Device model identifier android

Android device ID

Бывает возникает необходимость получить какой-то уникальный идентификатор для Android телефона. Какие могут быть варианты? В данном топике опишу семь известных мне способов сделать это. (Точее, способов будет шесть, а вот седьмой как вариант – это комбинация всех шести предыдущих). Итак.

Android IMEI.
Думаю, Вам известно, что каждый, даже самый старый черно-белый телефон, имеет свой уникальный идентификатор – IMEI (International Mobile Equipment Identity), применяемый по большей степени в GSM сетях. Он устанавливается производителем телефона и хранится в прошивке. Можем его смело использовать в качестве требуемого идентификатора:

TelephonyManager telephonyManager = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);
String devicIMEI = telephonyManager.getDeviceId();

Для эмулятора всегда возвращается «000000000000000″, для реального телефона что-то наподобие «351256985671943″

Phone Number
Следующим образом можем получить номер телефона:

String phoneNumber = telephonyManager.getLine1Number();

Вернет строку вида: +ХХХХХХХХХХХХ (Х = [0..9])

Примечание: предыдущие два примера требуют указания в манифесте следующего пермишина:
android.permission.READ_PHONE_STATE

Псевдо-уникальный ID
Не все андроид-девайсы могут быть оснащены GSM-модулем, скажем, зато у всех у них есть производитель, который «слепил» устройство из всяких железок. Вот какраз информация об этих железках, собранная вместе, и может послужить в качестве уникального идентификатора (правда возможны и повторения). В некоторых случаях может пригодиться. Сконструируем из этих данных что-то похожее на IMEI телефона (15 знаков):

String pseudoID = «35″ +
Build.BOARD.length()%10 + Build.BRAND.length()%10 +
Build.CPU_ABI.length()%10 + Build.DEVICE.length()%10 +
Build.DISPLAY.length()%10 + Build.HOST.length()%10 +
Build.ID.length()%10 + Build.MANUFACTURER.length()%10 +
Build.MODEL.length()%10 + Build.PRODUCT.length()%10 +
Build.TAGS.length()%10 + Build.TYPE.length()%10 +
Build.USER.length()%10;

Android ID
Это еще один ID. Считается ненадежным, так как может в некоторых случаях быть и null. Обратимся к документации:
A 64-bit number (as a hex string) that is randomly generated on the device’s first boot and should remain constant for the lifetime of the device.
Ничего, пригодится:

String androidID = Secure.getString(getContentResolver(), Secure.ANDROID_ID);

Wi-Fi Mac адрес
В качестве уникального Device Id можно использовать Mac Wi-Fi-адаптера. Для его получения необходимо в манифесте установить права: android.permission.ACCESS_WIFI_STATE

WifiManager wifiManager = (WifiManager)getSystemService(Context.WIFI_SERVICE);
String wifiMac = wifiManager.getConnectionInfo().getMacAddress();

Androif BlueTooth ID
По аналогии с Wi-Fi мак-адресом, может взять и голубозубый мак. (требуются права android.permission.BLUETOOTH и, возможно, включенный адаптер)

BluetoothAdapter bluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
String blueToothMac = bluetoothAdapter.getAddress();

Номер 7
Вариация всех предыдущих методов. Самый простой вариант – получить все вышеописанные идентификаторы, сложить в одну строку и взять md5 хеш от этой строки.

Источник

Как правильно идентифицировать Android-устройства

Всем привет! Если вам нужно создать уникальный и стабильный идентификатор Android-устройства для использования внутри приложения, то вы наверняка заметили тот хаос, который присутствует в документации и в ответах на stackoverflow. Давайте рассмотрим, как решить эту задачу в 2020 году. О том, где взять идентификатор, стойкий к переустановкам вашего приложения, и какие могут быть сложности в будущем — в этом кратком обзоре. Поехали!

Зачем нужна идентификация

В последнее время обсуждения конфиденциальности пользовательских данных стремительно набирают популярность. Возможно, это спровоцировано ростом выручки рекламных гигантов. Возможно, под этими обсуждениями скрывается обеспокоенность монополиями, которые идентифицируют пользователей и их устройства. Так, Apple, борясь со слежкой и ограничивая всем разработчикам использование IDFA, в то же самое время нисколько не ограничивает его себе. Что можно сказать точно: процесс идентификации пользователя приложения для разработчиков усложнился.

В задачах, опирающихся на идентификацию, встречаются: аналитика возвратов, персонализация контента и рекламы, предотвращение мошенничества.

Среди последних можно выделить несколько актуальных проблем:

Общие аккаунты в сервисах с платной подпиской или уникальным платным контентом. Только представьте сколько теряют сервисы вроде Netflix или Coursera от того, что пользователи заводят один аккаунт на нескольких человек.

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

Основные способы идентификации

Использование аппаратных идентификаторов

Устаревший и нежизнеспособный в настоящее время способ. Google хорошо поработала над тем, чтобы закрыть доступ к ним, поскольку они не меняются даже после сброса к заводским настройкам. Среди таких идентификаторов:

В настоящее время они недоступны без явного запроса разрешений. Более того, если приложению нужно ими пользоваться, оно может не попасть в Play Market. Оно должно основным функционалом опираться на эти разрешения, иначе будут трудности с прохождением ревью. Поэтому сейчас эта опция доступна приложениям для работы со звонками или голосовым ассистентам.

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

Генерация UUID с первым запуском

Данный способ схож с использованием cookie: создаем файл со сгенерированной строкой, сохраняем его в песочнице нашего приложения (например с помощью SharedPreferences), и используем как идентификатор. Недостаток тот же, что и у cookie — вся песочница удаляется вместе с приложением. Еще она может быть очищена пользователем явно из настроек.

При наличии у приложения разрешений к хранилищу вне песочницы можно сохранить идентификатор где-то на устройстве и постараться поискать его после переустановки. Будет ли в тот момент нужное разрешение у приложения — неизвестно. Этот идентификатор можно использовать как идентификатор установки приложения (app instance ID).

Использование идентификаторов, предоставляемых системой

В документации для разработчиков представлен идентификатор ANDROID_ID. Он уникален для каждой комбинации устройства, пользователя, и ключа, которым подписано приложение. До Android 8.0 идентификатор был общим для всех приложений, после — уникален только в рамках ключа подписи. Этот вариант в целом годится для идентификации пользователей в своих приложениях (которые подписаны вашим сертификатом).

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

Добавляем строчку в файл манифеста нужного модуля:

И вот так достаем идентификатор:

В коде происходит следующее: мы делаем запрос к данным из определенного ContentProvider-a, что поставляется с сервисами Google. Вполне возможно, что Google закроет к нему доступ простым обновлением сервисов. И это даже не обновление самой операционки, а пакета внутри нее, т.е. доступ закроется с обычным обновлением приложений из Play Market.

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

Приложение Device ID Changer в связке с Xposed позволяет подменять практически любой идентификатор. В бесплатной версии — только ANDROID_ID

Создание цифрового отпечатка (fingerprint) устройства

Идея device-fingerprinting не новая, и активно используется в вебе. У самой популярной библиотеки для создания отпечатка — FingerprintJS — 13 тысяч звезд на GitHub. Она позволяет идентифицировать пользователя без использования cookie.

Рассмотрим идею на примере (цифры взяты приблизительные для иллюстрации).

Возьмем ежедневную аудиторию какого-нибудь Android-приложения. Допустим она составляет 4 миллиона. Сколько среди них устройств марки Samsung? Гораздо меньше, примерно 600 тысяч. А сколько среди устройств Samsung таких, что находятся под управлением Android 9? Уже около 150 тысяч. Выделим среди последних такие, что используют сканер отпечатков пальцев? Это множество устройств еще меньше, ведь у многих планшетов нет сканера отпечатков пальцев, а современные модели опираются на распознавание лица. Получим 25000 устройств. Добавляя больше условий и получая больше информации, можно добиться множеств малых размеров. В идеальном случае — с единственным элементом внутри, что и позволит идентифицировать пользователя. Чем больше пользователей можно различить, тем выше энтропия этой информации.

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

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

Из достоинств метода — его независимость от приложения (в отличие от ANDROID_ID), поскольку при одинаковых показаниях с источников отпечатки будут одинаковыми. Отсюда же вытекает первый недостаток — разные устройства с некоторой вероятностью могут иметь одинаковый отпечаток.

Еще одна особенность отпечатка — не все источники информации стабильны. Например, установленные приложения дадут много энтропии. Возьмите устройство друга, и проверьте, одинаков ли у вас набор приложений. Скорее всего — нет, к тому же приложения могут устанавливаться и удаляться почти каждый день.

Таким образом, метод будет работать при правильном соотношении стабильности и уникальности источников энтропии.

Какой метод выбрать

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

Разумный вариант — использовать сторонние решения с открытыми исходниками. В этом случае за изменениями в политике конфиденциальности будет следить сообщество, вовремя поставляя нужные изменения. За столько лет существования проблемы до сих пор нет популярной библиотеки для ее решения, как это есть для веба. Но среди того, что можно найти на android-arsenal, можно выделить две, обе с открытым исходным кодом.

Android-device-identification — библиотека для получения идентификатора. Судя по коду класса, ответственного за идентификацию, используются аппаратные идентификаторы, ANDROID_ID, и цифровой отпечаток полей из класса Build. Увы, проект уже 2 года как не поддерживается, и в настоящий момент скорее неактуален. Но, возможно, у него еще будет развитие.

Fingerprint-android — совсем новая библиотека. Предоставляет 2 метода: getDeviceId и getFingerprint. Первый опирается на GSF_ID и ANDROID_ID, а второй отдает отпечаток, основанный на информации с аппаратного обеспечения, прошивки и некоторых стабильных настроек устройства. Какая точность у метода getFingerprint — пока неясно. Несмотря на это библиотека начинает набирать популярность. Она проста в интеграции, написана на Kotlin, и не несет за собой никаких зависимостей.

В случае, когда импортирование сторонних зависимостей нежелательно, подойдет вариант с использованием ANDROID_ID и GSF_ID. Но стоит следить за изменениями в обновлениях Android, чтобы быть готовым к моменту, когда доступ к ним будет ограничен.

Если у вас есть вопросы или дополнения — делитесь ими в комментариях. А на этом все, спасибо за внимание!

Источник

Есть ли уникальный идентификатор устройства Android?

устройства Android имеют уникальный идентификатор, и если да, то каков простой способ получить к нему доступ с помощью Java?

30 ответов

Settings.Secure#ANDROID_ID возвращает идентификатор Android как уникальный для каждого пользователя 64-разрядной шестнадцатеричной строки.

обновление: по состоянию на последние версии Android, многие из проблем с ANDROID_ID были решены, и я считаю, что этот подход больше не нужен. Пожалуйста, взгляните на Антония.

полное раскрытие: мое приложение использовало приведенный ниже подход первоначально, но больше не использует этот подход, и теперь мы используем подход, описанный в Блог Разработчика Android запись emmby это ссылки на (именно, создание и сохранение UUID#randomUUID() ).

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

на основе моих тестов устройств (все телефоны, по крайней мере один из которых не активирован):

1. все проверенные устройства вернули значение для TelephonyManager.getDeviceId()
2. все приборы GSM (все испытанные с SIM) возвратили значение для TelephonyManager.getSimSerialNumber()
3. все устройства CDMA вернули значение null для getSimSerialNumber() (как и ожидалось)
4. все устройства с добавленной учетной записью Google вернули значение для ANDROID_ID
5. все устройства CDMA вернули одно и то же значение (или вывод одного и того же значения) для обоих ANDROID_ID и TelephonyManager.getDeviceId() — пока учетная запись Google была добавлена во время установки.
6. у меня еще не было возможности протестировать GSM-устройства без SIM-карты, GSM-устройство без учетной записи Google, или любое из устройств в режиме полета.

Итак, если вы хотите что-то уникальное для самого устройства, TM.getDeviceId() должны быть достаточным. Очевидно, что некоторые пользователи более параноидальны, чем другие, поэтому может быть полезно хэшировать 1 или более из этих идентификаторов, так что строка по-прежнему практически уникальна для устройства, но явно не идентифицирует фактическое устройство пользователя. Например, используя String.hashCode() , в сочетании с UUID:

может результат в чем-то вроде: 00000000-54b3-e7c7-0000-000046bffd97

она работает достаточно хорошо для меня.

как Ричард упоминает ниже, не забывайте, что вам нужно разрешение на чтение TelephonyManager свойства, поэтому добавьте это в свой манифест:

Последнее Обновление: 6/2/15

после прочтения каждого сообщения о переполнении стека о создании уникального идентификатора, блога разработчика Google и документации Android, я чувствую, что «псевдо-идентификатор» является лучшим вариантом.

основная проблема: аппаратное и программное обеспечение

оборудование

• пользователи могут изменить свое оборудование, Android-планшет или телефон, поэтому уникальные идентификаторы на основе оборудования не являются хорошими идеями для отслеживание Пользователи
• на ОТСЛЕЖИВАНИЕ ОБОРУДОВАНИЯ, это отличная идея

программа

• пользователи могут стереть / изменить свой ПЗУ, если они укоренены
• вы можете отслеживать пользователей на разных платформах (iOS, Android, Windows и Web)
• лучшие хотите ОТСЛЕЖИВАНИЕ ОТДЕЛЬНОГО ПОЛЬЗОВАТЕЛЯ С согласие просто иметь их логин (сделать это бесшовное использование Протокол OAuth)

общая разбивка с Android

— гарантия уникальности (включая корневые устройства) для API >= 9/10 (99,5% устройств Android)

— никаких дополнительных разрешений

спасибо @stansult за публикацию все наши варианты (в этом вопросе переполнения стека).

список опций — причины/ почему не использовать они:

Электронная Почта Пользователя-Программное Обеспечение

Номер Телефона Пользователя-Программное Обеспечение

• потребители смогли изменить телефонные номера-сильно вряд ли

IMEI-оборудование (только для телефонов, должен android.permission.READ_PHONE_STATE )

• большинство пользователей ненавидят тот факт, что он говорит «телефонные звонки» в разрешении. Некоторые пользователи дают плохие оценки, потому что они считают, что вы просто крадете их личную информацию, когда все, что вы действительно хотите сделать, это отслеживать установки устройств. Очевидно, что вы собираете данные.

Android ID-оборудование (может быть null, может изменяться при сбросе заводских настроек, может быть изменен на корневом устройстве)

• поскольку он может быть «null», мы можем проверить «null» и изменить его значение, но это означает, что он больше не будет уникальным.
• если у вас есть пользователь с устройством сброса настроек, значение может быть изменено или изменено на корневом устройстве, поэтому могут быть дубликаты записи, если вы отслеживаете установки пользователя.

WLAN MAC-адрес-оборудование (needs android.permission.ACCESS_WIFI_STATE )

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

Bluetooth MAC-адрес — Оборудование (устройства с Bluetooth, потребности android.permission.BLUETOOTH )

• большинство приложений на рынке не используют Bluetooth, и поэтому, если ваше приложение не использует Bluetooth, и вы включаете это, пользователь может стать подозрительным.

псевдо-уникальный ID-Software (для всех устройств Android)

• очень возможно, может содержать столкновения-см. Мой метод размещен ниже!
• это позволяет вам иметь «почти уникальный» идентификатор от пользователя, не принимая ничего личного. Вы можете создать свой собственный анонимный идентификатор из информации об устройстве.

я знаю, что нет никакого «идеального» способа получить уникальный идентификатор без использования разрешений; однако иногда нам действительно нужно отслеживать установку устройства. Когда дело доходит до создания уникального идентификатора, мы можем создать псевдо уникальный идентификационный основе исключительно от информации, которую Android API дает нам без использования дополнительных разрешений. Таким образом, мы можем показать уважение пользователя и попытаться предложить хороший пользовательский опыт.

С псевдо-уникальным идентификатором вы действительно сталкиваетесь только с тем, что могут быть дубликаты, основанные на том, что есть похожие устройства. Вы можете настроить комбинированный метод, чтобы сделать его более уникальным; однако некоторым разработчикам необходимо отслеживать установки устройств, и это сделает трюк или производительность, основанную на подобное устройство.

API >= 9:

если их Android-устройство API 9 или более, это гарантированно будет уникальным из-за «сборки».Серийное поле.

если Android-устройство пользователя ниже API 9; надеюсь, у них есть не сделано заводской перезагрузки и их «безопасность».ANDROID_ID ‘будет сохранен или нет ‘null’. (см. http://developer.android.com/about/dashboards/index.html)

если все остальное терпит неудачу:

если все остальное не удается, если пользователь имеет ниже, чем API 9 (ниже, чем Gingerbread), сбросил свое устройство или «безопасный».ANDROID_ID «возвращает » null», то просто ID возвращается будет исключительно на основе их Android информации об устройстве. Это где столкновения могут случаться.

• Удалено ‘ Android.SECURE_ID ‘ из-за заводских сбросов может привести к изменению значения
• отредактировал код для изменения в API
• изменен псевдо

пожалуйста, взгляните на метод ниже:

New (для приложений с рекламой и Google Play Services):

из консоли разработчика Google Play:

начиная с 1 августа 2014, политика программы разработчика Google Play требуется все новые загрузки приложений и обновления для использования рекламного идентификатора в замените любые другие постоянные идентификаторы для любых рекламных целей. Учить больше

реализация:

Источник/Документы:

важно:

предполагается, что реклама ID полностью заменить существующий использование других идентификаторов для целей рекламы (например, использование ANDROID_ID в настройках.Secure), когда доступны сервисы Google Play. Случаи где службы Google Play недоступны, указывается GooglePlayServicesNotAvailableException выбрасывается getAdvertisingIdInfo ().

предупреждение, пользователи могут сброс:

я попытался ссылаться на каждую ссылку, из которой я взял информацию. Если вы отсутствуете и должны быть включены, пожалуйста, прокомментируйте!

Google Player Services InstanceID

Как упоминает Дэйв Уэбб,блог разработчика Android имеет статью что это покрывает. Их предпочтительным решением является отслеживание установок приложений, а не устройств, и это будет хорошо работать для большинства случаев использования. В блоге покажу вам необходимый код, чтобы сделать эту работу, и я рекомендую вам проверить его.

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

• android_id является предпочтительным идентификатором устройства. ANDROID_ID является абсолютно надежным на версиях Android =2.3. Только 2.2 имеет проблемы, упомянутые в сообщении.
• на несколько устройств нескольких производителей влияет ошибка ANDROID_ID в 2.2.
• насколько я смог определить, все уязвимые устройства тот же ANDROID_ID, которая составляет 9774d56d682e549c. Который также является тем же идентификатором устройства, о котором сообщает эмулятор, btw.
• Google считает, что OEMs исправили проблему для многих или большинства своих устройств, но я смог проверить, что по состоянию на начало апреля 2011 года, по крайней мере, все еще довольно легко найти устройства, которые имеют сломанные ANDROID_ID.

основываясь на рекомендациях Google, я реализовал класс, который будет генерировать уникальный UUID для каждого устройства, используя ANDROID_ID в качестве семени, где это необходимо, возвращаясь к TelephonyManager.getDeviceId () по мере необходимости, и если это не удается, прибегая к случайно сгенерированному уникальному UUID, который сохраняется при перезапуске приложения (но не при повторной установке приложения).

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

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

вот код, который Reto Meier использовал в Google I / O презентация в этом году, чтобы получить уникальный идентификатор для пользователя:

Если вы пару это с стратегии резервного копирования для отправки настроек в облако (также описано в Рето-х говорить, у вас должен быть идентификатор, который привязывается к пользователю и прилипает после того, как устройство было стерто или даже заменено. Я планирую использовать это в аналитике в будущем (другими словами, я еще не сделал этого бит :).

также вы можете рассмотреть MAC-адрес адаптера Wi-Fi. Извлекается таким образом:

требуется разрешение android.permission.ACCESS_WIFI_STATE в манифесте.

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

на некоторых устройствах он недоступен при выключенном Wi-Fi.

Примечание: Из Android 6.x, он возвращает последовательный поддельный mac-адрес: 02:00:00:00:00:00

есть довольно полезная информация здесь.

он охватывает пять различных типов идентификаторов:

1. IMEI (только для Android устройств с использованием телефона; потребности android.permission.READ_PHONE_STATE )
2. псевдо-уникальный ID (для всех устройств Android)
3. Android ID (может быть null, может изменяться при сбросе заводских настроек, может быть изменен на корневом телефоне)
4. WLAN MAC-адрес строка (должен android.permission.ACCESS_WIFI_STATE )
5. BT MAC-адрес строка (устройства с Bluetooth, потребности android.permission.BLUETOOTH )

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

At Google I / O Reto Meier выпустила надежный ответ на то, как подойти к этому, который должен удовлетворить большинство разработчиков, чтобы отслеживать пользователей через установки. Энтони Нолан показывает направление в своем ответе, но я подумал, что напишу полный подход, чтобы другие могли легко увидеть, как это сделать (мне потребовалось некоторое время, чтобы выяснить детали).

этот подход даст вам анонимный, безопасный идентификатор пользователя, который будет постоянным для пользователя в разных устройства (на основе основной учетной записи Google) и между установками. Основной подход заключается в создании случайного идентификатора пользователя и сохранении его в общих настройках приложений. Затем вы используете агент резервного копирования Google для хранения общих настроек, связанных с учетной записью Google в облаке.

давайте пройдем через полный подход. Во-первых, нам нужно создать резервную копию для наших SharedPreferences с помощью службы резервного копирования Android. Начните с регистрации вашего приложения через http://developer.android.com/google/backup/signup.html .

Google будет дать вам ключ службы резервного копирования, который необходимо добавить в манифест. Вы также должны сказать приложению использовать BackupAgent следующим образом:

затем вам нужно создать агент резервного копирования и сказать ему использовать вспомогательный агент для sharedpreferences:

для завершения резервного копирования вам необходимо создать экземпляр BackupManager в вашей основной деятельности:

наконец, создайте идентификатор пользователя, если он еще не существует, и сохраните его в SharedPreferences:

этот User_ID теперь будет сохраняться на всех установках, даже если пользователь перемещает устройство.

для получения дополнительной информации об этом подходе см. разговор Рето.

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

следующий код возвращает серийный номер устройства с помощью скрытого API Android. Но этот код не работает на вкладке Samsung Galaxy, потому что » ro.serialno » не установлен на этом устройстве.

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

псевдо-уникальный ID, который работает на всех устройствах Android Некоторые устройства не имеют телефона (например. Таблетки) или по какой-то причине вы не хотите включать разрешение READ_PHONE_STATE. Вы все еще можете прочитать детали, такие как версия ROM, имя производителя, тип процессора и другие детали оборудования, которые будут хорошо подходить, если вы хотите использовать ID для проверки серийного ключа или других общих целей. Этот ID, вычисленный таким образом, не будет уникальным: можно найти два устройства с одинаковым ID (на основе одного и того же оборудования и образа ROM), но изменения в реальных приложениях незначительны. Для этого можно использовать класс Build:

большинство членов сборки-строки, то, что мы здесь делаем, — это взять их длину и преобразовать ее по модулю в цифру. У нас есть 13 таких цифр, и мы добавляем еще две спереди (35), чтобы иметь тот же идентификатор размера, ЧТО и IMEI (15 десятичные знаки.) Есть и другие возможности здесь хорошо, просто взгляните на эти строки. Возвращает что-то вроде 355715565309247 . Специального разрешения не требуется, что делает такой подход очень удобным.

(дополнительная информация: приведенная выше техника была скопирована из статьи на Карман Магия.)

используя приведенный ниже код, вы можете получить уникальный идентификатор устройства Android OS в виде строки.

на серийный поле было добавлено к Build класс в API уровня 9 (Android 2.3-Gingerbread). В документации говорится, что он представляет серийный номер оборудования. Таким образом, он должен быть уникальным, если он существует на устройстве.

Я не знаю, действительно ли он поддерживается (=не null) всеми устройствами с уровнем API >= 9.

одна вещь, которую я добавлю — у меня есть одна из этих уникальных ситуаций.

оказывается, что, хотя мой планшет Viewsonic G сообщает DeviceID, который не является нулевым, каждый планшет G сообщает одно и то же число.

делает его интересным, играя «Pocket Empires», который дает вам мгновенный доступ к чьей-то учетной записи на основе» уникального » DeviceID.

мое устройство не имеет сотового радио.

подробные инструкции о том, как получить уникальный идентификатор для каждого устройства Android, с которого установлено приложение, см. В официальном блоге разработчиков Android Идентификация Установки Приложений.

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

Я лично считаю это приемлемым, но не идеальным. Нет идентификатора, предоставленного Android работает во всех случаях, так как большинство из них зависят от состояния радио телефона (Wi-Fi вкл/выкл, сотовая связь вкл/выкл, Bluetooth вкл/выкл). Другие, как Settings.Secure.ANDROID_ID должно быть реализовано производителем и не гарантируется уникальность.

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

Источник