Как узнать uuid приложения андроид
устройства Android имеют уникальный идентификатор, и если да, то каков простой способ получить к нему доступ с помощью Java?
обновление: по состоянию на последние версии Android, многие из проблем с ANDROID_ID были решены, и я считаю, что этот подход больше не нужен. Пожалуйста, взгляните на Антония.
на основе моих тестов устройств (все телефоны, по крайней мере один из которых не активирован):
- все проверенные устройства вернули значение для TelephonyManager.getDeviceId()
- все приборы GSM (все испытанные с SIM) возвратили значение для TelephonyManager.getSimSerialNumber()
- все устройства CDMA вернули значение null для getSimSerialNumber() (как и ожидалось)
- все устройства с добавленной учетной записью Google вернули значение для ANDROID_ID
- все устройства CDMA вернули одно и то же значение (или вывод одного и того же значения) для обоих ANDROID_ID и TelephonyManager.getDeviceId() -- пока учетная запись Google была добавлена во время установки.
- у меня еще не было возможности протестировать GSM-устройства без SIM-карты, GSM-устройство без учетной записи Google, или любое из устройств в режиме полета.
Итак, если вы хотите что-то уникальное для самого устройства, TM.getDeviceId() должны быть достаточным. Очевидно, что некоторые пользователи более параноидальны, чем другие, поэтому может быть полезно хэшировать 1 или более из этих идентификаторов, так что строка по-прежнему практически уникальна для устройства, но явно не идентифицирует фактическое устройство пользователя. Например, используя String.hashCode() , в сочетании с UUID:
может результат в чем-то вроде: 00000000-54b3-e7c7-0000-000046bffd97
она работает достаточно хорошо для меня.
как Ричард упоминает ниже, не забывайте, что вам нужно разрешение на чтение TelephonyManager свойства, поэтому добавьте это в свой манифест:
оборудование
- пользователи могут изменить свое оборудование, Android-планшет или телефон, поэтому уникальные идентификаторы на основе оборудования не являются хорошими идеями для отслеживание Пользователи
- на ОТСЛЕЖИВАНИЕ ОБОРУДОВАНИЯ, это отличная идея
программа
- пользователи могут стереть / изменить свой ПЗУ, если они укоренены
- вы можете отслеживать пользователей на разных платформах (iOS, Android, Windows и Web)
- лучшие хотите ОТСЛЕЖИВАНИЕ ОТДЕЛЬНОГО ПОЛЬЗОВАТЕЛЯ С согласие просто иметь их логин (сделать это бесшовное использование Протокол OAuth)
- гарантия уникальности (включая корневые устройства) для API >= 9/10 (99,5% устройств Android)
- никаких дополнительных разрешений
спасибо @stansult за публикацию все наши варианты (в этом вопросе переполнения стека).
список опций - причины/ почему не использовать они:
Электронная Почта Пользователя-Программное Обеспечение
- пользователь может изменить электронную почту - маловероятно
- API 5+ <uses-permission android:name="android.permission.GET_ACCOUNTS" /> или
- API 14+ <uses-permission android:name="android.permission.READ_PROFILE" /> <uses-permission android:name="android.permission.READ_CONTACTS" /> (как получить основной адрес электронной почты Android устройства)
Номер Телефона Пользователя-Программное Обеспечение
- потребители смогли изменить телефонные номера-сильно вряд ли
- <uses-permission android:name="android.permission.READ_PHONE_STATE" />
IMEI-оборудование (только для телефонов, должен android.permission.READ_PHONE_STATE )
- большинство пользователей ненавидят тот факт, что он говорит "телефонные звонки" в разрешении. Некоторые пользователи дают плохие оценки, потому что они считают, что вы просто крадете их личную информацию, когда все, что вы действительно хотите сделать, это отслеживать установки устройств. Очевидно, что вы собираете данные.
- <uses-permission android:name="android.permission.READ_PHONE_STATE" />
Android ID-оборудование (может быть null, может изменяться при сбросе заводских настроек, может быть изменен на корневом устройстве)
- поскольку он может быть "null", мы можем проверить "null" и изменить его значение, но это означает, что он больше не будет уникальным.
- если у вас есть пользователь с устройством сброса настроек, значение может быть изменено или изменено на корневом устройстве, поэтому могут быть дубликаты записи, если вы отслеживаете установки пользователя.
WLAN MAC-адрес-оборудование (needs android.permission.ACCESS_WIFI_STATE )
- это может быть второй лучший вариант, но вы все еще собираете и храните уникальный идентификатор, который поступает непосредственно от пользователя. Очевидно, что вы собираете данные.
- <uses-permission android:name="android.permission.ACCESS_WIFI_STATE "/>
Bluetooth MAC-адрес - Оборудование (устройства с Bluetooth, потребности android.permission.BLUETOOTH )
- большинство приложений на рынке не используют Bluetooth, и поэтому, если ваше приложение не использует Bluetooth, и вы включаете это, пользователь может стать подозрительным.
- <uses-permission android:name="android.permission.BLUETOOTH "/>
псевдо-уникальный ID-Software (для всех устройств Android)
- очень возможно, может содержать столкновения-см. Мой метод размещен ниже!
- это позволяет вам иметь "почти уникальный" идентификатор от пользователя, не принимая ничего личного. Вы можете создать свой собственный анонимный идентификатор из информации об устройстве.
я знаю, что нет никакого "идеального" способа получить уникальный идентификатор без использования разрешений; однако иногда нам действительно нужно отслеживать установку устройства. Когда дело доходит до создания уникального идентификатора, мы можем создать псевдо уникальный идентификационный основе исключительно от информации, которую Android API дает нам без использования дополнительных разрешений. Таким образом, мы можем показать уважение пользователя и попытаться предложить хороший пользовательский опыт.
С псевдо-уникальным идентификатором вы действительно сталкиваетесь только с тем, что могут быть дубликаты, основанные на том, что есть похожие устройства. Вы можете настроить комбинированный метод, чтобы сделать его более уникальным; однако некоторым разработчикам необходимо отслеживать установки устройств, и это сделает трюк или производительность, основанную на подобное устройство.
API >= 9:
если их Android-устройство API 9 или более, это гарантированно будет уникальным из-за "сборки".Серийное поле.
если все остальное терпит неудачу:
если все остальное не удается, если пользователь имеет ниже, чем API 9 (ниже, чем Gingerbread), сбросил свое устройство или "безопасный".ANDROID_ID "возвращает " null", то просто ID возвращается будет исключительно на основе их Android информации об устройстве. Это где столкновения могут случаться.
- Удалено ' Android.SECURE_ID ' из-за заводских сбросов может привести к изменению значения
- отредактировал код для изменения в API
- изменен псевдо
пожалуйста, взгляните на метод ниже:
из консоли разработчика Google Play:
начиная с 1 августа 2014, политика программы разработчика Google Play требуется все новые загрузки приложений и обновления для использования рекламного идентификатора в замените любые другие постоянные идентификаторы для любых рекламных целей. Учить больше
реализация:
Источник/Документы:
важно:
предполагается, что реклама ID полностью заменить существующий использование других идентификаторов для целей рекламы (например, использование ANDROID_ID в настройках.Secure), когда доступны сервисы Google Play. Случаи где службы Google Play недоступны, указывается GooglePlayServicesNotAvailableException выбрасывается getAdvertisingIdInfo ().
предупреждение, пользователи могут сброс:
я попытался ссылаться на каждую ссылку, из которой я взял информацию. Если вы отсутствуете и должны быть включены, пожалуйста, прокомментируйте!
Google Player Services InstanceID
Как упоминает Дэйв Уэбб,блог разработчика Android имеет статью что это покрывает. Их предпочтительным решением является отслеживание установок приложений, а не устройств, и это будет хорошо работать для большинства случаев использования. В блоге покажу вам необходимый код, чтобы сделать эту работу, и я рекомендую вам проверить его.
основываясь на рекомендациях 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
есть довольно полезная информация здесь.
он охватывает пять различных типов идентификаторов:
- IMEI (только для Android устройств с использованием телефона; потребности android.permission.READ_PHONE_STATE )
- псевдо-уникальный ID (для всех устройств Android)
- Android ID (может быть null, может изменяться при сбросе заводских настроек, может быть изменен на корневом телефоне)
- WLAN MAC-адрес строка (должен android.permission.ACCESS_WIFI_STATE )
- BT MAC-адрес строка (устройства с Bluetooth, потребности android.permission.BLUETOOTH )
официальный блог разработчиков Android теперь имеет полную статью как раз об этой теме, Идентификация Установки Приложений.
At Google I / O Reto Meier выпустила надежный ответ на то, как подойти к этому, который должен удовлетворить большинство разработчиков, чтобы отслеживать пользователей через установки. Энтони Нолан показывает направление в своем ответе, но я подумал, что напишу полный подход, чтобы другие могли легко увидеть, как это сделать (мне потребовалось некоторое время, чтобы выяснить детали).
этот подход даст вам анонимный, безопасный идентификатор пользователя, который будет постоянным для пользователя в разных устройства (на основе основной учетной записи Google) и между установками. Основной подход заключается в создании случайного идентификатора пользователя и сохранении его в общих настройках приложений. Затем вы используете агент резервного копирования Google для хранения общих настроек, связанных с учетной записью Google в облаке.
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 должно быть реализовано производителем и не гарантируется уникальность.
ниже приведен пример записи данных в установка файл, который будет храниться вместе с любыми другими данными, которые приложение сохраняет локально.
Всем привет! Если вам нужно создать уникальный и стабильный идентификатор 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. Подменить локально сохраненный идентификатор из предыдущего способа сложнее, поскольку это предполагает как минимум базовое изучение работы приложения.
Создание цифрового отпечатка (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, чтобы быть готовым к моменту, когда доступ к ним будет ограничен.
Если у вас есть вопросы или дополнения — делитесь ими в комментариях. А на этом все, спасибо за внимание!
Я ищу помощь, чтобы получить UUID моего Android телефона. Я поискал в сети и нашел одно потенциальное решение, но оно не работает в эмуляторе.
Кто-нибудь знает, почему это не работает, или у вас есть лучшее решение?
Возможный Дубликат : запуск моего приложения при наборе номера Я хотел бы получить номер мобильного телефона от dialer, который набрал пользователь в моем приложении android. Я реализовал приложение следующим образом: ((Button)findViewById(R.id.button1)).setOnClickListener(new OnClickListener()
Как я могу получить список контактов телефона в мобильном приложении FireMonkey?
- ANDROID_ID-это предпочтительный идентификатор устройства. ANDROID_ID идеально надежен в версиях Android <=2.1 или >=2.3. Только 2.2 имеет проблемы, упомянутые в посте.
- Несколько устройств нескольких производителей страдают от ошибки ANDROID_ID в 2.2.
- Насколько мне удалось определить , все затронутые устройства имеют один и тот же ANDROID_ID, который равен 9774d56d682e549c . Это также тот же идентификатор устройства, о котором сообщает эмулятор, кстати.
- Google считает, что OEMs исправили эту проблему для многих или большинства своих устройств, но я смог убедиться, что по состоянию на начало апреля 2011 года, по крайней мере, все еще довольно легко найти устройства с сломанным ANDROID_ID.
- Когда устройство имеет несколько пользователей (доступно на некоторых устройствах под управлением Android 4.2 или выше) , каждый пользователь отображается как совершенно отдельное устройство, поэтому значение ANDROID_ID уникально для каждого пользователя.
Основываясь на рекомендациях Google, я реализовал класс, который будет генерировать уникальный UUID для каждого устройства, используя ANDROID_ID в качестве семени, где это уместно, возвращаясь к TelephonyManager.getDeviceId() по мере необходимости, а если это не удастся, прибегая к случайно сгенерированному уникальному UUID, который сохраняется при перезапуске приложения (но не при повторной установке приложения).
Обратите внимание,что для устройств, которые должны быть резервными на устройстве ID, уникальный идентификатор будет сохраняться при заводских сбросах. Это то, что нужно осознавать. Если вам нужно убедиться, что заводской сброс сбросит Ваш уникальный ID, вы можете рассмотреть возможность возврата непосредственно к случайному UUID вместо устройства ID.
Опять же, этот код предназначен для устройства ID, а не для установки приложения ID. В большинстве случаев установка приложения ID-это, вероятно, то, что вы ищете. Но если вам действительно нужно устройство ID, то следующий код, вероятно, будет работать для вас.
Рассказываем про идентификаторы устройств на Android и про то, как приложения злоупотребляют ими, чтобы больше зарабатывать на рекламе.
О том, как работает реклама в Интернете и как рекламные сети (и не только они) узнают, какие сайты вы посещаете, мы уже рассказывали. Но ваша виртуальная жизнь вряд ли ограничивается веб-страницами. Скорее всего, заметная ее часть проходит в мобильных приложениях, которые тоже нередко зарабатывают на рекламе. Для этого они, как и сайты, сотрудничают с рекламными сетями.
Чтобы маркетологи могли составить на вас детальное досье и показывать вам персонализированные объявления, мобильные программы отправляют им информацию о вашем устройстве. Даже ту, использовать которую в рекламных целях Google не разрешает.
Какая информация позволяет отследить ваше Android-устройство
Убедиться, что та или иная программа установлена именно на вашем устройстве, рекламной сети помогают специальные коды-идентификаторы. Как правило, их у смартфона, планшета и любого другого гаджета несколько, и большинство из них придуманы не для рекламы.
Так, уникальный номер IMEI нужен, чтобы распознавать ваш телефон в сотовых сетях и, например, блокировать краденые устройства. А при помощи серийного номера можно определить все гаджеты серии, в которых обнаружен брак, и отозвать их из магазинов.
Еще один уникальный идентификатор, MAC-адрес, нужен для подключения устройства к сети, а заодно может быть использован, чтобы ограничить набор гаджетов, которые имеют право подключаться к вашему домашнему WiFi. Наконец, Android ID (он же SSAID) разработчики приложений используют, чтобы продавать лицензии на ограниченное количество копий для платных версий своих продуктов.
Долгое время какого-то отдельного идентификатора для рекламы вообще не существовало, поэтому приложения отправляли своим партнерам те, к которым имели доступ. При этом спрятаться от объявлений по интересам пользователь практически не мог: те же IMEI или MAC-адреса — это уникальные номера, по которым устройство опознается однозначно. Каждый раз, когда очередное приложение передает в рекламную сеть один из них, та понимает, что его установили именно вы.
Теоретически существует возможность изменить эти номера — в том числе при помощи специальных приложений, но это непросто, и, что хуже, подвергает опасности ваш телефон. Дело в том, что для подобных экспериментов нужны root-права, а получая их, вы делаете устройство уязвимым. К тому же в некоторых странах манипуляции вроде смены IMEI запрещены законом.
Android ID поменять проще — для этого достаточно сбросить смартфон или планшет до заводских настроек. Но после этого придется заново задавать все параметры, устанавливать приложения, авторизоваться в каждом из них и так далее. В общем, куча мороки, так что желающих делать это часто, мягко говоря, не очень много.
Рекламный идентификатор — ожидание
В 2013 году в качестве компромисса между интересами пользователей Android и рекламщиков компания Google ввела специальный рекламный идентификатор. Его задают сервисы Google Play, и пользователь при желании может сбросить его и создать новый. Делается это в меню Настройки > Google > Реклама > Сброс рекламного идентификатора. С одной стороны, такой идентификатор позволяет рекламным сетям отслеживать привычки и увлечения владельцев устройств. С другой — если же хочется избавиться от слежки рекламщиков, вы можете в любой момент без лишних трудностей его сбросить.
По правилам магазина Google Play, в рекламных целях можно использовать только этот идентификатор. Площадка не запрещает связывать его с другими ID, но для этого приложению нужно получить согласие пользователя.
В теории это должно работать так: если вам нравится реклама по интересам, вы не трогаете рекламный идентификатор и можете даже разрешить приложениям объединять его с чем угодно. Если же нет, вы запрещаете связывать эту метку с другими и периодически сбрасываете ее, таким образом отвязывая свое устройство от собранного на него досье.
Увы, в действительности все несколько иначе.
Рекламный идентификатор — реальность
Как обнаружил исследователь Серж Эгельман (Serge Egelman), более 70% приложений в Google Play используют хотя бы один дополнительный идентификатор без предупреждения. Некоторые из них, например 3D Bowling, Clean Master и CamScanner, скачали многие миллионы человек.
Чаще всего в ход идет Android ID, хотя IMEI, MAC-адреса и серийные номера разработчики тоже задействуют. Некоторые приложения отправляют партнерам сразу три идентификатора и более. Так, игра 3D Bowling — видимо, для верности — использует и рекламный идентификатор, и IMEI, и Android ID.
Такой подход делает саму идею специального рекламного идентификатора бессмысленной. Даже если вы против слежки и регулярно сбрасываете его, маркетологи при помощи более стабильной метки легко привяжут к существующему профилю новый идентификатор.
Несмотря на то что подобное поведение не соответствует правилам Google Play, вовремя отловить злоупотребляющих идентификаторами разработчиков не так-то просто. Все приложения проверяют перед публикацией, но многие не совсем честные авторы успешно обходят эту проверку. Даже майнеры то и дело попадают в магазин — что уж говорить о программах, в которых нет откровенно вредоносных функций.
При этом просто запретить приложениям доступ к идентификаторам устройства Google не может: как мы уже говорили, их используют не только для рекламы. Лишая мобильные программы, например, возможности считывать Android ID, компания Google помешала бы разработчикам защищать свой продукт от нелегального копирования, а значит, нарушила бы их права.
Борьба с навязчивой рекламой
Конечно, Google не бездействует. Компания принимает меры, чтобы ограничить возможность злоупотребления идентификаторами. Например, начиная с Android Oreo тот же Android ID для каждого приложения задается свой, так что в глазах рекламной сети, полагающейся на этот ID вместо рекламного, ваш Instagram будет установлен на одном устройстве, а Snapchat — на другом.
Однако для IMEI, серийных номеров и MAC-адресов ввести такую защиту нельзя. Да и телефонов с более старыми версиями Android на рынке немало. Поэтому рекомендуем ограничивать сбор данных, грамотно управляя приложениями.
Читайте также: