Access background location android

Исследование Android Q: Location Permissions

Перевод статьи о нововведениях версии мобильной операционной системы Android Q. В этой статье речь пойдет о Location Permissions — разрешениях доступа к местоположению их типах и способах предоставления.

Недавно мы увидели анонс бета-версии Android Q. В этой версии Android появилась коллекция интересных изменений, к которым нам нужно подготовить наши приложения. В этом наборе статей я собираюсь углубиться в каждую из них, чтобы мы были полностью готовы к тому, чтобы подготовить наши приложения!

Примечание. Код этой статьи можно найти здесь.

Как указано в примечаниях к бета-версии для Android Q, одним из изменений, которые мы видим, является то, как мы работаем с пользовательскими местоположениями внутри наших приложений — эти изменения влияют на доступ к местоположению как на переднем, так и на заднем плане. Это дает нашим пользователям больший контроль над тем, когда они хотят, чтобы приложения могли иметь доступ к их местоположению, что позволяет им ограничивать его только в том случае, если приложение используется в данный момент. В этой статье я хочу кратко остановиться на том, как эти изменения повлияют на приложения, а также на то, что нам нужно сделать, чтобы адаптироваться к этим изменениям.

Foreground Location Permission

Могут быть случаи, когда вашему приложению требуется доступ к местоположению пользователя во время работы на переднем плане. Например, может быть, ваше приложение обеспечивает навигацию для пользователя — как только пользователь перейдет на свой домашний экран из вашего приложения, приложение продолжит получение доступа к местоположению, чтобы продолжить обслуживание навигации. Если вашему приложению требуется доступ к этим данным о местоположении, важно сообщить пользователю, о доступе приложения к его местоположению.

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

Источник

Подготовка приложения к Android Q. Часть 1

Перевод статьи подготовлен специально для студентов курса «Android-разработчик. Базовый курс». Также напоминаем о том, что мы продолжаем набор на расширенный курс «Специализация Android-разработчик»

Мы находимся на 10-м году разработки Android (Android Q должен быть версией 10.0). В соответствии с Beta 4, официально у Android Q 29-й уровень API. Несмотря на то, что уже есть Beta 5 и ожидается Beta 6, API был помечен как окончательный, и сейчас самое время посмотреть, как Android Q повлияет на приложения и какие изменения нужно внести, чтобы полностью поддерживать Android Q.

Важные изменения (не все), представленные в Android Q, можно разделить на две категории: а) Конфиденциальность и безопасность, б) User Experience.

От переводчика: «Мы разделили перевод на две части соответствующие данным категориям. Соответственно в первой части поговорим о конфиденциальности и безопасности».

1) Конфиденциальность и безопасность

а) Запуск фоновых Activity

Больше нельзя запустить Activity, когда ваше приложение находится в фоновом режиме.

• На что влияет: Все приложения, работающие на Q (независимо от целевого SDK). Генерируется исключение, если Android Q — целевая версия приложения; и Activity просто не запустится, если Android Q — не целевая версия SDK для приложения, но оно работает на устройстве с Android Q.
• Исключения: Привязанные службы, такие как специальные возможности, автозаполнение и т. д. Если приложение получает PendingIntent от системы, мы можем использовать его для запуска Activity. Если у приложения есть разрешение SYSTEM_ALERT_WINDOW (удалено в Android GO) или приложение недавно вызывало finish() для Activity (не рекомендуется на это полагаться. «Недавно» может быть очень неоднозначным), тогда ваше приложение свободно от этого ограничения.
• Рекомендуемый подход: Уведомление, запускающее Activity

Добавьте Fullscreen PendingIntent к уведомлению. Теперь, когда уведомление сработает, система запустит полноэкранный Intent.

Поэтому, если мы хотим запустить Activity из фонового режима, сначала создайте уведомление, которое будет показываться пользователю. В этом уведомлении добавьте Fullscreen PendingIntent . Кроме того, добавьте разрешение USE_FULL_SCREEN_INTENT в свой манифест. Теперь, когда уведомление сработает, система запустит полноэкранный Intent.

• Подводные камни: Система решает, когда показывать уведомление и когда показывать Activity. Если пользователь активно использует устройство, то отображается всплывающее уведомление. Если устройство в состоянии покоя или когда пользователь взаимодействует с уведомлением, запускается полноэкранное Activity. Например, как при получении телефонного звонка (всплывающие уведомления во время использования телефона, в противном случае полноэкранное Activity).

б) Аппаратные идентификаторы

Доступ к несбрасываемым идентификаторам устройства был отменен в Android Q.

• На что влияет: Все приложения, работающие на Q (независимо от целевого SDK). Генерируется исключение, если Q — это целевое SDK; и возвращается null , если целевое SDK меньше Q
• Избегайте: Mac-адрес теперь рандомизирован, а IMEI ( TelephonyManager.getDeviceId() ) и серийный номер больше не доступны. Теперь они являются «привилегированными разрешениями» и доступны только для приложений операторов.
• Рекомендуемый подход: используйте сбрасываемые идентификаторы, такие как Advertising ID, Instance ID или Globally-unique ID (GUID). См. Best practices for unique identifiers (Лучшие практики по использованию уникальных идентификаторов) для получения дополнительной информации о том, какой идентификатор использовать в каком случае.

в) Фоновое определение локации

Начиная с Android Q, система будет различать запросы местоположения, сделанные на переднем плане и в фоне.

Запрос на разрешение доступа к местоположению теперь будет иметь 3 варианта: Разрешать все время, Разрешать только при использовании приложения (доступ только на переднем плане) и Запретить (нет доступа).

• На что влияет: Это зависит от целевого SDK. Если Q — это целевое SDK для приложения, то вам нужно запросить новое разрешение на определение местоположения в фоновом режиме. Если у приложения другое целевое SDK, оно автоматически получит это разрешение, если уже имело права доступа к местоположению.

Изображение взято из документации для разработчиков Android

• Рекомендуемый подход: если приложению требуется однократный доступ к местоположению пользователя для выполнения некоторых задач, используйте службу переднего плана с параметром foregroundServiceType, заданным как location в файле манифеста приложения.

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

Запрос доступа к местоположению в фоновом режиме

Напоминание, показываемое системой, о доступе к местоположению в фоновом режиме

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

На этом первая часть статьи подошла к концу.А о User Experiences, как и обещали, поговорим во второй части.

Источник

Android 10 (Q) ACCESS_BACKGROUND_LOCATION permission

I need the user to check and set permission to ACCESS_BACKGROUND_LOCATION («Allow all the time») without the option to «Allow only while using the app». My GPS Tracking app needs to continue accessing location even when the application is minimised.

I have already permissions working for ACCESS_FINE_LOCATION for Android 9.

I need the only permission option to be «Allow all the time» if possible. How do I set this up when checking and setting permissions?

2 Answers 2

For Android 10, if:

• You omit ACCESS_BACKGROUND_LOCATION , and:
• You use a foreground service with the android:foregroundServiceType=»location» property set in the manifest, then:

The system will supply only the «Allow only while using the app» and «Deny» options to the user, in reference to the location permission.

I realize that’s the exact opposite of what you asked for, but the point is, under this condition, «Allow only while using the app» effectively behaves like «Allow all the time», provided the aforementioned foreground service is running.

You will be able to receive location updates even when the app is offscreen. And the user does not have the option of only partially allowing location updates; they have to choose between fully allowing it, or fully denying it.

EDIT

This answer also assumes your targetSdkVersion is 29.

Источник

Android activity cannot resolve symbol ACCESS_BACKGROUND_LOCATION

I am trying to check permission for access to background location.

I have already visited this Cannot resolve Manifest.permission.ACCESS_FINE_LOCATION and I have examined all the provided solutions. None of them solved my issue.

Here is my code in Manifest file:

and here is how I am trying to check the permission:

I am getting this error:

Any thoughts would be appreciated.

1 Answer 1

I found the answer to my own question. So I am posting it here in case somebody else has the same problem.

Basically I was trying to ask permission for a background location tracking. It turned out that asking for permission is a requirement only if you have upgraded your app to work with Android 10 (Android Q). To check if your app needs permission, simply go to build.gradle file and check your targetSdkVersion. If it is anything below 29, like in my case which is 27, then you don’t need to check permission for background location tracking. However, it is a good practice to upgrade your app to work with Android 10 by setting your targetSdkVersion to 29 and upgrading all your dependencies.

To some up this answer, I couldn’t get ACCESS_BACKGROUND_LOCATION simply because the android.Manifest doesn’t support that permission if you have not upgraded your app to sdk 29. For more information consider visiting the following page: https://developer.android.com/about/versions/10/privacy/changes

NOTE: As indicated by @LordParsley’s comment:

• Changing compileSdkVersion (not just targetSdkVersion ) is needed.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.12.3.40888

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

ACCESS_BACKGROUND_LOCATION permission has issue when API less than Android Q #646

Comments

TankJK commented Oct 25, 2019

Overview

ACCESS_BACKGROUND_LOCATION is not handled for Android API less than 29.

• Describe the issue briefly

Compile and target SDK 29
From Android Q, special permission is required for accessing location in background. This did works well for Android Q but when its less than Android Q, even though user has given Allow permission for location, it consider failure (deny) for ACCESS_BACKGROUND_LOCATION

Expected

What is the expected behavior?

When Android API less than 29, when user has given Allow permission for location, it should consider success for ACCESS_BACKGROUND_LOCATION.

Actual

What is the actual behavior?

When Android API less than 29, when user has given Allow permission for location, it consider failure (deny) for ACCESS_BACKGROUND_LOCATION.

Environment

Which library version are you using?
4.5.0

On which devices do you observe the issue?
All which has OS less than 29.

Note any other information that might be useful

Reproducible steps

• While it’s not required, it’d be perfect to add a link to a sample project where you encounter the issue

Thanking you in advance,
TankJK

The text was updated successfully, but these errors were encountered:

hotchemi commented Oct 25, 2019

@TankJK I’m afraid it’s not related to our library. Have you tried below?

TankJK commented Oct 25, 2019

@hotchemi Yes all permission is been added.

hotchemi commented Oct 25, 2019

@TankJK really? I wonder because ACCESS_BACKGROUND_LOCATION is from API level 29?

TankJK commented Oct 25, 2019

@hotchemi App all permission:
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
ACCESS_BACKGROUND_LOCATION

If it’s API below 29, simply Allow should give all three permissions. While in 29, users have 2 choices:

1. While using app (which is ACCESS_FINE_LOCATION)
2. Allow all the time (which is ACCESS_FINE_LOCATION + ACCESS_BACKGROUND_LOCATION)

But problem occurs when API is less then 29 as described in issue.

hotchemi commented Oct 28, 2019

we’ll take a look

hotchemi commented Oct 28, 2019

@TankJK thank you we could replicate the issue.

Actually the root cause is ACCESS_BACKGROUND_LOCATION doesn’t exist but you request the permission to Android and it always return -1(DENIED). Kind of obvious but this can be an improvement point for our library, let us think a bit.

A quick workaround is like below on your side.

lumina0o0 commented Apr 2, 2020

I also encountered the same problem

This permission is added after api29 and cannot be run in lower versions
Looking forward to your updates

wilder-ness commented Apr 10, 2020

多的这个权限回调在哪执行 OnPermissionDenied 这个会生成2组回调么 我这里 只生成了一组

prash6001 commented Apr 20, 2020

@TankJK thank you we could replicate the issue.

Actually the root cause is ACCESS_BACKGROUND_LOCATION doesn’t exist but you request the permission to Android and it always return -1(DENIED). Kind of obvious but this can be an improvement point for our library, let us think a bit.

A quick workaround is like below on your side.

Источник