Сегодня в этой статье вы познакомитесь с новой функцией системы Android 14, которая заключается в авторизации доступа к некоторым фотографиям и видео, которую также можно назвать выборочной авторизацией доступа к фотографиям и видео.
Это еще одна настройка и обновление системы Android с точки зрения конфиденциальности и безопасности с целью лучшей защиты конфиденциальности пользователей.
Но для разработчиков эта новая функция действительно усугубляет наши страдания, поэтому я объясню эту последнюю функцию, одновременно жалуясь.
Разработчики Android несчастны.
Я дам подробное введение в полную историю изменений локальных разрешений на чтение и запись системы Android от ее рождения до настоящего времени, и тогда каждый сможет сопереживать боли Android-разработчиков.
Локальные разрешения на чтение и запись относятся к способности приложения читать и записывать во внешнюю общедоступную память телефона (SD-карту).
Система Android в древние времена была очень свободной в плане разрешений.
Конечно, я никогда не использовал ни один Android-телефон той эпохи. В то время говорилось, что не было никаких ограничений на локальные функции чтения и записи. Любое приложение могло по своему желанию читать и записывать все общедоступное пространство памяти телефона.
Очевидно, что существует проблема с таким свободным дизайном разрешений, поэтому в системе Android 1.6 появилось разрешение WRITE_EXTERNAL_STORAGE.
Если вы хотите записать данные в общедоступное хранилище телефона, вы должны объявить это разрешение в файле AndroidManifest.xml вашего приложения.
Система Android 1.6 имеет ограничения только на запись в общедоступное хранилище, а чтение файлов в общедоступном хранилище по-прежнему не ограничено.
Итак, начиная с Android 4.4, Google ввел разрешение READ_EXTERNAL_STORAGE. Если вы хотите читать файлы в общедоступном хранилище, вам необходимо объявить это разрешение в файле AndroidManifest.xml.
В предыдущей системе Android, если вы хотели использовать определенное разрешение, вам нужно было только объявить его в файле AndroidManifest.xml.
Какой эффект имеет это заявление? Он сообщит пользователю, когда приложение будет установлено, и какие разрешения приложение запросило в целом. Если установка продолжится, будет считаться, что пользователь согласился со всеми этими приложениями разрешений.
Это правило действительно несколько властное, поскольку пользователи не могут частично согласиться с разрешениями, запрашиваемыми приложением.
Поэтому в системе Android 6.0 Google представила функцию разрешений во время выполнения. Некоторые крайне опасные разрешения больше не могут быть объявлены в файле AndroidManifest.xml, как раньше. Вместо этого во время работы окна приложения должны появляться только приложения-разрешения. Пользователь соглашается на авторизацию и может использовать функции, соответствующие его разрешениям.
READ_EXTERNAL_STORAGE и WRITE_EXTERNAL_STORAGE включены в объем разрешений среды выполнения.
Подробнее о среде выполнения,Можно обратиться к«Первая строка кода Android версии 3»Нет.8глава。
После введения механизма разрешений во время выполнения конфиденциальность и безопасность системы Android вышли на новый уровень, что также позволило локальным разрешениям на чтение и запись поддерживать относительно стабильное использование в течение длительного времени.
Однако, начиная с системы Android 10, Google не удовлетворился существующим положением вещей и начал проводить радикальные реформы, а частота последующих изменений ошеломляет.
В Android 10 представлен механизм Scoped Storage, и приложениям запрещено использовать абсолютные пути для доступа к общедоступному хранилищу. Таким образом, личная информация на пользовательских устройствах может быть лучше защищена.
Если приложению требуется доступ к общедоступным ресурсам, таким как фотографии, видео и аудио с мобильного телефона, оно может использовать для этого API MediaStore.
Приложение записывает общедоступные ресурсы, такие как фотографии, видео и аудио, через API MediaStore, и ему не требуется запрашивать какие-либо разрешения. Приложениям, которые используют API MediaStore для чтения общедоступных ресурсов, таких как фотографии, видео и аудио, по-прежнему необходимо подать заявку на получение разрешения READ_EXTERNAL_STORAGE.
Поскольку механизм Scoped Storage слишком сильно изменился, Google боится, что большое количество приложений не успеет адаптироваться, поэтому предоставляет атрибут requestLegacyExternalStorage. Установите для этого свойства значение true, чтобы приложение по-прежнему могло получать доступ к общедоступному хранилищу, используя абсолютные пути.
Об Андроиде Еще 10 изменений поведения, вы можете посмотреть Android 10 точек адаптации, хранилище для прицела Эта статья.
После предоставления годичного буферного периода Google считает, что большинство приложений должны были завершить адаптацию Scoped Storage, поэтому, начиная с Android 11, атрибут requestLegacyExternalStorage больше не будет работать.
Кроме того, учитывая, что некоторым приложениям типа файлового браузера необходимо использовать абсолютные пути для доступа к общедоступному хранилищу, в Android 11 добавлено разрешение MANAGE_EXTERNAL_STORAGE, но оно доступно только для определенных приложений, которым оно действительно необходимо. может быть забанен в Google Play Store. Удален с полок.
Об Андроиде 11Дополнительные изменения в поведении см. Android 11 новых функций, ограниченная область действия У хранилища есть новые трюки Эта статья.
Еще через два года Google решил, что существующие локальные разрешения на чтение и запись недостаточно безопасны.
Конкретная причина заключается в том, что разделение локальных разрешений на чтение и запись недостаточно четкое. Приложению необходимо только подать заявку на разрешение READ_EXTERNAL_STORAGE для доступа к фотографиям, видео и аудио в общедоступном хранилище мобильного телефона. Пользователи не могут авторизовать приложение с более высокой степенью детализации.
Поэтому система Android 13 отказалась от разрешения READ_EXTERNAL_STORAGE и добавила три новых разрешения времени выполнения: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO и READ_MEDIA_AUDIO, которые используются для управления доступом приложения к фотографиям, видео и аудио соответственно.
Об Андроиде 13. Дополнительные изменения в поведении см. Android 13 Список изменений разрешений во время выполнения Эта статья.
Наконец-то вышел Android 14, которому посвящена эта статья.
Чтобы лучше защитить конфиденциальность пользователей, Google добавил в систему Android 14 функцию выборочной авторизации доступа к фото и видео.
Так что же такое дополнительный грант на доступ к фотографиям и видео?
Раньше, когда приложение запрашивало разрешение READ_MEDIA_IMAGES, и если пользователь соглашался, приложение могло получить доступ ко всем фотографиям на телефоне. Пользователи не могут ограничить доступ приложения только к определенным фотографиям.
Эта новая функция, добавленная в Android 14, позволяет пользователям выбирать, разрешить ли приложению доступ ко всем фотографиям одновременно или только к нескольким конкретным фотографиям. То же самое касается видео.
На самом деле, эта функция понятна с точки зрения пользователя. Если она может лучше защитить конфиденциальность пользователя, это действительно хорошая функция.
Но с точки зрения разработчика, поскольку у системы Android слишком много исторических долгов с точки зрения локальных разрешений на чтение и запись, если ваш код хочет учитывать все сценарии, его написание может оказаться довольно громоздким.
Далее я объясню вам, как адаптироваться к выборочной авторизации доступа к фото и видео в Android 14, с помощью практической демонстрации. Насколько сложен этот код, можно понять, если мы на него посмотрим.
Чтобы объяснить это более понятно, в статье я приведу только фрагмент кода, связанного с выборочным доступом к фото и видео.
Что касается полного исходного кода Демо, то ссылку на исходный код я дам внизу статьи.
Во-первых, в Android 14 представлено новое разрешение во время выполнения, которое представляет собой выборочный доступ к фото и видео:
android.permission.READ_MEDIA_VISUAL_USER_SELECTED
Мы все знаем, что, хотя разрешения во время выполнения применяются во время работы приложения, их все равно необходимо объявить в AndroidManifest.xml.
Как вы думаете, легко ли объявить разрешение в AndroidManifest.xml? Но на самом деле, учитывая исторические проблемы Android, нам нужно написать так:
<manifest>
<!-- Devices running Android 12L (API level 32) or lower -->
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32" />
<!-- Devices running Android 13 (API level 33) or higher -->
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
<!-- To handle the reselection within the app on Android 14 (API level 34) -->
<uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" />
...
</manifest>
Это метод записи, который идеально адаптируется к локальным разрешениям на чтение и запись различных версий системы Android.
Для систем Android 12 и более ранних версий нам нужно только объявить разрешение READ_EXTERNAL_STORAGE. А поскольку начиная с Android 13 от этого разрешения отказались, необходимо добавить maxSdkVersion="32".
В Android 13 добавлены 3 новых разрешения во время выполнения, которые используются для управления доступом приложения к фотографиям, видео и аудио. В нашем примере не требуется доступ к аудио, поэтому просто объявите здесь два разрешения READ_MEDIA_IMAGES и READ_MEDIA_VIDEO.
В Android 14 добавлено разрешение READ_MEDIA_VISUAL_USER_SELECTED для выборочной авторизации фотографий и видео.
Как насчет этого, не кажется ли вам довольно громоздким просто объявить разрешения в AndroidManifest.xml?
Не волнуйтесь, все более сложное еще впереди.
Следующим шагом является запрос локальных разрешений на чтение и запись во время работы приложения. Поэтому вполне возможно, что разные версии системы требуют разных разрешений.
В настоящее время при запросе разрешений во время выполнения на Android вместо этого вы в основном используете Activity. Result API Друзья, которые не понимают эту часть, могут обратиться к этой статье. Activity Result Подробное объяснение API, пора отказаться от startActivityForResult 。
Давайте посмотрим на конкретный способ запроса локальных разрешений на чтение и запись:
private val permissionLauncher =
registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { _ ->
// Обработка результатов запроса Разрешения
}
private fun requestPermissions() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
permissionLauncher.launch(
arrayOf(READ_MEDIA_IMAGES,
READ_MEDIA_VIDEO,
READ_MEDIA_VISUAL_USER_SELECTED)
)
} else if (Build.VERSION.SDK_INT == Build.VERSION_CODES.TIRAMISU) {
permissionLauncher.launch(arrayOf(READ_MEDIA_IMAGES, READ_MEDIA_VIDEO))
} else {
permissionLauncher.launch(arrayOf(READ_EXTERNAL_STORAGE))
}
}
И здесь снова необходимо запрашивать разные разрешения в зависимости от разных версий системы.
Android 14 требует больше всего разрешений. Поскольку ему необходимо адаптироваться к функциям выборочного доступа к фотографиям и видео, ему необходимо подать заявку на три разрешения: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO и READ_MEDIA_VISUAL_USER_SELECTED.
Если у вас система Android 13, вы можете подать заявку на одну меньше. Вам нужно только подать заявку на разрешения READ_MEDIA_IMAGES и READ_MEDIA_VIDEO.
Это проще всего для систем Android 12 и ниже: просто подайте заявку на разрешение READ_EXTERNAL_STORAGE.
Эти коды оценки версий действительно раздражают, но их нужно писать вот так.
Если вы хотите полностью удалить эти коды определения версии, по крайней мере, подождите, пока ваша minSdkVersion не будет указана для Android 14 и более поздних версий. Но к тому времени кто знает, придумает ли Google какие-нибудь другие трюки.
Наконец, после запроса локальных разрешений на чтение и запись нам все равно придется оценить результат запроса разрешения. И это еще сложнее.
Чтобы избавить всех от необходимости каждый раз ломать голову над тем, как поступить с этим местом наиболее комплексно, я сразу выложу здесь код шаблона, и вы сможете его скопировать и вставить при реализации:
private fun checkPermissionResult() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU
&& (ContextCompat.checkSelfPermission(this, READ_MEDIA_IMAGES) == PERMISSION_GRANTED
|| ContextCompat.checkSelfPermission(this, READ_MEDIA_VIDEO) == PERMISSION_GRANTED)
) {
// Android 13 и выше полные фото и видео посетите Разрешения
} else if (
Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE &&
ContextCompat.checkSelfPermission(this, READ_MEDIA_VISUAL_USER_SELECTED) == PERMISSION_GRANTED
) {
// Android 14 и выше частичные фотографии и посещения Разрешения
} else if (ContextCompat.checkSelfPermission(this, READ_EXTERNAL_STORAGE) == PERMISSION_GRANTED) {
// Android Полный локальный доступ для чтения и записи для детей 12 лет и младше.
} else {
// Нет локального доступа для чтения и записи.
}
}
Видно, что результат запроса разрешения необходимо разделить на четыре ситуации, а именно:
Я знаю, что это раздражает, но это должно быть написано так. Не жалуйтесь, просто скопируйте и заберите, когда вам это понадобится.
Таким образом, адаптация избирательных прав доступа к фото и видео в Android 14 на уровне кода грубо делится на эти три этапа. Они должны объявлять разрешения в AndroidManifest.xml, запрашивать разрешения при запуске программы и, наконец, определять результаты запроса разрешений.
Но с точки зрения бизнес-процессов Google выдвинула к нам более высокие требования.
Поскольку предоставляется выборочный доступ к фотографиям и видео, возможно, что пользователи имеют только авторизованный доступ к некоторым нашим фотографиям и видео. А что, если позже пользователь захочет предоставить нам доступ к большему количеству фотографий и видео? Поэтому необходимо предоставить пользователям работоспособную опцию на уровне пользовательского интерфейса.
Лучший практический процесс, предложенный Google, выглядит следующим образом.
Как показано на рисунке, когда пользователь выбирает права доступа к некоторым фотографиям и видео, мы можем дать пользователю подсказку в верхней части интерфейса, чтобы сообщить, что фотографии и видео, отображаемые ниже, являются лишь частью выбранной пользователем авторизации. Нажмите. кнопку «Управление», чтобы перейти к интерфейсу управления, чтобы выбрать больше фотографий и видео или отозвать авторизованные фотографии и видео.
Так как же реализовать этот передовой процесс? Фактически, этого уже можно достичь с помощью примеров кода, которые я только что объяснил.
Ниже я записал демонстрацию передовой практики. Вы можете ознакомиться с конкретным процессом и эффектами.
Вы можете видеть, что если пользователь решит разрешить ограниченные разрешения, вверху всегда будет отображаться баннер, чтобы облегчить пользователю управление авторизованными фотографиями и видео.
Если пользователь решит разрешить все, баннер вверху автоматически исчезнет, как показано на рисунке ниже.
Я загрузил весь исходный код демо-версии на GitHub. Если он вам нужен, вы можете перейти по ссылке ниже:
https://github.com/guolindev/PartialAccessDemo
конечно. Ведь с таким громоздким кодом адаптации я не верю, что все приложения можно идеально адаптировать.
В лучшем случае несовместимость только помешает вашему приложению обеспечить наилучшую работу в системе Android 14.
Потому что Android 14 также может запускать в режиме совместимости приложения, которые не адаптированы для выборочной авторизации доступа к фото и видео.
Что касается работы режима совместимости, то официальный сайт Android тоже довольно сложен. Я упростил это здесь, чтобы всем было легче понять.
Режим совместимости в основном имеет следующие две ситуации:
В первом случае для targetSdkVersion вашего приложения указана версия 33 или ниже, что означает, что ваше приложение не было адаптировано для системы Android 14.
Эта ситуация очень простая. Она еще не адаптирована, и Android не предоставит вам новых возможностей. В настоящее время ваше приложение будет работать в режиме совместимости с Android 13, то есть концепция выборочной авторизации доступа к фото и видео отсутствует.
Во втором случае у вашего приложения targetSdkVersion указана версия 34 или выше, но у вас просто нет возможности выборочной авторизации доступа к фото и видео.
В этом случае система Android 14 по-прежнему может работать нормально, но вам необходимо знать несколько вещей.
Даже если вы не адаптировали функцию выборочной авторизации доступа к фото и видео, когда ваше приложение запрашивает разрешения на фото и видео, система все равно будет иметь опцию «Разрешить ограниченный доступ» в всплывающем окне подтверждения разрешения. Как показано ниже:
Если пользователь выбирает «Разрешить ограниченный доступ», он также может выборочно разрешить доступ к определенным фотографиям и видео, как в предыдущей записи экрана.
Ваше приложение будет получать обратные вызовы авторизации для двух разрешений: READ_MEDIA_IMAGES и READ_MEDIA_VIDEO, но оно может получить доступ только к фотографиям и видео, которые только что выбрал пользователь.
Когда ваше приложение закроется, авторизация для двух разрешений READ_MEDIA_IMAGES и READ_MEDIA_VIDEO будет отозвана, и вам придется подать заявку еще раз при следующем запуске, что в некоторой степени похоже на эффект однократной авторизации.
Когда вы запустите его в следующий раз, хотя у вас нет разрешений READ_MEDIA_IMAGES и READ_MEDIA_VIDEO, у вас все равно будет разрешение на доступ к фотографиям и видео, выбранным предыдущим пользователем.
Этот набор правил совместимости на самом деле довольно сложен. Это упрощенная версия, которую я скомпилировал. Изначально нам нужно было определить, заявлено ли разрешение READ_MEDIA_VISUAL_USER_SELECTED в файле AndroidManifest, и ситуация была более сложной. Я долго пытался понять эту часть, когда учился.
Если вы считаете, что приведенные выше правила совместимости сложны для понимания, то наиболее рекомендуемым подходом является адаптация к функции выборочной авторизации доступа к фото и видео в Android 14.
Хотя код адаптации действительно непросто написать, его несложно скопировать и вставить, не так ли?