Awareness API и Android O с помощью BroadcastReceiver

Ответ 1

Теперь я не могу протестировать его на устройстве, но из всего, что я прочитал, ограничение распространяется только на неявные трансляции. Это означает, что если вы создаете явную трансляцию вместо этого, все, что вам нужно, чтобы заставить ее работать.

Это означает вместо этого:

// implicit intent matching action
PendingIntent.getBroadcast(context, 0,
    new Intent("my.application.packageFENCE_RECEIVER_ACTION"), 0)

вы делаете это:

// explicit intent directly targeting your class
PendingIntent.getBroadcast(context, 0,
    new Intent(context, FenceDetector.MyFenceReceiver.class), 0)

Ответ 2

Я немного погулял и наткнулся на этот пост в блоге CommonsWare. В нем оговаривается сама проблема, с которой вы столкнулись.

Из вышеприведенного сообщения: -

Одна из наиболее противоречивых изменений в Android O - для приложений с достаточно высокий targetSdkVersion - это эффективный запрет на неявный трансляций.

Итак, в соответствии с этим, я не думаю, что ваша проблема имеет какое-либо отношение к API-интерфейсу Awareness. Вместо этого, это из-за нового поведения, введенного в Android 8.

К сожалению, на данный момент, похоже, не существует жизнеспособного решения. Опять же, фразы из того же поста: -

Если вы принимаете неявные трансляции, отправленные системой (например, ACTION_PACKAGE_ADDED), сохраните цель targetSdkVersion на уровне 25 или ниже, пока мы не выясним лучшие обходные пути, которые (надеюсь) не привлекают опрос.

Итак, мы надеемся, что в ближайшем будущем будет лучшее решение для 8. Между тем, вы могли бы рассмотреть другие варианты или могли бы рассмотреть вопрос о снижении целевого уровня.

Ответ 3

Ваше понимание очень правильно.

Приложения, ориентированные на Android 8.0 или более поздние версии, больше не могут регистрировать широковещательные приемники для неявных передач в своем манифесте. Неявная трансляция - это широковещательная передача, которая специально не предназначена для этого приложения.

Приложения могут продолжать регистрироваться для явных передач в своих манифестах.

Источник

Если вас интересует настроить забор, когда гарнитура подключена к. Вы можете использовать

Примечание. В настоящее время ряд неявных трансляций освобождается от этого ограничения. Приложения могут продолжать регистрировать приемники для этих трансляций в своих манифестах, независимо от уровня API, на который нацелены приложения. Список исключенных трансляций см. В Неявные исключения трансляции.

Вы можете запросить ACTION_HEADSET_PLUG в Android Manifest. В onReceive вы можете:

• запустите NotificationManager.startServiceInForeground(), чтобы вы могли выполнять работу в фоновом режиме.
• Найдите способ дублирования функциональных возможностей службы с запланированным заданием. Если служба не делает что-то сразу же заметное для пользователя, вы обычно должны иметь возможность использовать запланированное задание. См. Планировщик заданий
• Отложите фоном работу до тех пор, пока приложение не будет естественно на переднем плане.

Я бы предложил использовать комбинацию Планировщик заданий с ACTION_HEADSET_PLUG, если необходимо выполнить длительную работу.

Другой разумный, если необходимо выполнить кратковременную работу, которая в onReceive вы можете получить помощь от следующего:

A BroadcastReceiver, который использует goAsync(), чтобы отметить, что ему нужно больше времени для завершения после завершения onReceive(). Это особенно полезно, если работа, которую вы хотите заполнить в onReceive(), достаточно длинна, чтобы заставить поток пользовательского интерфейса пропускать кадр ( > 16 мс), что делает его более подходящим для фонового потока.

вы не должны запускать длинные потоки фона из широковещательного приемника. После onReceive() система может убить процесс в любое время, чтобы восстановить память, и при этом он завершает порожденный поток, выполняемый в этом процессе. Чтобы этого избежать, вы должны либо вызвать goAsync() (если вам нужно немного больше времени для обработки широковещательной передачи в фоновом потоке), либо назначить JobService из приемника с помощью JobScheduler, поэтому система знает, что процесс продолжает выполнять активные Работа.

Источник