AccountManager
Иногда разработчик хочет отслеживать пользователя. Первый вариант, который приходит в голову — попросить его ввести какие-то данные о себе и сохранить их где-нибудь. Но просить пользователя повторять эту процедуру при покупке нового устройства не самая лучшая идея. Кроме того, вы не можете гарантировать уникальность данных. Второй вариант — запомнить идентификатор телефона. Но пользователи иногда пользуются двумя телефонами, планшетами и т.д. и тут одним идентификатором не обойдёшься. Опять проблема.
Третий вариант – использовать класс AccountManager. С разрешения пользователя, вы можете использовать AccountManager для извлечения имён учетных записей, которые пользователь хранит на устройстве. Имея полученную информацию, вы можете, например, автоматически заполнить форму с адресом электронной почты.
Само устройство может хранить несколько аккаунтов от разных сервисов. Вы можете отфильтровать результат по типам аккаунтов. Например, у Гугла аккаунт имеет тип «com.google», Twitter использует тип «com.twitter.android.auth.login».
Для извлечения информации требуется разрешение:
В приложении вы сначала получаете экземпляр AccountManager через метод get(), а затем можете вызвать список аккаунтов определённого типа через getAccountsByType().
Метод getAccountsByType() возвращает массив учётных записей. Если в массиве более одной учётной записи, то покажите пользователю диалоговое окно с запросом для выбора одного аккаунта.
Объект Account содержит имя учетной записи, для учетных записей Google – это адрес электронной почты, который вы можете использовать для автоматического заполнения полей или в качестве ключа в базе данных и т.д.
В других учётных записях в имени не обязательно может содержаться электронный адрес. Например, это может быть часть электронного адреса или просто имя пользователя.
На эмуляторе скорее всего нет никаких аккаунтов, поэтому лучше проверять на устройстве. В большинстве случаев на телефоне есть аккаунт для Гугла. В логах я проверил количество аккаунтов, а в текстовом поле вывел имя аккаунта, который оказался моим электронным адресом.
Метод getAccounts() выводит все учётные записи, которые есть на устройстве.
На моём устройстве оказалось три учётные записи. Чтобы понять, кому они принадлежат, я заменил account.name на account.toString() и получил следующий результат.
Теперь стало понятно.
Мы рассмотрели только базовый пример работы с AccountManager. На самом деле, у класса много других возможностей. Например, вы можете добавить новую учётную запись и управлять ею.
Источник
Account manager андроид что это
Новые темы необходимо создавать только в корневом разделе! В дальнейшем они будут обработаны модераторами.
Если Вы выложили новую версию программы, пожалуйста, сообщите об этом модератору нажав на вашем сообщении кнопку «Жалоба».
Account Manager
версия: 3.3.1
Последнее обновление программы в шапке: 27.06.2016
Краткое описание:
Учетная запись Sony Entertainment Network со всеми приложениями.
Описание:
С помощью Account Manager можно использовать одну учетную запись Sony Entertainment Network со всеми приложениями на устройстве, для которого нужна учетная запись Sony Entertainment Network.
После установки свяжите учетную запись Sony Entertainment Network с устройством любым из следующих способов:
— выполните вход в одно из поддерживаемых приложений
— перейдите к меню [Настройки] > [Аккаунты], а затем выберите [Добавить аккаунт] на устройстве Android.
После связывания учетной записи можно выполнять вход в любое поддерживаемое приложение без повторного ввода данных учетной записи.
Если вы уже являетесь пользователем PlayStation™Network или Qriocity, вы можете использовать существующую учетную запись в качестве учетной записи Sony Entertainment Network.
Требуется Android: 3.1 и выше
Русский интерфейс: Да
Источник
Уязвимость Account Manager в Android, о которой необходимо знать
Приветствую тебя, дорогой читатель! Многие разработчики используют возможности Account Manager(AM) в своих приложениях. И правильно делают, ведь этот инструмент позволяет упростить некоторые вещи. Он позволяет хранить пароль, токен, да и в принципе любые строковые данные юзера. Так же позволяет автоматически обновлять токен, если тот протухает, и много других полезных штук. Но у этого удобства есть и другая сторона — безопасность. Из-за этого собственно я и написал данный текст.
Раз AM позволяет хранить такие важные данные как пароль и токен, то наверно он просто обязан это делать безопасно, ведь если они утекут, то ничего хорошего не получится. Вы можете сказать, что на рутованых андроид девайсах ничто не хранится безопасно, и я тут соглашусь. Однако если бы все ограничивалось только рутом, то не читать бы вам сие «произведение». Чтобы рассказать, ради чего мы тут собрались, я начну с самого начала.
Вообще для работы с AM в приложении нужно сделать несколько телодвижений и создать два компонента — наследника AbstractAccountAuthenticator и Service (подробней тут). Последний придется зарегистрировать в манифесте приложения таким образом:
А еще, если вы заметили, то нам надо создать в ресурсах некий xml-файл с именем authenticator.xml. Хотя название тут не важно, а важно содержимое. Оно то и играет ключевую роль рассказа. Выглядит файл внутри вот так:
Параметр label — отвечает за название в списке аккаунтов в настройках девайса, а самое интересно несет в себе accountType. Без него приложение не сможет добавлять и получать аккаунты. А еще с помощью этого параметра можно перехватить аккаунты другого приложения даже на девайсах без рута. Давайте посмотрим, как это может произойти.
На устройстве существует приложение А с accountType = «someType», это приложение создает акаунт, добавляет в него токен, пароль и прочую информацию. В один прекрасный момент на устройство устанавливается приложение B с таким же accountType = «someType». И вот если удалить приложение A, то все созданные аккаунты перейдут во власть приложения B с полным доступом. Обратное тоже верно, аккаунты приложения B передадутся приложению A, если удалить B.
Опережая вопросы про подписи apk, это не зависит от того, каким ключом было подписано приложение, релизным или дебажным, передача произойдет в любом случае. Ужасно, правда?
Все это можно проделать в плоть до API версии 23. Исправлено только с выходом андроид 7.0(API 24). Печалит в этой ситуации ничтожно малый процент устройств с этой версией андроида. Кстати, узнал я об этой проблеме из доклада по безопасности в андроид. К сожалению в тексте, пересказе презентации, об этом ничего нет вообще, а вот в видео об этом упомянули вскользь, не придав особого значения.
Так же что же ты предлагаешь? — можете спросить вы. А я предлагаю вам два варианта решения проблемы. Первый — продолжать пользоваться AM, но хранить в нем все важные данные в зашифрованном виде. Если вы перестали доверять AM, можно продолжать им пользоваться, но не хранить в нем важные данные и воспользоваться AM в связке со вторым вариантом. Второй — вообще отказаться от AM и пользоваться хранилищем, которое можно шифровать. Например SQLite в связке с sqlcipher или Realm, который поддерживает шифрование из коробки. Я выбрал последний. Тут пример для realm, где показано, как генерировать и хранить ключ шифрования.
Примеры кода в статье приводить не стал, так как в этом нет смысла. С исходниками жертвы и перехватчика вы сможете ознакомиться на гитхабе.
Источник
Для чего нужно использовать AccountManager для Android?
Я видел AccountManager в Android SDK и что он используется для хранения информации об учетной записи. Таким образом, я не могу найти общего обсуждения того, для чего он предназначен. Кто-нибудь знает о каком-либо полезном обсуждении того, что представляет собой замысел AccountManager и что он покупает? Любые мнения о том, для каких типов учетных записей это подходит? Будете ли вы размещать информацию об учетной записи своего пользователя для общего веб-сервиса?
Этот вопрос немного устарел, но я думаю, что он по-прежнему представляет большой интерес.
AccountManager , SyncAdapter и SyncAdapter идут вместе.
- У вас не может быть SyncAdapter без Account в AccountManager .
- У вас не может быть SyncAdapter без SyncAdapter .
- Используйте ContentProvider без других.
- Используйте AccountManager без других (но вы не можете использовать AccountManager без SyncAdapter перед Android 2.2 / Froyo API 8)
С AccountManager / SyncAdapter / SyncAdapter :
- AccountManager предоставляет пользователям центральную точку (Настройки> Учетные записи) для определения своих учетных данных
- Android решает, когда синхронизация может быть выполнена через SyncAdapter . Это может быть полезно для оптимизации батареи (например, синхронизация не выполняется, когда сеть отключена)
- ContentProvider – удобный способ обмена данными между приложениями. Примечание. Существуют другие методы межпроцессного взаимодействия на Android .
ContentProvider планирует доступ к базе данных в фоновом потоке. AsyncQueryHanlder помогает запрашивать ContentProvider в фоновом потоке, предотвращая ошибки Application Not Responsive (ANR), не требуя от вас явно обрабатывать потоки.- ContentResolver с наблюдателем ContentResolver : это означает, что легко уведомлять представления при изменении содержимого
Итог : структура AccountManager / SyncAdapter / SyncAdapter помогает, если вы хотите синхронизировать данные с веб-ресурса. Для API 7 требуются поддельные / немые реализации . Также
- Если вы хотите хранить данные, вам следует рассмотреть более простой механизм хранения данных
- Если вам нужен только один ресурс, вы можете использовать AsyncTaskLoader
- Если вы хотите загружать изображения асинхронно, вы можете использовать специализированные библиотеки, такие как Square Picasso
- Если вы хотите только выполнить какой-либо код в определенный момент времени, вы можете рассмотреть Сервис / Тревога
- Доступный только от API> = 7 (это уже не имеет значения)
Наконец, если вы используете SyncAdapter , серьезно подумайте о Firebase Cloud Messaging (ранее Google Cloud Messaging), а также «push notifications», чтобы иметь более свежие обновления и оптимизированное использование батареи.
Класс AccountManager интегрирован с вашими учетными записями телефона. Поэтому, если вы будете следовать всем руководствам и работать правильно, вы увидите свои учетные записи в меню «Настройки-> учетные записи и синхронизация». Оттуда вы можете их настроить или удалить. Кроме того, у AccountManager есть кеш аутентификационных билетов для ваших учетных записей. Это также можно использовать, если вы не планируете синхронизировать свою учетную запись (насколько я знаю).
Если вы не хотите, чтобы ваши учетные записи отображались в этом меню, вы не должны использовать AccountManager и хранить данные учетных записей в другом месте (возможно, в общих настройках). http://developer.android.com/guide/topics/data/data -storage.html
Первая часть головоломки называется Аутентификатором учетной записи, которая определяет, как учетная запись пользователя появится в настройках «Учетные записи и синхронизация». Для реализации Аутентификатора учетной записи требуется 3 части: служба, которая возвращает подкласс AbstractAccountAuthenticator из метода onBind, действие, предлагающее пользователю ввести свои учетные данные и файл xml, описывающий, как ваша учетная запись должна выглядеть при отображении пользователю. Вам также нужно будет добавить разрешение android.permission.AUTHENTICATE_ACCOUNTS на ваш AndroidManifest.xml.
AccountManager хорош по следующим причинам:
- Во-первых, хранить несколько имен учетных записей с различными уровнями доступа к функциям приложения под одним типом учетной записи. Например, в приложении для потоковой передачи видео могут быть два имени учетной записи: один с демо-доступом к ограниченному числу видео, а другой с полносетевым доступом ко всем видео. Однако это не основная причина использования Accounts , так как вы можете легко управлять этим в своем приложении без необходимости в этой причудливой учетной Accounts ….
- Другим преимуществом использования Accounts является избавление от традиционной авторизации с именем пользователя и паролем каждый раз, когда пользователь запрашивает авторизованную функцию, поскольку проверка подлинности происходит в фоновом режиме, и пользователю предлагается ввести пароль только в определенных условиях, Который я получу к нему позже.
- Использование функции Accounts в android также устраняет необходимость в определении собственного типа учетной записи. Вероятно, вы сталкивались с приложениями, использующими учетные записи Google, для авторизации, что избавляет вас от необходимости создавать новую учетную запись и запоминать ее учетные данные для пользователя.
- Accounts могут быть добавлены независимо через Настройки → Учетные записи
- Межплатформенную авторизацию пользователей можно легко управлять с помощью Accounts . Например, клиент может одновременно получить доступ к защищенным материалам в своем устройстве android для Android и без необходимости повторного входа в систему.
- С точки зрения безопасности использование одного и того же пароля в каждом запросе на сервер допускает возможность подслушивания в незащищенных соединениях. Шифрование пароля здесь недостаточно, чтобы предотвратить кражу паролей.
- Наконец, важной причиной использования функции Accounts в android является разделение двух сторон, вовлеченных в любой бизнес, зависящий от Accounts , так называемый аутентификатор и владелец ресурсов, без ущерба для учетных данных клиента (пользователя). Термины могут показаться довольно расплывчатыми, но не сдавайтесь, пока вы не прочитаете следующий параграф … 😉
Позвольте мне подробно остановиться на примере приложения для потоковой передачи видео. Компания A является владельцем видеопотока в контракте с Компанией B, чтобы предоставить своим определенным участникам услуги премиум-потоковой передачи. Компания B использует метод имени пользователя и пароля для распознавания его пользователя. Чтобы компания A признала премиум-членов B, одним из способов было бы получить их список из B и использовать аналогичный механизм совпадения имени пользователя и пароля. Таким образом, аутентификатор и владелец ресурсов являются одинаковыми (компания A). Помимо обязательности пользователей помнить второй пароль, очень вероятно, что они установили тот же пароль, что и профиль их компании B для использования услуг от A. Это, очевидно, не является благоприятным.
Чтобы устранить вышеупомянутые недостатки, OAuth был представлен. В качестве открытого стандарта для авторизации в приведенном выше примере OAuth требует, чтобы авторизация выполнялась компанией B (аутентификатором) путем выдачи некоторого токена под названием Access Token для правомочных пользователей (третьего лица), а затем предоставления Компании A (владельцу ресурса) Токен. Таким образом, никакой токен не означает права на участие.
Я подробно рассказал об этом и многое другое в AccountManager на моем сайте здесь.
Источник
