Информационный портал по безопасности

Хочу поделиться историей разработки своего приложения. Идея приложения возникла 1,5 года назад, начало разработки было положено в феврале 2017 года и завершено всё в июне 2017 года.

Началась эта история с того, что в результате неудачных экспериментов с ядром смартфона Samsung Galaxy Ace 2 (он же GT-I8160, aka codina), приводящих к ребутам девайса, оказалось так, что раздел EFS перестал читаться. Собственно, сами эксперименты отношения к данному вопросу не имеют — возможно, как-нибудь дойду и до них, но это выходит за рамки данной статьи. Хотя и раздел EFS – один из наиболее важных на этом смартфоне, убийство данного раздела само по себе не приводит к катастрофическим последствиям, поскольку его все еще можно восстановить, например, с другого телефона, после чего, при желании сменить WIFI MAC и BT MAC. На данном устройстве IMEI хранится не на разделе EFS, а CSPSA (Crash Safe Parameter Storage Area, дословно переводится как «Область хранения параметров, устойчивая к крашам»). Вот если с этим разделом пойдет что-то не так, это уже будет не столь весело, собственно об этом и пойдет речь далее. Кого заинтересовал, прошу под кат.

Представьте, что у вас имеется образ ядра Linux для телефона на базе Android, но вы не располагаете ни соответствующими исходниками, ни заголовочными файлами ядра. Представьте, что ядро имеет поддержку подгрузки модулей (к счастью), и вы хотите собрать модуль для данного ядра. Существует несколько хороших причин, почему нельзя просто собрать новое ядро из исходников и просто закончить на том (например, в собранном ядре отсутствует поддержка какого-нибудь важного устройства, вроде LCD или тачскрина). С постоянно меняющимся ABI ядра Linux и отсутствием исходников и заголовочных файлов, вы можете подумать, что окончательно зашли в тупик.

Как констатация факта, если вы соберете модуль ядра, используя другие заголовочные файлы (нежели те, что были использованы для сборки того образа ядра, которым вы располагаете, — прим. пер.), модуль не сможет загрузиться с ошибками, зависящими от того, насколько заголовочные файлы отличались от требуемых. Он может жаловаться о плохих сигнатурах, плохих версиях и о прочих вещах.

Но больше об этом далее.

Читая Хаб о разработке игр, я часто натыкаюсь на топики в духе «А вот мы делали-делали игру, конечно, она не пошла, но главное опыт, первый блин комом...» и все в таком ключе. Да я и сам грешил этим, чего уж скрывать. И знаете что? К черту это! Хочется прочитать, как у автора все получилось, про миллионы восторженных игроков, про манящие вершины топов, про то, ради чего мы и читаем «постмортемы». Чтобы черпать вдохновение, чтобы с удвоенной энергией преодолевать свои собственные трудности, в конце концов.



Этим мы сегодня и займемся. Это будет рассказ о создании одной моей неоднозначной головоломки, с трудностями, победами, деньгами и прочими пикантными подробностями (для самых нетерпеливых я обвел на КДПВ сумму). Конечно, кто-то только улыбнется такому «успеху», но я считаю, что в современных реалиях, игра, сделанная 2 людьми в свободное от основной работы время, показала себя очень и очень неплохо! Но, обо всем по порядку.

Xamarin удивителен тем, что позволяет .NET разработчикам писать приложения для Android, iOS, macOS на… С#. Но эта удивительная возможность имеет свою цену и даже простейшее приложение может запросто потреблять неприлично много памяти. Давайте посмотрим как это происходит и что мы можем сделать с этим. Большинство моих примеров основываются на Xamarin.Android, но вы быстро заметите, что это также применимо и к Xamarin.iOS.

Как работает сборщик мусора в Xamarin приложениях

На самом деле в Xamarin приложениях используется несколько типов объектов. Каждое Xamarin приложение имеет объекты, которые живут в двух отдельных мирах:

• Управляемый, мир Mono с объектами, наследуемыми из System.Object


• Неуправляемый, нативный мир с объектами, наследуемыми от NSObject (iOS) или Java.Lang.Object (Android)

Из этого также следует что существуют и работают 2 сборщика мусора:

• Сборщик мусора от Mono, называемый SGEN


• Сборщики мусора из нативных миров Android или iOS

На одном из проектов столкнулась с утечками памяти. Воспользовалась первым правилом разработчиков — загуглила. К моему глубокому разочарованию нашла много статей для программистов и совсем чуточку для тестировщиков. Большинство публикаций датированы 2011-2014 годом.

Ниже информация об утечках памяти, которая пригодится в 2017 году. Расскажу, чем их наличие грозит приложению, и перечислю несколько подходов к локализации.

Этот туториал предназначен в первую очередь для новичков в разработке под андроид, но может быть будет полезен и более опытным разработчикам. Тут рассказано как создать простейшую 2D игру на анроиде без использования каких-либо игровых движков. Для этого я использовал Android Studio, но можно использовать любую другую соответствующее настроенную среду разработки.

Шаг 1. Придумываем идею игры
Для примера возьмём довольно простую идею:

Внизу экрана — космический корабль. Он может двигаться влево и вправо по нажатию соответствующих кнопок. Сверху вертикально вниз движутся астероиды. Они появляются по всей ширине экрана и двигаются с разной скоростью. Корабль должен уворачиваться от метеоритов как можно дольше. Если метеорит попадает в него — игра окончена.

Как известно, RxJava идеально подходит для решения двух задач: обработки потоков событий и работы с асинхронными методами. В одном из предыдущих постов я показал, как можно построить цепочку операторов, обрабатывающую поток событий от сенсора. А сегодня я хочу продемонстрировать, как RxJava применяется для работы с существенно асинхронным API. В качестве такого API я выбрал Camera2 API.

Ниже будет показан пример использования Camera2 API, который пока довольно слабо задокументирован и изучен сообществом. Для его укрощения будет использована RxJava2. Вторая версия этой популярной библиотеки вышла сравнительно недавно, и примеров на ней тоже немного.

Для кого этот пост? Я рассчитываю, что читатель – умудрённый опытом, но всё ещё любознательный Android-разработчик. Очень желательны базовые знания о реактивном программировании (хорошее введение – здесь) и понимание Marble Diagrams. Пост будет полезен тем, кто хочет проникнуться реактивным подходом, а также тем, кто хочет использовать Camera2 API в своих проектах. Предупреждаю, будет много кода!

Исходники проекта можно найти на GitHub.

В этом году я впервые побывал на Google I/O. По итогу, могу с уверенностью сказать, что было круто! О докладах я рассказал в предыдущей статье, а теперь — о самой поездке. Рекомендую каждому Android-разработчику туда съездить. Под катом — лайфхаки на тот случай, если вы хотите побывать на Google I/O, но не знаете, как это сделать и во сколько вам это обойдётся.

Этот пост является вольным переводом статьи Kotlin and Swift. Is it a whole new era in Mobile Development? by Andrew Cherkashyn

Когда в Google объявили о том, что они теперь официально будут использовать Kotlin для разработки под Android, я, как и многие другие Android-разработчики, вздохнул с облегчением. Я еще раз зашел на официальный сайт Kotlin, чтобы перепроверить функционал/синтаксис и сравнить его с последней версией Swift, на котором сейчас пишу, и вдруг ощутил это: проходит одна эпоха и начинается новая, по крайней мере в мобильной разработке...