Content Provider я выделил отдельно вот по какой причине. У него в отличие от других компонентов есть несколько интересных моментов касательно установки разрешения. Так как Content Provider это основной компонент на него, как и на другие можно навесить обычное разрешение. Устанавливаем такое, и теперь только приложение с нужным разрешением сможет получить от нас какие-либо данные. Помимо этого можно
exported сделать false и Content Provider получится приватным и только ваше приложение сможет его использовать. Тут все как у всех других компонентов ничего интересного.Помимо обычного разрешения Content Provider позволяет настроить более точечную настройку разрешений. Есть возможность поставить разрешение, отдельно на запись и отдельно на чтение данных. Например, можно не задавать разрешение на чтение данных и позволить любому приложению читать данные, и при этом поставить signature разрешение на запись данных, тем самым разрешив модифицировать данные только определенным приложениям. Тут тоже все понятно и очевидно.
И самое интересное и запутанная хрень в Content Provider это
grantUriPermissions. Лучше всего объяснить на примере. Смотрите, возможно вам когда-либо выпадала задача показать pdf файл в любом другом приложении. Этот файл доступен только вашему приложению, т.е он не лежит в открытой публичной папке. И вот каким образом дать разрешение другому приложению конкретно вот на этот файл?Если вы пойдете на stackoverflow, там будет дикий запад с костылями про то, как это сделать. Поискав чуть лучше, можно будет найти FileProvider. Суть проста, FileProvider это частный случай Content Provider который работает только с файлами. А нужен он для того, чтобы вы могли раздавать свои приватные файлы другим приложениям.
Идея тут должна быть понятна, мы не можем перегнать весь файл в bundle и отправить его в другое приложение, мы можем другому приложению передать только путь до нашего файла. Однако, что другое приложение сможет сделать с этим путем? Да ничего, система пошлет его лесом как только он попробует по этому пути перейти. А вот FileProvider позволяет легально обойти это ограничение.
Если вы зайдете в доку FileProvider, там будет сказано, что вам нужно сделать этот провайдер как
exported=false. И тут внимательный читатель задастся вопросом: “Если exported=false то как он вообще что-то может передать другому приложению, ведь провайдер становится приватным“. Все так и есть, FileProvider делается приватным, однако мы также указываем grantUriPermissions=true и вот тут, начинается самое интересное. GrantUriPermissions это настройка, которая позволяет другим приложениям выдавать временный доступ до конкретного Uri (если говорим про FileProvider то условно путь до файла). Однако работает она не сама по себе, мы должны явно сообщить об этом системе, и тут два пути:👉 Первый это когда мы формируем Intent на показ файла, нужно добавить флаг ‘FLAG_GRANT_READ_URI_PERMISSION’ и приложение, которое получит этот Intent получить также право временно(до перезагрузки устройства) обращаться к переданному Uri(к нашему файлу).
👉 Второй, мы можем программно вызывать метод
grantUriPermission, передать в него наш Uri а также пакет конкретного приложения, которому мы это права даем. Ну и есть зеркальный метод revokeUriPermission, который это разрешение отзывает.Ну я думаю логика должна была сложиться к голове как это все работает. Если кстати навесить еще и разрешение на FileProvider, то даже несмотря на
grantUriPermission, приложение, которое хочет получить наши файлы должно обладать еще и этим разрешением.Однако это не все самое прикольное. Я обнаружил интересную толи багу, толи фичу связанную с FLAG_GRANT_READ_URI_PERMISSION, о которой расскажу в следующем посте.