Beacon Ranging с использованием фреймворка ProximityKit для Android

В случае смахивания приложения с экрана с помощью переключателя задач, возможно, обнаруживаются маяки, но уведомление по какой-то причине блокируется операционной системой. Мне было бы любопытно узнать, показывает ли LogCat какие-либо признаки приложения, если за ним следят в течение 15 минут после того, как вы проведете его с экрана. Конечно, идентификатор процесса изменится при перезапуске приложения, поэтому вам придется отфильтровать LogCat для известного шаблона журнала из приложения, а затем вернуться и отфильтровать PID, который вы видите, чтобы попытаться получить более подробную информацию о том, что продолжается.

Спасибо за ответ @davidgyoung ..

Я попытался воспроизвести и скопировать некоторые журналы, которые, по моему мнению, полезны для проверки любых признаков приложения, через 15 минут приложение удаляется из переключателя задач (журналы см. В моем отредактированном сообщении выше).

Эти строки журнала выглядят как обычная сборка мусора - я не думаю, что это означает, что приложение было приостановлено, на самом деле я думаю, что оно работает нормально. Интересно, не перезапускается ли ProximityKit при перезапуске приложения нормально. Вы можете попробовать записать строки в журнал, когда приложение вызывает pkManager.start(); и получает обратные вызовы в didSync() или didFailSync(), а также в didEnterRegion() и т. д. При устранении неполадок при автоматическом перезапуске после отключения от переключателя задач подробное ведение журнала - ваш друг.

Дэвид, просто хотел подтвердить, является ли это хорошим обходным путем для реализации настраиваемой фоновой службы, использующей методы ProximityKit, для решения проблемы, когда состояние приложения убивается из переключателя задач? Я думаю, что фреймворк ProximityKit для Android состоит из библиотеки Android Beacon, поэтому, если это решение будет реализовано, существует вероятность того, что существующая служба из ProximityKit будет работать в другой настраиваемой фоновой службе. Пожалуйста, дайте мне знать, верны ли мои предположения. Спасибо.

Настраиваемая фоновая служба должна быть в порядке, поскольку при нормальных условиях она находится в том же процессе Android, что и приложение переднего плана. Поскольку BeaconManager библиотеки Android Beacon является одноэлементным, будет один экземпляр, совместно используемый фоновым процессом и приложением переднего плана. Однако будьте осторожны с Android 8+, так как он блокирует длительные фоновые процессы.

Спасибо @davidgyoung за подтверждение решения относительно реализации настраиваемой фоновой службы. Я повторно реализовал это решение и настроил настраиваемую службу с помощью START_STICKY, так что она будет перезапущена, когда приложение будет убито из переключателя задач. Однако проблема, которую я заметил, связана с расходом заряда батареи телефона, когда он оставлен работать в течение нескольких часов.

Это может быть связано с тем, что, когда приложение убивается из переключателя задач, оно работает так же, как когда приложение работает на переднем плане, учитывая, что была реализована фоновая служба (отличается, когда приложение работает в фоновом режиме / свернуто, поскольку методы делегата запускаются каждые 5 или 15 минут в зависимости от на ОС Android).

Я также попытался добавить журналы для некоторых методов делегата ProximityKit didSync() и didFailSync(), чтобы проверить, перезапускается ли ProximityKit нормально или нет, когда приложение убивается из переключателя задач. Однако, согласно моему тестированию, связанные журналы не отображались в консоли, когда я выполнял сценарий и ждал не более 20 минут.

Еще одна проблема, о которой мы хотели сообщить, - это решить, следует ли переходить с использования инфраструктуры ProximityKit на библиотеку Android Beacon или продолжать использовать ProximityKit. Мы также слышали некоторые новости о том, что есть соображения по прекращению поддержки фреймворка ProximityKit. Для нас было бы предпочтительнее продолжать использовать ProximityKit, поскольку мы использовали портал Radius Networks при настройке маяков и добавлении некоторых атрибутов метаданных, которые обрабатывались фреймворком и необходимы для нашего варианта использования приложения.

Однако мы также открыты для перехода на библиотеку Android Beacon, если это идеальное решение для долгосрочных случаев. Было бы здорово, если бы вы могли поделиться своими мыслями по этому поводу. Спасибо, @davidgyoung!

Я ничего не знаю о планах по прекращению поддержки ProximityKit, но я не работаю в Radius Networks изо дня в день, так что эти знания на самом деле ничего не значат. Библиотека Android Beacon является открытым исходным кодом и очень широко используется по состоянию на апрель 2018 года, поэтому очень маловероятно, что сообщество с открытым исходным кодом откажется от нее в ближайшее время, даже если ее ведущий разработчик (ваш искренне) упадет со скалы.

Самое забавное в результатах ваших тестов заключается в том, что ProximityKit использует AndoridBeaconLibrary под капотом. В Android 4.3.x-7.x сама библиотека Android Beacon использует BeaconService с флагом START_STICKY. Поэтому он должен запускаться автоматически, как и ваша служба. Я ожидал, что вы увидите эту информационную строку журнала: github.com/AltBeacon/android-beacon-library/blob/master/src/‌…. Вы можете проверить свой слился ApplicationManifest.xml, чтобы узнать, есть ли у BeaconService этот флаг.

Спасибо за информацию, которую вы предоставили @davidgyoung. Я смог увидеть журнал, который вы упомянули в своем предыдущем комментарии в нашем приложении, после того, как был запущен менеджер близостиKit. Тем не менее, по-прежнему замечая, что приложение не могло определять маяки, когда приложение было убито из переключателя задач, проверенного с помощью журналов и локальных уведомлений. Я также получил копию эталонного приложения Android ProximityKit от github.com/RadiusNetworks/proximitykit-reference-android и заметил, что та же проблема возникает в этом эталонном приложении.

Дэвид, просто интересно, есть ли у вас рекомендуемые решения, кроме реализации настраиваемой фоновой службы, поскольку кажется, что это не идеальное решение, учитывая, в основном, использование батареи приложения (поскольку это будет продолжать работать в фоновом режиме в течение длительного периода времени). Или вы думаете, что это то, что можно будет рассмотреть и решить в будущих выпусках фреймворка ProximityKit? Еще раз спасибо @davidgyoung за помощь и быстрый ответ.

Ваша фоновая служба не должна использовать ЦП, если она все время спит. Это что-нибудь делает? Извините, я не могу говорить о планах на будущие релизы Proximity. Вам придется обратиться в службу поддержки Radius.