Android broadcast boot completed

Содержание

Автозапуск приложения при загрузке
Практика: ошибки и особенности эксплуатации
Отладка ресивера в эмуляторе и на реальных устройствах
Итоги
Android. Автозапуск приложения при загрузке: теория и практика
1. Теория
2. Практика: ошибки и особенности эксплуатации
3. Отладка ресивера в эмуляторе и на реальных устройствах.
Итоги
Android — Broadcast Receivers
Creating the Broadcast Receiver
Registering Broadcast Receiver
Broadcast-Receiver
Broadcasting Custom Intents
Example

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

Тема получения сообщения ACTION_BOOT_COMPLETED остается актуальной и по сей день. Многие новички сталкиваются с проблемой: они не получают в своих приложениях данное сообщение.

Можно выделить следующие правила:

В манифесте указать разрешение:

В манифесте в блоке application зарегистрировать приёмник на приём сообщения ACTION_BOOT_COMPLETED:

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

Код вашего широковещательного приёмника:

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

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

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

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

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

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

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

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

После установки или force stop приложение ни разу не запускалось.
Приложение установлено не на внутренней памяти, или пользователь вручную перенес его на внешнюю память.
У некоторых разработчиков приём начинал работать, когда они указывали относительное имя класса приёмника.
Также некоторые разработчики в Logcat не видели своих сообщений из ресивера. Используйте Toast для отладки:
Опечатки или несуществующие сообщения внутри тега ресивера:
Неправильное положение элементов в манифесте приложения:
«uses-permission» должен быть указан только как прямой потомок элемента «manifest», не нужно его указывать/дублировать в теге «receiver»;
тег «receiver» должен быть указан только как прямой потомок элемента «application».
Различные диспетчеры задач, оптимизаторы, приложения безопасности, Startup-менеджеры и т.п. могут отслеживать регистрацию приложения для приема ACTION_BOOT_COMPLETED и запрещать/разрешать его получение при загрузке. Удалите эти приложения или добавьте в исключение вашу программу в их настройках.
Как было указано выше, некоторые устройства используют режим Fast boot. Можно попробовать в настройках телефона отключить этот режим.
В приложении нет ни одной активности, поэтому после установки у пользователя нет возможности хотя бы один раз запустить ваше приложение. Из-за этого сообщение ACTION_BOOT_COMPLETED не будет отправлено в ваше приложение.
Нет ошибки, но всё же: указаны лишние, не обязательные атрибуты в теге «receiver», например («uses-permission», «enabled», «exported») (Примечание от меня: сомнительный совет, у меня работало):

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

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

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

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

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

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

Итоги

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

Источник

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

1. Теория

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

В манифесте в элементе «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. Практика: ошибки и особенности эксплуатации

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

Приложение установлено не на внутренней памяти, или пользователь вручную перенес его на внешнюю память (см. п. 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».

Источник

Android — Broadcast Receivers

Broadcast Receivers simply respond to broadcast messages from other applications or from the system itself. These messages are sometime called events or intents. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.

There are following two important steps to make BroadcastReceiver works for the system broadcasted intents −

Creating the Broadcast Receiver.

Registering Broadcast Receiver

There is one additional steps in case you are going to implement your custom intents then you will have to create and broadcast those intents.

Creating the Broadcast Receiver

A broadcast receiver is implemented as a subclass of BroadcastReceiver class and overriding the onReceive() method where each message is received as a Intent object parameter.

Registering Broadcast Receiver

An application listens for specific broadcast intents by registering a broadcast receiver in AndroidManifest.xml file. Consider we are going to register MyReceiver for system generated event ACTION_BOOT_COMPLETED which is fired by the system once the Android system has completed the boot process.

Broadcast-Receiver

Now whenever your Android device gets booted, it will be intercepted by BroadcastReceiver MyReceiver and implemented logic inside onReceive() will be executed.

There are several system generated events defined as final static fields in the Intent class. The following table lists a few important system events.

Sticky broadcast containing the charging state, level, and other information about the battery.

Indicates low battery condition on the device.

Indicates the battery is now okay after being low.

This is broadcast once, after the system has finished booting.

Show activity for reporting a bug.

Perform a call to someone specified by the data.

The user pressed the «call» button to go to the dialer or other appropriate UI for placing a call.

The date has changed.

Have the device reboot.

Broadcasting Custom Intents

If you want your application itself should generate and send custom intents then you will have to create and send those intents by using the sendBroadcast() method inside your activity class. If you use the sendStickyBroadcast(Intent) method, the Intent is sticky, meaning the Intent you are sending stays around after the broadcast is complete.

This intent com.tutorialspoint.CUSTOM_INTENT can also be registered in similar way as we have regsitered system generated intent.

Example

This example will explain you how to create BroadcastReceiver to intercept custom intent. Once you are familiar with custom intent, then you can program your application to intercept system generated intents. So let’s follow the following steps to modify the Android application we created in Hello World Example chapter −

Sr.No	Event Constant & Description
1

Step	Description
1	You will use Android studio to create an Android application and name it as My Application under a package com.example.tutorialspoint7.myapplication as explained in the Hello World Example chapter.
2	Modify main activity file MainActivity.java to add broadcastIntent() method.
3	Create a new java file called MyReceiver.java under the package com.example.tutorialspoint7.myapplication to define a BroadcastReceiver.
4	An application can handle one or more custom and system intents without any restrictions. Every intent you want to intercept must be registered in your AndroidManifest.xml file using tag
5	Modify the default content of res/layout/activity_main.xml file to include a button to broadcast intent.
6	No need to modify the string file, Android studio take care of string.xml file.
7	Run the application to launch Android emulator and verify the result of the changes done in the application.

Following is the content of the modified main activity file MainActivity.java. This file can include each of the fundamental life cycle methods. We have added broadcastIntent() method to broadcast a custom intent.

Following is the content of MyReceiver.java:

Following will the modified content of AndroidManifest.xml file. Here we have added tag to include our service:

Following will be the content of res/layout/activity_main.xml file to include a button to broadcast our custom intent −

Let’s try to run our modified Hello World! application we just modified. I assume you had created your AVD while doing environment set-up. To run the app from Android studio, open one of your project’s activity files and click Run icon from the tool bar. Android Studio installs the app on your AVD and starts it and if everything is fine with your set-up and application, it will display following Emulator window −

Now to broadcast our custom intent, let’s click on Broadcast Intent button, this will broadcast our custom intent «com.tutorialspoint.CUSTOM_INTENT» which will be intercepted by our registered BroadcastReceiver i.e. MyReceiver and as per our implemented logic a toast will appear on the bottom of the the simulator as follows −

You can try implementing other BroadcastReceiver to intercept system generated intents like system boot up, date changed, low battery etc.

Источник