Возможно ли иметь AccountAuthenticator и управление учетными записями в библиотеке .aar?

Question

То, что я пытаюсь сделать, - это разделить все процедуры управления учетными записями в отдельной библиотеке .aar, чтобы использовать ее во всем моем проекте. Дело в том, чтобы разделить одну и ту же учетную запись между разными приложениями. Например: я вошел в приложение A. Приложение A сохранило некоторые данные авторизации в Account Manager. Затем я устанавливаю приложение B, которое имеет тот же AAR с управлением учетной записью. Приложение B автоматически использует учетные данные, созданные в приложении A.

Для первой простой попытки я собрал все методы типа «CRUD» для AccountManager в моем AAR. Я также добавил классы AuthenticatorService и Authenticator в этот AAR и добавил свой сервис с authenticator. xml внутри манифеста AAR.

Проблема в том, что приложение, использующее мой AAR для аутентификации, не может создать Счет. Я получаю исключение "uid XXX cannot explicitly add accounts of type: com.example.acc_type".

Я дважды проверил, и типы учетных записей одинаковы в аутентификаторе. xml и в моем коде.

Что такое подробнее: если я перенесу классы AuthenticatorService, Authenticator, authenticator. xml и описание службы из AAR в приложение - все работает нормально!

Поэтому я считаю, что есть какая-то ошибка. Действительно ли возможно иметь AuthenticatorService и Authenticator в aar библиотеке?

Answer 1

Технически говоря, хранение классов AuthenticatorService и Authenticator в отдельном модуле Android -Library для повторного использования не должно вызывать каких-либо проблем при использовании его в приложении android. Ваша проблема в том, чтобы делиться данными между двумя приложениями, а не мультимодульно. Для этого вы можете создать общую локальную базу данных, используя сторонние библиотеки или простые файлы (независимо от того, что вам подходит).

Android предоставляет некоторый полезный API, который позволяет использовать IP C для приложений android:

Если размер данных невелик, вы можете использовать для этого API SharedPreferences, однако он устанавливает CAP на то, какой объем данных может предоставить приложение. Поскольку SharedPreferences является глобальным по своей природе, я бы не советовал хранить там конфиденциальные данные.

Если вы хотите, чтобы приложение предоставляло некоторые данные, то посмотрите, как архитектура android допускает каталог «Экспорт» внутри каждого приложения, где Вы можете хранить любые данные, а другие приложения могут просто читать их безопасным способом. Удаление приложения удалит все данные, присутствующие в этом каталоге «Export».