2014-06-27 2 views
0

Я достаточно искал Google, но не смог найти этот случай. Я хочу написать пользовательский поставщик контента, который является общим/доступным только для определенных приложений.Личный контент-провайдер, используемый только среди моих приложений

Я такой сценарий:

  • Есть несколько приложений на Google Play. Скажите A, B и C.
  • Хотите написать контент-провайдера, скажем Z, к которому можно получить доступ только A, B и C. Я собираюсь опубликовать Content Provider 'Z' в качестве своего собственного apk.
  • Когда Z установлен на устройстве; A, B и C может получить доступ к Z. Если Z не установлен, то первое приложение будет направлять в Google Play, чтобы установить Z.

Теперь мой вопрос:

Можно ли вообще писать такие Контент-провайдер вообще, который распространяется только на определенные приложения? android: exported = "false" делает его недоступным для любого другого внешнего приложения. android: grantUriPermissions = "true" не работает, когда android: exported установлен в false, а установка android: экспортировано в true, делает его общедоступным.

Пожалуйста, не стесняйтесь делиться другими решениями, если они кажутся более подходящими для моих потребностей в обмене информацией между несколькими приложениями.

+0

Нет, это не может быть выборочно доступны только для некоторых приложений. Вместо этого, что делает Google, а не только с ContentProviders, но и все остальное - проверяет подпись вызывающих приложений и разрешает доступ только своим приложениям. –

ответ

0

андроид: grantUriPermissions = "истина" не работает, когда андроид: экспортироваться установлен в ложном

Да, это делает.

Однако android:grantUriPermissions может не иметь отношения к вашему используемому случаю, особенно если Z является его собственным автономным приложением. Z должен быть тем, кто звонит в A/B/C, используя Intent с флагом FLAG_GRANT*, и я предполагаю, что это не соответствует вашему плану.

Если, как я подозреваю, A/B/C необходимость доступа Z независимо от Z, говоря им, что она может быть доступна и предоставления Uri Определённые разрешений, стандартный подход будет использовать пользовательский signature уровневый <permission> , Затем вы защищаете экспорт поставщика и защищаете его с помощью этого разрешения, используя android:permission в <provider>. Теория заключается в том, что только ваш пакет приложений может содержать это разрешение, потому что только ваш пакет приложений будет подписан этим ключом подписки и, следовательно, будет иметь соответствие подписи.

(я говорю «в теории», потому что есть issues with this approach)

+0

приложения, подписанные с одним и тем же сертификатом, и без каких-либо ограничений использования контента для разрешения разрешений на подпись (без использования поставщика контента)? Есть ли у вас какой-нибудь пример? Благодаря ! – bianca

+0

@bianca: Нет. Разрешения на уровне подписи не создают волшебные создания новых протоколов IPC; они просто защищают те, которые существуют. 'android: sharedUserId' позволяет приложениям, подписанным с одним и тем же ключом подписки, делиться идентификатором пользователя Linux, позволяя им напрямую читать и записывать часть внутреннего хранилища друг друга. Однако это очень хрупко. В частности, если какое-либо из ваших приложений уже отправлено, это уже не вариант для вас. – CommonsWare