Как ACCESS_BACKGROUND_LOCATION, введенный в Android Q, влияет на API-интерфейсы геозоны?

#android #android-location #android-geofence #android-10.0

#Android #android-местоположение #android-геозона #android-10.0

Вопрос:

Чтобы использовать API геозоны, пользователь должен предоставить приложение ACCESS_FINE_LOCATION . Это местоположение считается опасным и может быть отозвано в любое время; после отзыва этого разрешения приложение не сможет запрашивать обновления геозоны.

Как ACCESS_BACKGROUND_LOCATION разрешение вписывается в эту картину? Мы точно знаем, что это разрешение также опасно и может быть отозвано в любое время. Означает ли это, что если мы хотим зарегистрировать некоторые IntentService из них для вызова каждый раз, когда происходит изменение геозоны, мы также должны убедиться, что пользователь предоставил ACCESS_BACKGROUND_LOCATION разрешение? Или нам нужно использовать это разрешение, только если мы пытаемся получить текущее местоположение в нашей собственной фоновой службе / BroadcastReceiver?

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

Ответ №1:

Документация API геозон теперь обновлена, и нам нужно определить ACCESS_BACKGROUND_LOCATION , как отслеживать геозоны, если мы нацелены на Android Q

Из документа:

Чтобы использовать геозону, ваше приложение должно запросить ACCESS_FINE_LOCATION. Если ваше приложение предназначено для Android 10 (уровень API 29) или выше, ваше приложение также должно запросить ACCESS_BACKGROUND_LOCATION.

Ответ №2:

Я предполагаю, что раздел «Перерегистрируйте геозоны только при необходимости«:

Зарегистрированные геозоны сохраняются в com.google.process.location процессе, принадлежащем com.google.android.gms пакету.

будет заключаться в том, что он на самом деле не нужен, как com.google.process.location и должен быть тот, кто получает данные о местоположении (поэтому тому, кто должен запрашивать ACCESS_BACKGROUND_LOCATION разрешение).

При этом, следуя этой логике ACCESS_FINE_LOCATION , разрешение не требуется. Тот факт, что это необходимо, может быть вызван двумя причинами (я не знаю реальной причины):

  • проверяется либо при регистрации геозоны, либо при получении местоположения уведомления,
  • или что это разрешение проверяется службами Google Play, чтобы запретить приложению обходить отсутствие разрешения на местоположение, используя службы Play в качестве прокси-процесса для получения информации.

Для меня второе предположение имеет больше смысла, а это означает, что даже когда технически приложение не будет нуждаться в (процесс получения местоположения — это служба воспроизведения), это требуется по соображениям конфиденциальности / безопасности.

Следуя этой логике, Google должен (будет?) также применяйте ACCESS_BACKGROUND_LOCATION , как для обеспечения конфиденциальности / безопасности пользователя, так и для снижения потребления батареи.

Комментарии:

1. Да, мое мышление было точно таким же: с одной стороны, работа, связанная с геозонами (которая требует разрешений), выполняется в отдельном процессе, следовательно, разрешение на фоновое местоположение не требуется; с другой стороны ACCESS_FINE_LOCATION , разрешение, тем не менее, требуется.

Ответ №3:

В бета-версии 4 добавление геозоны, когда ACCESS_BACKGROUND_LOCATION не разрешено, даже когда приложение полностью находится на переднем плане, завершается ошибкой с кодом состояния 13 («ошибка»).

Ответ №4:

Для использования ACCES_BACKGROUND_LOCATION требуется API Android 10 уровня 29