Продолжение.

FAQ

Могу ли я сделать файлы во внутреннем хранилище World-Readable или World-Writeable ?

О, $DEITY, нет. Используйте FileProvider и обслуживайте этот контент с помощью этой реализации ContentProvider. Затем вы, по крайней мере, имеете возможность использовать систему разрешений Android для управления доступом к этим файлам, в отличие от того, что любое приложение в системе может испортить эти файлы.

Ну, как насчет android:sharedUserId?

Я дам совет против этого.

android: sharedUserId — это атрибут, который вы можете поместить в манифест, который указывает логический идентификатор пользователя, который будет использоваться для вашего приложения. Любое другое приложение, которое установлено, которое подписывается одним и тем же ключом подписи и запрашивает тот же андроид: sharedUserId будет использовать одного и того же пользователя Linux с точки зрения безопасности.

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

Этот атрибут в действительности предназначен для предварительно установленных приложений, таких как набор программного обеспечения, предварительно загруженный разработчиком устройства, или ROM mod maintainer. В частности, как только вы выпускаете свое приложение, вы не можете надежно изменить свое значение android: sharedUserId, не блокируя пользователя из любых существующих файлов … поскольку Android не изменяет права собственности на существующие файлы, когда он меняет учетную запись пользователя Linux, под которой запускается приложение.

Существуют различные риски при одновременном использовании файлов несколькими процессами.

Некоторые подсистемы, такие как SQLite, имеют встроенную логику для решения этой проблемы. Но если вы сами делаете свой собственный доступ к файлу (например, через File and Java I/O), вам нужно как-то иметь дело с одновременным доступом, который может стать сложным. Вам также нужно иметь дело с тем, что происходит, когда одно приложение удаляется, удаляя файлы, которые использовало другое приложение.

В модели hub-and-spoke, например, где есть приложение и набор плагинов, возможно, это не так рискованно. В других моделях, где приложения ближе к традиционному виду, вы не можете позволить себе потерять данные своего приложения, потому что пользователь решил удалить какое-то другое приложение.

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

 

Читать ещё :   Android External Storage

Как запретить пользователям rooted устройств доступ к моим файлам во внутреннем хранилище?

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

Некоторые разработчики попытаются зашифровать свои файлы с помощью жестко запрограммированного пароля, чтобы пользователи с rooted устройствами не могли использовать эти файлы. Это создает «speed bump», но он маленький. Все, что требуется, — это один человек с интересом перепроектировать ваше приложение, определить, как расшифровать эти файлы, а затем написать сообщение в блоге или на форуме о том, как это сделать.

В целом, относительно мало людей с rooted устройствами — я оцениваю их на уровне менее 1%. ИМХО, у вас будет больше успеха, если вы сосредоточите свою инженерную работу на написании лучшего приложения, вместо того, чтобы тратить время на блокирование пользователей рутованных устройств.