Loading an android program

Running Your Android Application on an Android Emulator

After you create one or more Android emulators, you can run your RAD Studio mobile applications on your Android emulators. Before you run your application on your Android emulator, start your Android emulator as described below in To Start Your Android Emulator, so as to reduce startup time when you run your Android application from the IDE.

Caution: Android emulators are extremely slow and do not support the same feature set as real devices.
We do not recommend that you attempt to use an Android emulator:

• If you have an Android device, use your Android device instead.

• You can also use Mobile Preview to do initial debugging of an Android app.

To Start Your Android Emulator

1. Start the Android Virtual Device Manager: Select Start | All Programs | Embarcadero RAD Studio XE6 | Android SDKs | Android AVD Manager .
2. In the Android Virtual Device Manager, select your Android emulator in the list and click Start.
3. On the Launch options dialog box, click Launch:

To Run Your Application on Your Android Emulator

1. Open your Android application in RAD Studio.
2. In the Project Manager, enable the emulator as the target platform. If necessary, expand the Target Platforms node and double-click the Android target platform. (The active target platform is displayed using a bold font.)
   1. Expand the Android node in the Project Manager.
   2. Expand the child Target node.
   3. Double-click the target Android emulator to activate it. (The active emulator is displayed using a bold font.) Note: If the emulator is not shown, right-click the Target node and select Refresh. If the emulator still is not displayed, see Using the Target Node.

   In the following image you can see an emulator named rsxe6_android running, and the target platform setting activated in the Project Manager:

3. In the device selector in the FireMonkey Mobile Form Designer, select the device that matches the emulator you are using. For example, if your emulator uses the WQVGA400 device, select 3.3″ WQVGA Android Phone (240dp x 400 dp).
4. Run your application:
   • Run with debugging ( Run >Run or F9)
   • Run without debugging ( Run >Run Without Debugging or SHIFT+CTRL+F9)
5. Compile and deploy messages should appear in the IDE.
6. If the emulator is not running, the IDE displays: «The selected emulator is not running. Do you want start it?» Click Yes. A «Launching emulator» message is displayed.
7. Open your emulator screen and watch for the app to appear. In the following image you can see a custom Nexus 4 emulator running a simple Hello World! application:

RAD Studio builds your application for Android and runs your application on the selected Android emulator. If the active Android emulator is not running, RAD Studio shows a dialog box that gives you the choice to start your Android emulator. If your Android emulator screen is locked, unlock it to access your application.

Android emulators run much slower than real devices due to the ARM platform emulation on top of a non-ARM system; if performance prevents you from using an Android emulator side by side with RAD Studio, see Running and Debugging Your Android Application Remotely. For obvious reasons, emulators also lack some of the physical features that real devices provide, although you can emulate some features], such as geo location.

Источник

Android. Автозапуск приложения при загрузке: теория и практика

1. Теория

Взглянув на примеры из официального источника (например, этот и этот) и изучив рекомендации на сайте stackoverflow.com, можно выделить следующие правила:

В манифесте в элементе «manifest» указать разрешение:

В манифесте в элементе «application» зарегистрировать ваш ресивер на прием сообщения ACTION_BOOT_COMPLETED:

Используйте правильное полное или относительное имя класса вашего broadcast-ресивера. В описании ресивера без необходимости не указывайте атрибуты «enabled», «exported» и т.д. Вполне достаточно настроек и атрибутов по умолчанию.

Код вашего broadcast-ресивера:

Если ваш ресивер используется только для сообщения ACTION_BOOT_COMPLETED, то проверка «if» не обязательна. Однако иногда разработчики используют один и тот же ресивер для разных сообщений. В этом случае фильтруйте сообщения, проверяя их внутри метода onReceive.

Приложение должно быть установлено на внутреннюю память. ОС Android устроена таким образом, что сообщение ACTION_BOOT_COMPLETED отправляется приложениям перед монтированием внешний памяти. Поэтому приложения, установленные на внешней памяти, никогда не получат это сообщение. Чтобы указать системе не устанавливать приложение на внешнюю память, в манифесте НЕ нужно прописывать для атрибута «@android:installLocation» значения «auto» или «preferExternal». По умолчанию, т.е. если этот атрибут не указан, ОС установит ваше приложение только на внутреннюю память. Однако согласно официальной документации лучше явно указать значение «internalOnly», чтобы у вас и других разработчиков не возникло искушение в будущем указать иное значение.

После установки или принудительной остановки (force stop) приложение должно быть запущено хотя бы один раз, чтобы система «запомнила» это приложение для отправки ему сообщения ACTION_BOOT_COMPLETED. Такое поведение было реализовано в версии Android 3.1 в целях безопасности. В чем суть? Все только что установленные приложения находятся в состоянии «stopped» (не путать с активити, т.к. ОС управляет этим состоянием у приложений и активити по-разному). В это же состояние приложение «уходит», когда пользователь в настройках телефона принудительно его останавливает. Пока приложение находится в таком состоянии, оно не будет запущено системой ни по какой причине (например, через ACTION_BOOT_COMPLETED), исключая, конечно же, запуск самим пользователем. Благодаря такому нововведению немалая часть«вирусни и троянцев» перестала работать, т.к. уже нет возможности запуститься автоматом после установки.

Исключение составляют системные приложения: см. замечание пользователя kolipass.

Особенности режима Fast boot в HTC-устройствах. Известно, что HTC-устройства не перезагружаются в классическом смысле, а используют так наз. режим Fast boot (это одна из форм гибернации), сохраняя состояние ОС на диск. Поэтому сообщение ACTION_BOOT_COMPLETED не отправляется системой, т.к. в действительности перезагрузка не происходит (см. здесь). Вместо ACTION_BOOT_COMPLETED система может отправить следующие сообщения:

В вашем приложении укажите в теге «receiver» кроме ACTION_BOOT_COMPLETED также вышеуказанные сообщения. Кроме этого необходимо прописать разрешение в дополнение к п.1:

2. Практика: ошибки и особенности эксплуатации

Разберем ошибки, которые совершают новички при настройке приложения и в коде.

После установки или force stop приложение ни разу не запускалось (см. п.1.5).

Приложение установлено не на внутренней памяти, или пользователь вручную перенес его на внешнюю память (см. п. 1.4).

У некоторых разработчиков прием начинал работать, когда они указывали относительное имя класса ресивера.

Также некоторые разработчики, отлаживая приложение, в logcat не видели своих сообщений из ресивера. Используйте Toast для отладки:

Опечатки или несуществующие сообщения внутри тега ресивера:

Неправильное положение элементов в манифесте приложения:

• «uses-permission» должен быть указан только как прямой потомок элемента «manifest», не нужно его указывать/дублировать в теге «receiver»;
• тег «receiver» должен быть указан только как прямой потомок элемента «application».

Различные диспетчеры задач, оптимизаторы, приложения безопасности, Startup-менеджеры и т.п. могут отслеживать регистрацию приложения для приема ACTION_BOOT_COMPLETED и запрещать/разрешать его получение при загрузке. Удалите эти приложения или добавьте в исключение вашу программу в их настройках.

Как было указано выше, некоторые устройства используют режим Fast boot. Можно попробовать в настройках телефона отключить этот режим или учесть п. 1.6.

В приложении нет ни одной активити, поэтому после установки у пользователя нет возможности хотя бы 1 раз запустить ваше приложение. Из-за этого сообщение ACTION_BOOT_COMPLETED не будет отправлено в ваше приложение.

Не ошибки, но все же: указаны лишние, не обязательные атрибуты в теге «receiver», например («uses-permission», «enabled», «exported»):

3. Отладка ресивера в эмуляторе и на реальных устройствах.

В терминале выполните:

Далее, чтобы отправить ACTION_BOOT_COMPLETED всем приложениям, наберите в терминале:

Или для отправки ACTION_BOOT_COMPLETED конкретному приложению наберите в терминале:

В эмуляторе: установите ваше ПО, запустив его из студии. При этом студия соберет ваш проект, установит приложение и запустит его. После этого закройте эмулятор (это аналогично выключению на реальном устройстве). Чтобы получить сообщение ACTION_BOOT_COMPLETED, запустите эмулятор из AVD-менеджера, а не с помощью кнопки «Run app» в тулбаре студии.

После запуска эмулятора во вкладке Android Monitor укажите запущенный эмулятор и ваше приложение, чтобы просмотреть логи logcat.

Итоги

Чтобы ваше приложение запускалось при загрузке на всех устройствах, манифест как минимум должен выглядеть так:

Код ресивера, как правило, будет таким:

Надеюсь, эта статья поможет новичкам побороть «коварного врага» под названием «ACTION_BOOT_COMPLETED».

Источник

Руководство по фоновой работе в Android. Часть 2: Loaders

Это вторая из серии статей об инструментах и методах фоновой работы в Android. Ранее уже были рассмотрены AsyncTask, в следующих выпусках — ThreadPools с EventBus, RxJava 2 и корутины в Kotlin.

В предыдущем тексте мы упомянули, что у AsyncTasks есть несколько проблем. Давайте вспомним две из них:

• AsyncTasks ничего не знают о жизненном цикле Activity. При неправильном обращении вы в лучшем случае получите утечку памяти, а в худшем — сбой.
• AsyncTask не поддерживает сохранение состояния прогресса и повторное использование результатов загрузки.

Смысл первой проблемы вот в чем: чтобы обновить UI в методе onPostExecute, нам нужна ссылка на конкретный view или на всю Activity, к которой он относится. Наивный подход в том, чтобы хранить эту ссылку внутри самого AsyncTask:

Проблема в том, что как только пользователь поворачивает устройство, Activity уничтожается, и ссылка устаревает. Это приводит к утечке памяти. Почему? Вспомним, что наш метод doInBackground вызывается внутри Future, исполняемого на executor — статическом члене класса AsyncTask. Это делает наш объект AsyncTask, а также Activity, строго достижимыми(потому что статика является одним из корней GC), а следовательно, неподходящими для сборки мусора. Это в свою очередь означает, что несколько поворотов экрана могут вызвать OutOfMemoryError, потому что Activity занимает приличный объем памяти.

Исправить эту ошибку можно с помощью WeakReference:

Хорошо, от OOM мы избавились, но результат выполнения AsyncTask в любом случае потерян, и мы обречены вновь его запускать, разряжая телефон и расходуя трафик.

Для того, чтобы исправить это, команда Android несколько лет назад предложила Loaders API («Загрузчики»). Посмотрим, как использовать это API. Нам нужно реализовать интерфейс Loader.Callbacks:

Как можно заметить, метод onLoadFinished очень похож на onPostExecute, который мы реализовывали в AsyncTask.

Нам нужно создать сам Loader:

И вызвать initLoader() с id нашего Loader:

Пожалуйста, обратите внимание: WeatherForecastLoaderCallbacks — вложенный класс нашей Activity; LoaderManager хранит ссылку на этот объект Callbacks — а значит, и на саму Activity тоже

Немало кода, да? Но мы тут получаем важное преимущество. Во-первых, Loader оказывается переиспользован при повороте экрана (или других изменениях конфигурации). Если экран повернули, onLoadFinished будет вызван с передачей результата, загруженного нами ранее.

Другое преимущество в том, что у нас не происходит утечка памяти, хотя доступ к Activity у нас остается, позволяя обновлять интерфейс.

Круто, у AsyncTask обоих этих преимуществ не было! Давайте теперь разберёмся, как всё это работает.

Тут-то и начинается главное веселье. Я думал, что LoaderManager хранится где-то внутри Application, но настоящая реализация оказалась куда более интересной.

LoaderManager создается при создании экземпляра Activity:

FragmentController.createController — это просто именованный конструктор для класса FragmentController. FragmentController делегирует создание LoaderManager в HostCallbacks (вложенному классу нашей Activity), реализация выглядит так:

Как видите, LoaderManager для самой Activity инициализируется лениво; экземпляр LoaderManager не создается до тех пор, пока впервые не понадобится. Доступ к LoaderManager нашей Activity происходит по ключу ‘(root)’ в Map LoadersManagers. Доступ к этой Map реализован так:

Однако это не последняя запись поля LoaderManager. Посмотрим на метод Activity#onCreate:

Метод restoreLoaderNonConfig в итоге просто обновляет host controller, который теперь является членом класса нового экземпляра Activity, созданной после изменения конфигурации.

При вызове метода initLoader() у LoaderManager уже есть вся информация о Loaders, которые были созданы в уничтоженной Activity. Так что он может опубликовать загруженный результат немедленно:

Здорово, что мы разобрались с двумя вещами сразу: как мы избегаем утечек памяти (заменяя экземпляр LoaderCallback) и как доставляем результат в новую Activity!

Возможно, вас интересует, что ещё за зверь такой — mLastNonConfigurationInstances. Это экземпляр класса NonConfigurationInstances, определённый внутри класса Activity:

Объект создаётся с помощью метода retainNonConfigurationInstance(), а затем к нему напрямую обращается Android OS. И он становится доступен для Activity в методе Activity#attach() (а это внутреннее API Activity):

Так что, к сожалению, главная магия остаётся внутри Android OS. Но поучиться на её примере нам никто не запретит!

Давайте подытожим, что мы обнаружили:

1. У Loaders неочевидное API, но они позволяют сохранять результат загрузки при изменении конфигурации
2. Loaders не вызывают утечки памяти: просто не делайте их вложенными классами Activity
3. Loaders позволяют в фоновой работе переиспользовать AsyncTask, но можно и реализовать свой собственный Loader
4. LoaderManager оказывается переиспользованным между уничтоженными и вновь созданными Activity благодаря сохранению в специальный объект

В следующей статье мы поговорим, как организовывать фоновую работу на Executors, и подмешаем туда немного EventBus. Stay tuned!

Как вы заметили, это перевод моей англоязычной статьи. Если статья вам показалось ценной, обратите внимание — в апреле пройдёт конференция Mobius, в программный комитет которой я вхожу, и могу обещать, что в этом году программа будет особенно насыщенна. На сайте конференции пока что опубликована только часть программы, потому что нам крайне тяжело выбрать лучшие — конкуренция остра как никогда. Уже можете изучить имеющиеся описания докладов, а скоро к ним добавятся новые!

Источник

Читайте также:  Распорядок дня для андроида