Перевод статьи о нововведениях версии мобильной операционной системы Android Q. В этой статье речь пойдет о Location Permissions — разрешениях доступа к местоположению их типах и способах предоставления.
Недавно мы увидели анонс бета-версии Android Q. В этой версии Android появилась коллекция интересных изменений, к которым нам нужно подготовить наши приложения. В этом наборе статей я собираюсь углубиться в каждую из них, чтобы мы были полностью готовы к тому, чтобы подготовить наши приложения!
Примечание. Код этой статьи можно найти здесь.
Как указано в примечаниях к бета-версии для Android Q, одним из изменений, которые мы видим, является то, как мы работаем с пользовательскими местоположениями внутри наших приложений — эти изменения влияют на доступ к местоположению как на переднем, так и на заднем плане. Это дает нашим пользователям больший контроль над тем, когда они хотят, чтобы приложения могли иметь доступ к их местоположению, что позволяет им ограничивать его только в том случае, если приложение используется в данный момент. В этой статье я хочу кратко остановиться на том, как эти изменения повлияют на приложения, а также на то, что нам нужно сделать, чтобы адаптироваться к этим изменениям.
Foreground Location Permission
Могут быть случаи, когда вашему приложению требуется доступ к местоположению пользователя во время работы на переднем плане. Например, может быть, ваше приложение обеспечивает навигацию для пользователя — как только пользователь перейдет на свой домашний экран из вашего приложения, приложение продолжит получение доступа к местоположению, чтобы продолжить обслуживание навигации. Если вашему приложению требуется доступ к этим данным о местоположении, важно сообщить пользователю, о доступе приложения к его местоположению.
Для начала, любой сервис такого рода, который использует местоположение пользователей, должен быть объявлен как сервис переднего плана местоположения. Это можно сделать, используя foregroundServiceType при объявлении службы в файле манифеста.
<service
android:name="ForegroundService"
android:foregroundServiceType="location"/>
Прежде чем мы попытаемся запустить наш приоритетный сервис, мы должны убедиться, что у нас есть на это разрешение от пользователя. Мы можем сделать это, проверив разрешение ACCESS_COARSE_LOCATION. Теперь, это не новое разрешение — на самом деле, оно существовало со времени API уровня 1. Однако раньше нам нужно было только определить его в файле манифеста приложения — теперь мы должны запросить это разрешение во время выполнения. Вы можете видеть, как это теперь дает нашему пользователю намного больший контроль над тем, как используется это разрешение.
val hasLocationPermission = ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_COARSE_LOCATION) == PackageManager.PERMISSION_GRANTED
if (hasLocationPermission) {
// handle location update
} else {
ActivityCompat.requestPermissions(this,
arrayOf(Manifest.permission.ACCESS_COARSE_LOCATION), REQUEST_CODE_FOREGROUND)
}
В этом коде выше вы можете видеть, что мы начинаем с проверки, есть ли у нас разрешение на местоположение. Если это так, мы можем продолжать обрабатывать поток местоположения или иным образом, мы должны запросить разрешение у пользователя. Если это так, то мы получим состояние разрешения в обратном вызове onRequestPermissionsResult () в нашем вызывающем классе.
Когда мы запрашиваем это разрешение, нашему пользователю будет показан следующий диалог:
Как вы можете видеть, цель разрешения была совершенно ясна — наше приложение будет иметь доступ только к их местоположению, пока находится на переднем плане (как, например, приложение используется). Если пользователь отказал в этом разрешении в какой-либо момент, и мы запрашиваем его снова, тогда ему будет показан небольшой вариант диалога:
Подобно тому, как обычно работают разрешения времени выполнения в android, мы знаем, что показан вариант, в котором пользователь может запросить повторный запрос. Из-за этой функциональности важно, чтобы вы запрашивали доступ к этому местоположению на переднем плане только в той точке, в которой он требуется. Это указывает вашему пользователю, почему разрешение требуется в текущем контексте, а не создает ощущение, что его запрашивают без причины.
Background location permission
Когда дело доходит до доступа к местоположению пользователя, когда наше приложение находится в фоновом режиме, все работает немного по-другому. Сначала нам нужно добавить новое разрешение в наш файл манифеста, это разрешение ACCESS_BACKGROUND_LOCATION. Несмотря на то, что это объявлено в манифесте, пользователь может отозвать его в любое время.
<manifest>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>
Обратите внимание, что здесь нам не нужно добавлять тип сервиса foregroundServiceType в наше объявление сервиса, потому что нам не нужно мгновенное разрешение на запуск вне нашего приложения — это фоновое разрешение уже дает нашему приложению возможность сделать это.
Как и выше, разрешение должно быть предоставлено пользователем во время выполнения. Поэтому, прежде чем мы попытаемся получить доступ к местоположению пользователей из фона, мы должны убедиться, что у нас есть необходимое разрешение от пользователя для этого. Мы можем сделать это, проверив разрешение ACCESS_BACKGROUND_LOCATION. Вы можете снова увидеть, как это теперь дает нашему пользователю гораздо больший контроль над тем, как используется это разрешение, и позволяет избежать злоупотребления доступом к фоновому местоположению.
Наш код для проверки разрешения может выглядеть примерно так:
val hasForegroundLocationPermission = ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_COARSE_LOCATION) == PackageManager.PERMISSION_GRANTED
if (hasForegroundLocationPermission) {
val hasBackgroundLocationPermission = ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_BACKGROUND_LOCATION) == PackageManager.PERMISSION_GRANTED
if (hasBackgroundLocationPermission) {
// handle location update
} else {
ActivityCompat.requestPermissions(this,
arrayOf(Manifest.permission.ACCESS_BACKGROUND_LOCATION), REQUEST_CODE_BACKGROUND)
}
} else {
ActivityCompat.requestPermissions(this,
arrayOf(Manifest.permission.ACCESS_COARSE_LOCATION,
Manifest.permission.ACCESS_BACKGROUND_LOCATION), REQUEST_CODE_BACKGROUND)
}
Вы заметите, что этот код очень похож на проверки, которые мы определили для разрешения расположения переднего плана. Здесь мы проверяем оба разрешения, что дает нам запасной вариант в поиске местоположения, если пользователь по какой-то причине отказывает нам в фоновом доступе.
Когда мы запрашиваем это разрешение, нашему пользователю будет показан следующий диалог:
Намерение разрешения было сделано довольно ясно — наше приложение сможет получить доступ к их местоположению в фоновом режиме. Если пользователь отказал в этом разрешении в какой-либо момент, и мы запрашиваем его снова, тогда ему будет показан небольшой вариант диалога:
Подобно тому, как обычно работают разрешения времени выполнения в android, мы знаем, что показан вариант, в котором пользователь может запросить повторный запрос. Из-за этой функциональности важно, чтобы вы запрашивали доступ к фоновому местоположению только в той точке, в которой он требуется. Это указывает вашему пользователю, почему разрешение требуется в текущем контексте, а не создает ощущение, что его запрашивают без причины.
Из этой статьи мы видим, что Android Q меняет способ работы наших приложений с разрешениями местоположения. Наши приложения больше не смогут свободно получать доступ к местоположениям пользователей из сервисов, будь то на переднем плане или в фоновом режиме. Для поддержки обратной совместимости, если ваше приложение не предназначено для Q, тогда разрешение ACCESS_BACKGROUND_LOCATION будет добавлено, если объявлены разрешения COARSE или FINE. Аналогично, запрос любого из двух во время выполнения также предоставит разрешение.
Эти изменения дают нашим пользователям больший контроль над тем, как приложения получают доступ к их местоположению, что позволяет нам создавать приложения с учетом конфиденциальности и безопасности пользователей. Есть вопросы об этих изменениях местоположения? Не стесняйтесь обращаться в комментариях!
Перевод источника.
