Android IPC и ContentProvider различия - PullRequest
Новая
       12

Android IPC и ContentProvider различия

7 голосов
/ 30 июня 2011

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

IPC - Pro's

  • Гибкие типы ответов клиенту. Могут быть возвращены различные коды ошибок и уровни ограниченного доступа

МПК - Con's

  • Сложнее в реализации, чем поставщик контента

  • Придется написать собственный способ защиты доступа к контенту.

Контент-провайдер - Pro's

  • Простота реализации

  • Простой в доступе доступ с определением разрешения провайдера: protectionLevel = подпись

Контент-провайдер - Con's

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

  • Ограниченная гибкость в возвращаемых типах результатов. Поставщик контента возвращает только объект Cursor для запрашиваемых столбцов.


Есть ли какие-либо существенные различия в производительности и аккумуляторе?
Можно ли выполнить асинхронно?
Любые другие комментарии / предложения к списку?

Ответы [ 2 ]

4 голосов
/ 30 июня 2011

Простой и безопасный доступ благодаря разрешению определения поставщика: protectionLevel = подпись

Это работает, только если вы являетесь единственной фирмой, использующей контент-провайдера.

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

Я бы описал это как «может соответствовать медицинскому определению« безумия »».Ваши третьи лица смогут изменять ваши «защищенные» данные, подделывать приложения, которые были опубликованы вами, передавать ваш ключ подписи авторам вредоносных программ и т. Д.

Content Provider возвращает только объект Cursor длястолбцы, которые были запрошены.

Вы можете использовать API поставщика содержимого на основе файлов в дополнение или вместо API поставщика содержимого на основе Cursor.См. Методы, такие как openInputStream() на ContentResolver.

Существуют ли какие-либо существенные различия в производительности и аккумуляторе?

Не особенно.

Может ли выполняться асинхронно?

Оба могут, хотя лично я нахожу это немного проще с услугами.

Любые другие комментарии / предложения к списку?

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

0 голосов
/ 23 апреля 2017

Я не могу ответить на ваш полный вопрос, но могу обратиться к разделу обмена ключами.Ваш APK подписан с открытой частью вашей пары открытый / закрытый ключ.Может быть возможно прикрепить ваш открытый ключ к другому приложению, чтобы представить себя вашим приложением, но кому-то понадобится ваш личный ключ для загрузки приложения на ваше имя с использованием вашего открытого ключа.

« Сертификат открытого ключа, также известный как цифровой сертификат или сертификат идентификации, содержит открытый ключ пары открытый / закрытый ключ, а также некоторые другие метаданные, идентифицирующие владельца ключа (например, имяи местоположение).Владелец сертификата владеет соответствующим закрытым ключом.

Когда вы подписываете APK, инструмент подписи присоединяет сертификат открытого ключа к APK.Сертификат открытого ключа служит «отпечатком», который однозначно связывает APK с вами и вашим соответствующим закрытым ключом.Это помогает Android гарантировать, что все будущие обновления вашего APK являются подлинными и исходят от оригинального автора. ”

(от https://developer.android.com/studio/publish/app-signing.html)

Также,насколько я понимаю, другие приложения делятся своими ключами с вашим приложением, а не наоборот.Защита уровня подписи также не требуется, если вы можете использовать одну из других настроек.В соответствии с https://developer.android.com/guide/topics/manifest/permission-element.html#plevel вы можете выбрать для приложения один из 4 различных уровней защиты.Большинство приложений не содержат данных, которые являются достаточно чувствительными, чтобы требовать установки «опасного», поэтому нормальное будет работать для большинства приложений.

Кроме того, подпись (открытый ключ) вашего приложения уже предоставляется с помощью методов, доступных вкласс PackageManager.Я внимательно просмотрел страницы разработчиков Android и прочитал очень полезный ответ на другой пост, чтобы найти это.Похоже, что любое приложение может получить открытый ключ вашего приложения с помощью метода, описанного здесь Уровень защиты поставщика контента Android и различные ключи от CommonsWare.

...