Action package added android

В файле разметки activity_main.xml добавим несколько элементов для тестирования:

Перейдём к написанию кода. Создадим класс PermissionUtils, в котором будет находиться проверка разрешений и их запрос.

Затем в классе активности MainActivity.java определим элементы из разметки.

Текстовое поле будет отображать, если у приложения необходимые разрешения. Для этого после объявления переменных добавим проверку.

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

Добавим обработчик для кнопки, который будет отправлять запрос на предоставление разрешения.

Нам также необходимо задать код запроса, чтобы мы могли после определить, что ответ пришёл именно для этого запроса.

Когда пользователь нажмёт на кнопку, у него откроется новая активность с настройками приложения, в которой будет предложено дать полный доступ данному приложению. Пользователь может как согласиться, так и отклонить запрос.

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

Любой результат действий пользователя в итоге возвращается в нашу активность. Поскольку для API 30 мы запускаем отдельную активность, то результат работы мы должны отслеживать в методе onActivityResult(). Переопределим его и добавим следующий код.

Здесь мы снова проверяем, дал ли пользователь разрешение или нет, и обновляем текстовое поле в соответствии с результатом.

Аналогичным образом проверяем результат операции для старых уровней API, но здесь уже переопределяем метод onRequestPermissionResult().

Теперь у нашего приложения есть полный доступ к файловой системе, и технически этого уже достаточно. Однако если попытаться опубликовать такое приложение в Google Play, то публикацию запретят по причине отсутствия заявки на получение доступа ко всем файлам. Поэтому, после того, как в консоли будет создан выпуск и загружена туда новая версия приложения, нам нужно перейти в раздел Контент приложения и выбрать там появившийся пункт Важные разрешения и API.

В появившейся форме требуется описать подробно, зачем приложению требуется доступ ко всем файлам, относится ли это к основному функционалу приложения, а также объяснить с технической точки зрения почему невозможно использовать в приложении альтернативные способы.

Также, в случае если показать работу приложения проще, чем объяснить, можно также записать демо-ролик работы приложения, загрузить его на Youtube и прикрепить в данной форме ссылку на видео. В некоторых случаях это может ускорить получение доступа.

Итак, заполнив форму и сохранив её, можно вернуться обратно в настройку выпуска и проверить его. Предупреждение об отсутствии заявки должно пропасть и мы может отправить выпуск на публикацию. В процессе публикации Google тщательно проверит приложении, чтобы убедиться, что доступ ко всем файлам действительно необходим приложению. Как показывает практика, для приложений, представляющих собой файловые менеджеры, заявку одобрят достаточно быстро.

Когда Google одобрил доступ для приложения, новая версия успешно публикуется, а в разделе Контент приложения указано разрешение, которое было одобрено.

Однако, Google также могут и не одобрить заявку, если посчитают, что это не является обязательной функцией или если можно ограничиться MediaStore\Storage Access Framework. Здесь может помочь изменение в работе приложения либо переоформление заявки, это нужно учитывать.

Таким образом, с помощью пары строк кода можно обновить своё приложения для работы с файловой системой на новых версиях Android.

Источник

Package visibility in Android 11

On Android 10 and earlier, apps could query the full list of installed apps on the system using methods like queryIntentActivities() . In most cases, this is far broader access than is necessary for an app to implement its functionality. With our ongoing focus on privacy, we’re introducing changes on how apps can query and interact with other installed apps on the same device on Android 11. In particular, we’re bringing better scoped access to the list of apps installed on a given device.

To provide better accountability for access to installed apps on a device, apps targeting Android 11 (API level 30) will see a filtered list of installed apps by default. In order to access a broader list of installed apps, an app can specify information about apps they need to query and interact with directly. This can be done by adding a element in the Android manifest.

For most common scenarios, including any implicit intents started with startActivity() , you won’t have to change anything! For other scenarios, like opening a specific third party application directly from your UI, developers will have to explicitly list the application package names or intent filter signatures like this:

If you use Custom Tabs to open URLs, you might be calling resolveActivity() and queryIntentActivities() in order to launch a non-browser app if one is available for the URL. In Android 11 there’s a better way to do this, which avoids the need to query other apps: the FLAG_ACTIVITY_REQUIRE_NON_BROWSER intent flag. When you call startActivity() with this flag, an ActivityNotFoundException will be thrown if a browser would have been launched. When this happens, you can open the URL in a Custom Tab instead.

In rare cases, your app might need to query or interact with all installed apps on a device, independent of the components they contain. To allow your app to see all other installed apps, Android 11 introduces the QUERY_ALL_PACKAGES permission. In an upcoming Google Play policy update, look for guidelines for apps that need the QUERY_ALL_PACKAGES permission.

When targeting API level 30 and adding a element to your app, use the latest available release of the Android Gradle plugin. Soon we’ll be releasing updates to older Android Gradle plugin versions to add support for this element. You can find more information and use cases about Package Visibility in the developer documentation.

Источник

Давайте будем прямыми в своих intent

В Android 12 появится важное изменение, улучшающее безопасность платформы целиком и всех приложений, предназначенных для работы с этой версией ОС. Активити, сервисы и бродкаст ресиверы (broadcast receivers), в которых указаны интент-фильтры (intent-filters), должны явно обозначать, будут ли они доступны для других приложений или компонентов системы.

Далее перевод статьи про проблемы и решения, которые могут возникнуть при переходе на новую версию.

Ошибки

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

Решение

Обе эти ошибки можно устранить, добавив атрибут `android:exported` к каждому компоненту манифеста приложения, таким как , , или , если в них объявлены свои интент-фильтры.

Но не следует бездумно добавлять `android:exported=”true”` ко всем этим элементам. Просмотрите каждый компонент, включающий в себя и спросите себя: «Хочу ли я, чтобы любое приложение, установленное на устройстве, могло запустить этот компонент?».

Ответ на этот вопрос зависит от назначения приложения, взаимодействия с ним другого ПО и иных, более специфических условий. Ниже представлены несколько распространённых примеров интент-фильтров с рекомендуемым значением exported-атрибута и объяснением выбора.

Активити с : android:exported=”true”

Скорее всего, это MainActivity вашего приложения и поскольку лаунчер в Android может быть обычным приложением, атрибут exported необходим, иначе лаунчер не сможет запустить её.

Эта активити отвечает за обработку действия «открыть с помощью» из других приложений.

Позволяет обрабатывать контент, которым могут делиться другие приложения.

Если сервис предоставляет другим приложениям доступ к медиа-библиотеке вашего, то он должен быть экспортированным (exported), чтобы разрешить приложениям использовать эту библиотеку. Скорее всего, такой сервис, напрямую или опосредованно, наследуется от MediaBrowserServiceCompat. Если это не так, то возможно, атрибут exported необязателен.

Это сервис Firebase Cloud Messaging, он должен наследоваться от FirebaseMessagingService и не должен быть экспортированным, поскольку Firebase может запустить компонент вне зависимости от факта его экспортации. Подробности можно узнать по ссылке: Set up a Firebase Cloud Messaging client app on Android

Система может доставлять это событие в бродкаст ресивер вне зависимости от факта экспортации.

Бэкграунд

Вплоть до Android 12, активити, сервисы и бродкаст ресиверы с обозначенным интент-фильтром автоматически становились экспортированными.

Эта активити экспортирована по умолчанию:

И хотя подобное дефолтное поведение выглядит разумным, ошибка может сделать ваше приложение уязвимым. Например, приложение имеет активити для проигрывания видео:

Позже обнаруживается, что мы обращаемся к этой активити из множества разных мест в приложении, и, чтобы уменьшить связность, меняем её, включая интент-фильтр для выбора активити системой:

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

Но при таргете на Android 12 система предотвратит подобное поведение, требуя от нас явно указать значение атрибута android:exported. И поскольку в данном случае мы не хотим, чтобы активити была экспортирована — ставим атрибут android:exported = false, чтобы обезопасить приложение.

Для улучшения безопасности в Android 12 появится важное изменение. Приложения, у которых эта версия указана в target SDK, должны будут явно объявлять значение атрибута `android:exported` для любых активити, сервисов или ресиверов, которые используют интент-фильтры в AndroidManifest.xml. Без него приложение просто не установится.

Тщательно принимайте решение касательно значения этого атрибута и, если сомневаетесь — предпочитайте android:exported=”false”.

Для получения более подробной информации об интентах и интент-фильтрах смотрите Receiving an implicit intent.

О других изменениях безопасности и приватности читайте на этой странице.

Источник