- Почему мой BroadcastReceiver не работает?
- BroadcastReceiver не работает, когда приложение не работает
- Почему на версиях Android выше 6.0 не работает BroadcastReceiver onReceive?
- BroadcastReceiver не получает загрузку завершена
- 9 ответов:
- Broadcast (Широковещательные сообщения)
- Приёмники системных событий
- Типы трансляций
- Ограничения в Android 8.0 Oreo (API 26)
- Ограничения в Android 9.0 Pie (API 28)
Почему мой BroadcastReceiver не работает?
Я пытаюсь научиться использовать Android BroadcasReceiver. Я написал этот код, но он не работает… Я попытался, например, изменить время и т.д. Что это неправильно?
Я добавил в манифесте:
Мой простой BroadcasReceiver:
Моя основная деятельность (основная деятельность по умолчанию)
“В отличие от других широко распространенных намерений, для Intent.ACTION_SCREEN_OFF и Intent.ACTION_SCREEN_ON вы НЕ МОЖЕТЕ объявить их в своем манифесте Android! Я точно не знаю, почему, но они должны быть зарегистрированы в IntentFilter в вашем JAVA-коде”
Основной класс деятельности
открытый класс MainActivity расширяет действие <
публичный класс Broadcast расширяет BroadcastReceiver <
Ознакомьтесь с этим руководством по вещательным приемникам.
Обновление: я не уверен, что вы используете этот учебник, потому что в этом учебнике есть много полезного материала, например:
Другими словами, вы создали собственный broadcast receiver class , но вы его не использовали.
И также, пожалуйста, проверьте это.
Вы добавили необходимые предложения?
use-permission android: name = “android.permission.READ_PHONE_STATE”
Это приемник для обработки, когда экран выключен или включен или заблокирован:
У меня была та же проблема, и я ее исправил (проверен на 4.3 и 5.1). Я мог объявить “android.intent.action.USER_PRESENT” внутри манифеста, если у вас есть разрешение READ_PHONE_STATE, это нормально! Мое мини-приложение состоит из широковещательного приемника, который реагирует на состояние ВКЛ/ВЫКЛ экрана и запускает фоновый сервис, который обеспечивает непрерывное распознавание голоса. Если экран выключен, распознавание отключается. Вот код, наслаждайтесь: МАНИФЕСТ:
Как вы можете себе представить, мой приемник USER_PRESENT не зарегистрирован нигде. Я регистрирую ACTION_SCREEN_OFF и ON в методе onCreate моей службы, который был вызван моим получателем.
Наконец, я отменил регистрацию экрана в on-off в onDestroy() моей службы:
Источник
BroadcastReceiver не работает, когда приложение не работает
В моем файле манифеста я объявил получателя. (следующим образом)
Однако, как только я закрою свое приложение, я не могу получить предупреждения и уведомления. По-видимому, вызов OnReceive в моем Broadcast receiver никогда не был сделан.
Внутри MainActivity мой класс диспетчера аварийных сигналов выглядит следующим образом.
И мой манифест, как следует:
Что делать, чтобы получать уведомления / сигналы тревоги, даже если я отключил свое приложение. Фоновая служба?
Вы должны добавить фильтр намерений в манифест, так как
Как говорит Гонг Конг, вам нужно объявить, какие события прослушивает ваш приемник.
А затем, когда вы установите свой сигнал тревоги, используйте намерение с вашим действием:
Ваш код работает нормально!
Все, что вам нужно сделать, это изменить эту строку:
И код в onReceive будет работать после 5000 мс (5 секунд), даже если приложение не работает
В моем понимании, в некоторых случаях, в зависимости от способа реализации, ОС имеет право корректировать установленное время будильника. Поэтому попробуйте использовать AlarmManager.set (…), AlarmManager.setexact (…) и т. Д. Соответственно. В некоторых случаях, в зависимости от производителя (пользовательская ОС Android), существует вероятность того, что ОС блокирует пожарную тревогу.
Добавление android:exported=»true» для получателя в файле манифеста помогло мне получать сигналы тревоги (и, таким образом, пробуждать приложение), даже когда приложение было отключено (умышленно со мной, удалив приложение из списка задач).
1.Установите приемник в файле манифеста:
Всегда помните, что вся Android-система чувствительна к регистру. Поэтому проверьте правильность написания в AndroidMainfest.xml.
2.Если вы создаете PendingIntent для своего получателя, добавьте requestCode – даже это случайное число! Без вашего кода onReceive никогда не onReceive !
Функция, запускающая AlarmManager должна выглядеть следующим образом:
Оригинальная статья: Почему мой BroadcastReceiver не вызван?
Источник
Почему на версиях Android выше 6.0 не работает BroadcastReceiver onReceive?
У меня есть вот такой пример: ( stacktips.com/tutorials/android/repeat-alarm-examp. )
Работает начиная с 4.4. и до 6.0
- Вопрос задан более трёх лет назад
- 927 просмотров
Al,
Вот, добавил в Ресивер и заработало на 6.0
Причин может быть несколько.
Во-первых, убедитесь, что всё именно так, как вы думаете. Попробуйте запускать Activity вместо Toast.
Во-вторых, добавьте в receiver это:
а в манифест это:
и проверьте, чтобы было так:
Приложение должно быть запущено хотя бы один раз. Для этого добавьте в проект хотя бы одну Activity.
И можно проверить настройки безопасности системы или сторонних приложений, обеспечивающих безопасность.
Источник
BroadcastReceiver не получает загрузку завершена
Я искал здесь похожие проблемы, но по какой-то причине мой BroadcastReceiver никогда не получает android.намерение.действие.BOOT_COMPLETED намерениях.
вот мой (родственник) Андроид.Файл Манифеста:
а вот и сам приемник.
спасибо! Любая помощь очень ценится
9 ответов:
вы можете эмулировать все широковещательные действия, подключившись через adb к устройству и открыв оболочку устройства.
- откройте консоль / терминал и перейдите в /platform-tools
- тип adb shell или на linux / mac ./adb shell
- в оболочке типа am broadcast -a android.intent.action.BOOT_COMPLETED или любое действие, которое вы хотите запустить
есть куча хороших команд, поступающих с adb или оболочкой adb. Просто попробовать это
С уважением Фло
edit: О черт, я хотел, чтобы этот ответ был ответом на «должен был включать/выключать телефон каждый раз». к сожалению, ребята!—4—>
я публикую это в надежде, что это будет полезно для тех, кто пробовал все, но все еще не может заставить его работать при загрузке после установки или он работал раньше и больше не работает.
Итак, предположим, что вы добавили разрешение:
и зарегистрировал ваш приемник:
и исходном коде BroadcastReceiver :
начиная с Android 3.1 все приложения, после установки, размещены в «остановил» состояние.(Это то же самое состояние, в котором приложение заканчивается после принудительной остановки приложения пользователем из приложения настроек.)
находясь в состоянии «остановлено», приложение не будет работать ни по какой причине, за исключением ручного запуска деятельности. (Что означает нет BroadcastRecevier ( ACTION_PACKAGE_INSTALLED , BOOT_COMPLETED etc. будет вызван, независимо от события, для которого они зарегистрированы,пока пользователь не запустит приложение вручную.)
это дизайнерское решение Google для предотвращения вредоносных приложений. Google выступал за то, чтобы пользователи сначала запускали активность из пусковой установки, прежде чем это приложение сможет многое сделать. Предотвращение BOOT_COMPLETED от доставки до запуска действия является логическим следствием этого аргумента.
как только пользователь запускает любую активность в вашем приложении один раз, вы получите boot_completed broadcast после всех будущих загрузок.
Если ваше приложение установлено на внешнем хранение (SD-карта), вы никогда не получите полное действие загрузки. Поэтому вы должны указать android:installLocation=»internalOnly» на manifest tag .
оказывается, приемник не был в теге манифеста. Упс! Спасибо за вашу помощь ребята! Худшая часть о тестировании это то, чтобы продолжать выключать и по телефону. : P
код элемент должен быть непосредственным потомком элемент, и ваш код выше показывает, что это не так.
вот пример проекта демонстрация использования BOOT_COMPLETED .
это, кажется, основной поток для этой проблемы, поэтому я хотел добавить решение для моих коллег по C#. Я ломал голову, пытаясь понять, что я делаю неправильно после того, как попробовал все здесь, безрезультатно. Я, наконец, выяснил, что было не так, и это немного отличается от Совета здесь для разработки C# Mono. В основном, это сводится к тому, что я только что узнал трудный путь. С помощью C# не изменяйте AndroidManifest.xml вручную!
более непосредственно для этой проблемы, вот как вы это сделали.
во-первых, в свойствах проекта, на вкладке Манифест, есть список флажков для выбора разрешений, которые вы хотите предоставить, один из которых RECEIVE_BOOT_COMPLETED. Проверьте это, чтобы предоставить эти разрешения.
во-вторых, вам нужно поставить правильные теги на вашем BroacastReceiver класс.
заключительная часть [IntentFilter ()], связанная с приоритетом, не требуется, она просто позволяет другим более приоритетным вещам сначала загружаться и является хорошей практикой, если ваше приложение не является высокоприоритетной вещью.
Как вы увидите в связанной статье, Использование этих тегов в вашем коде вызовет AndroidManifest.xml-файл, который будет создан во время сборки, со всем, как это должно быть. Я обнаружил, что при изменении манифеста вручную включать тег приемника, система заставляла его искать класс на одном уровне слишком глубоко, тем самым бросая исключение ClassNotFound. Он пытался создать экземпляр [пространства имен].[Пространство имен.][BroadcastReceiver] что было неправильно. И это было сделано из — за ручного редактирования манифеста.
в любом случае, надеюсь, что это помогает.
кроме того, еще один быстрый совет с помощью инструмента adb. Если вы хотите получить более легкую для чтения версию журнала, попробуйте это:
C:\Android\platform-tools\adb logcat >> C:\log.txt
это приведет к сбросу logcat в текстовый файл, который вы можете открыть и прочитать немного проще, чем в окне командной строки. Делает вырезать и вставить вещи немного легче тоже.
относится к некоторым устройствам под управлением Android Kitkat 4.4.4_r2/r1.
там, кажется, ошибка в Android, которые делают android.намерение.действие.BOOT_COMPLETED нет вещания.
в большинстве случаев это не ответ на ваши проблемы (скорее всего, потому что разрешения и т. д.), Но если вы используете Kitkat, вы можете посмотреть и посмотреть, кажется ли это будьте в этом случае для вас.
У меня была эта проблема и android.намерение.действие.BOOT_COMPLETED просто не будет транслироваться несколько раз она завелась!
добавить это в мой файл манифеста решить мою проблему и работает.
другие ответы здесь уже описаны, как идеально реализовать широковещательный приемник, чтобы он работал, однако у меня все еще были проблемы с получением намерения BOOT_COMPLETED, пока я не понял, что приложение действительно работает при запуске с телефона/эмулятора, нажав на значок приложения. Всякий раз, когда я запускаю свое приложение с помощью команд debug/run из Android Studio, Boot_completed Intent не будет доставлен, если приложение не будет открыто и запущено.
Я надеюсь, что это может помочь кому-то который, как и я, часами боролся с этой проблемой. Более того, если у кого-то есть объяснение этому поведению, я был бы очень рад узнать об этом больше.
Источник
Broadcast (Широковещательные сообщения)
Практическая часть показана в отдельной статье.
Иногда для правильной работы приложению следует знать о текущем заряде батареи или наличии интернета. Если делать проверку самостоятельно на постоянной основе, то на систему идёт большая нагрузка. Но в этом нет нужды, система сама следит за подобными вещами и готова поделиться со всеми нуждающимися своими сообщениями. Ваша задача — реализовать у себя широковещательный приёмник (Broadcast Receiver). Получатель трансляции всегда будет получать уведомления, независимо от состояния вашего приложения — работает ли ваше приложение в фоновом режиме или вообще не работает в данный момент.
Широковещательные сообщения делают приложение более открытым; передавая события, использующие сообщения, вы открываете компоненты своего приложения для сторонних приложений, и сторонние разработчики реагируют на события без необходимости изменять ваше оригинальное приложение. В своём приложении вы можете прослушивать широковещательные сообщения других приложений, заменить или улучшить функциональность собственного (или стороннего) приложения или реагировать на системные изменения и события приложений.
Вы тоже можете организовать отправку широковещательных сообщений, а другие приложения могут обзавестись приёмниками для обработки ваших сообщений.
Приёмник широковещательных сообщений — это компонент для получения внешних событий и реакции на них. Инициализировать передачи могут:
- другие приложения или службы
- сама система
- ваше собственное приложение
Широковещательные сообщения можно разделить на две группы:
- Неявная широковещательная трансляция (implicit broadcast) — сообщения рассылаются всем желающим, а не конкретно вашему приложению. Вам нужно только зарегистрироваться для получения этих сообщений через фильтр IntentFilter в манифесте. Система просматривает все объявленные фильтры намерений в вашем манифесте и проверяет, есть ли совпадение. Из-за этого поведения неявные широковещательные сообщения не имеют целевого атрибута
- Явная трансляция (explicit broadcast) предназначена для конкретных приложений. В атрибуте target указывают имя пакета приложения или имя класса компонента, по которому можно найти получателя
Класс BroadcastReceiver является базовым для класса, в котором должны происходить получение и обработка сообщений, посылаемых клиентским приложением с помощью вызова метода sendBroadcast().
Зарегистрировать экземпляр класса BroadcastReceiver можно динамически в коде или статически в манифесте.
Для статической регистрации в файле манифеста в секции application следует создать секцию receiver и указать класс приёмника. Атрибут android:exported=»true» сообщает получателю, что он может принимать широковещательные сообщения вне области приложения. Внутри секции указывается фильтр намерений в виде строки, чтобы определить, какие сообщения приёмник должен прослушивать.
Если регистрация была сделана через манифест, приложение не обязано работать, чтобы ваш приёмник среагировал на трансляцию намерения. Приложение запустится автоматически, когда подходящие намерение будет транслировано. Система сама сканирует содержимое манифеста всех приложений и делает за нас всю работу. Это хорошее решение, позволяющее экономить ресурсы. Такой подход позволяет создавать приложения, способные реагировать на события даже после завершения или принудительного завершения.
Динамическая регистрация происходит с помощью метода Context.registerReceiver().
Перед этим создаётся класс, расширяющий базовый класс BroadcastReceiver и реализуется метод обратного вызова onReceive() обработчика событий.
Метод onReceive() будет выполнен при получении широковещательного намерения, если полученное намерение соответствует фильтру. Приложения с зарегистрированными приёмниками широковещательных намерений будут запущены автоматически при получении соответствующего намерения. Метод должен быть завершён в течение пяти секунд, иначе появится диалоговое окно о принудительном закрытии.
Когда широковещательное сообщение прибывает для получателя сообщения, Android вызывает его методом onReceive() и передаёт в него объект Intent, содержащий сообщение. Приёмник широковещательных сообщений является активным только во время выполнения этого метода. Процесс, который в настоящее время выполняет BroadcastReceiver, т. е. выполняющийся в настоящее время код в методе обратного вызова onReceive(), как полагает система, является приоритетным процессом и будет сохранён, кроме случаев критического недостатка памяти в системе.
Когда программа возвращается из метода onReceive(), приёмник становится неактивным и система полагает, что работа объекта BroadcastReceiver закончена. Процесс с активным широковещательным получателем защищён от уничтожения системой. Однако процесс, содержащий неактивные компоненты, может быть уничтожен системой в любое время, когда память, которую он потребляет, будет необходима другим процессам.
Это представляет проблему, когда ответ на широковещательное сообщение занимает длительное время. Если метод onReceive() порождает отдельный поток, а затем возвращает управление, то полный процесс, включая и порождённый поток, система Android считает неактивным (если другие компоненты приложения не активны в процессе), и считает этот процесс кандидатом на уничтожение.
В частности, вы не можете отобразить диалог или осуществить связывание со службой внутри экземпляра BroadcastReceiver. Для первого случая необходимо вместо этого использовать методы класса NotificationManager. Во втором случае можно использовать вызов метода Context.startService(), чтобы послать команду для запуска службы.
Решение этой проблемы возможно, если запустить в методе onReceive() отдельную службу вместе с BroadcastReceiver и позволить службе выполнять задание, чтобы сохранить содержание процесса активным в течение всего времени вашей операции.
Также можно зарегистрировать широковещательный приёмник не через манифест, а программно. Приёмник, зарегистрированный таким способом, будет отвечать на поступающие намерения только в том случае, если компонент приложения, которому он принадлежит, выполняется в этот момент.
Это может быть полезным, когда приёмник используется для обновления элементов пользовательского интерфейса внутри активности, запуска служб или уведомления через NotificationManager. В таких случаях вы можете отменять регистрацию широковещательного приёмника, если активность не отображается на экране или находится в неактивном состоянии.
В коде программы можете написать приблизительно такой код (обычно используют метод onResume()):
Для отмены регистрации используется метод unregisterReceiver() в контексте приложения, передавая ему в качестве параметра экземпляр широковещательного приёмника (обычно в методе onPause()):
Для объекта BroadcastReceiver нет никаких возможностей видеть или фиксировать намерения, используемые в методе startActivity(). Аналогично, когда вы передали намерение для запуска активности через объект BroadcastReceiver, вы не сможете найти или запустить требуемую активность. Эти две операции семантически полностью различаются: запуск активности через намерение является приоритетной операцией для системы, изменяющей содержимое экрана устройства, с которым в настоящее время взаимодействует пользователь. Передача широковещательных сообщений для системы является фоновой работой, о которой обычно не знает пользователь и которая, соответственно, имеет более низкий приоритет.
Приёмники системных событий
Android использует широковещательные сообщения для системных событий, таких как уровень зарядки батареи, сетевые подключения, входящие звонки, изменения часового пояса, состояние подключения данных, входящие сообщения SMS или обращения по телефону. Вы можете использовать эти сообщения, чтобы добавлять к вашим собственным проектам новые функциональные возможности, основанные на системных событиях.
Следующий список показывает некоторые из встроенных действий, представленных как константы в классе Intent, которые используются для того, чтобы проследить изменения состояния устройства:
- ACTION_BOOT_COMPLETED — передаётся один раз, когда устройство завершило свою загрузку. Требует разрешения RECEIVE_BOOT_COMPLETED
- ACTION_CAMERA_BUTTON — передаётся при нажатии пользователем клавиши Camera
- ACTION_DATE_CHANGED и ACTION_TIME_CHANGED — запускаются при изменении даты или времени на устройстве вручную пользователем
- ACTION_SCREEN_OFF и ACTiON_SCREEN_ON — передаются, когда экран выключается или включается
- ACTION_TIMEZONE_CHANGED — передаётся при изменении текущего часового пояса
Типы трансляций
Есть три способа отправки трансляций
- Порядковые сообщения о намерениях (Ordered broadcasts), которые посылаются методом Context.sendOrderedBroadcast(). Эти сообщения посылаются только одному получателю за один раз. Поскольку каждое полученное сообщение выполняется по очереди, он может в случае необходимости полностью прервать сообщение, чтобы его не успели передать другим приёмникам. Приёмниками сообщений можно управлять с помощью атрибута android:priority фильтра сообщений; приёмники сообщений, имеющие одинаковый приоритет, будут выполнены в произвольном порядке.
- Нормальные сообщения о намерениях (Normal broadcasts) — посылаемые вызовом метода context.sendBroadcast() и являющиеся полностью асинхронными. Все широковещательные приёмники получают сообщение и не зависят друг от друга. Это более эффективно, но означает, что получатели не могут использовать результат или прервать сообщение;
- Метод LocalBroadcastManager.sendBroadcast() отправляет широковещательные сообщения только получателям, определённым в вашем приложении, и не выходит за рамки вашего приложения
Если важно, чтобы приёмники получали намерения в определённом порядке или могли влиять на транслируемое намерение, можно использовать метод sendOrderedBroadcast():
С помощью этого метода ваше намерение дойдёт до всех зарегистрированных приёмников, обладающих необходимым доступом (если он был указан), в порядке их приоритета. Приоритет задаётся с помощью атрибута android:priority внутри узла фильтра намерений в манифесте. Чем больше значение, тем выше приоритет.
Производить упорядоченные трансляции с использованием приоритетов рекомендуется только для тех приёмников, которым необходим конкретный порядок приёма сообщений.
Ограничения в Android 8.0 Oreo (API 26)
Часть неявных (implicit) широковещательных сообщений, задаваемых через манифест, запретили. Теперь нужно регистрировать их программно. Существует список исключений, которые будут работать как прежде без ограничений.
В качестве замены для некоторых случаев подойдёт JobScheduler.
Примерами устаревшего способа работы с приёмником является android.net.conn.CONNECTIVITY_CHANGE, ACTION_POWER_CONNECTED и др.
Ограничения в Android 9.0 Pie (API 28)
Стало доступно меньше информации, получаемой при трансляции системы Wi-Fi и Network_State_Changed_Action.
Источник