Device type android on android 2

Работа с устройствами USB в Android

В недавней статье на Geektimes в комментариях возник вопрос о поддержке в ОС Android периферии, подключенной к шине USB. Действительно, большинство вендорского ПО, к примеру, для работы с принтерами и МФУ, поддерживает только подключение по сети. Однако это не означает, что в самой ОС Android нет такой возможности — это означает лишь то, что большинство устройств не имеют полноценного USB хоста, и далеко не все имеют поддержку OTG. По сети же могут работать абсолютно все без исключения.

Большинство устройств на Android при наличии порта OTG поддерживают на уровне системы (ядра Linux или стандартных компонентов Android) следующие классы устройств:

• Устройства ввода — клавиатуры, мыши, джойстики (HID)
• Накопители (Mass Storage)

Несколько реже:

• Сотовые модемы
• Сетевые адаптеры
• Вебкамеры

Хабы поддерживаются при наличии полноценных хост-портов, но не поддерживаются на портах OTG.

Подробнее список устройств, поддерживаемых на уровне ядра Linux, можно получить в sysfs:

$ ls /sys/bus/usb/drivers

Если же модуль в принципе доступен в исходниках ядра Linux, но не включен в Android — не стоит рассчитывать на то, что его получится собрать и расставить на все целевые системы.

Однако, начиная с Android 3.1 (API 12), в системе содержатся средства, достаточные для поддержки на уровне приложения любой USB периферии. Данные средства описаны в разделе USB Host руководства по Android API. Здесь же я хочу привести примеры реальной работы с некоторыми видами устройств.

Права доступа

Как и для прочих действий, Android требует, чтобы приложение получило разрешение на доступ к USB периферии. Существует 2 способа получить такое разрешение:

• Задекларировать список устройств в AndroidManifest
• Явно показать пользователю диалог “разрешить”

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

Итак, нам необходимо добавить в манифест следующее:

А в res/xml/device_filter.xml вписать следующее:

Отмечу, что хотя общепринято указывать VID:PID в 16-ричной системе счисления, здесь они должны быть указаны в десятичной. В документации заявляется, что возможно указание только класса, без VID и PID, но у меня это не стало работать.

Принтеры

На примере принтера я покажу, как непосредственно использовать API android.hardware.usb. На уровне передачи данных все принтеры поддерживают стандартый класс USB устройств:

Класс предельно простой. В рамках этого класса устройство должно поддерживать:

• Обязательный bulk out endpoind для отправки данных на принтер
• Опциональный bulk in endpoind для получения статуса принтера
• 3 управляющих запроса

Код, приведенный ниже, предоставляет функциональность, аналогичную устройству /dev/usb/lp в Linux. Далее нам нужен фильтр, преобразующий исходный документ в пакет данных, понятный конкретной модели принтера. Но это тема иной статьи. Как один из вариантов — можно собрать ghostscript с помощью NDK.

Для работы с устройством нам в первую очередь нужно:

1. Найти устройство. В примере для простоты я ищу первый попавшийся:

2. Получить endpoint’ы:

3. Непосредсвенно открыть устройство:

4. После этого мы можем читать и писать в устройство:

5. По завершении работы — закрыть устройство:

Преобразователи USB-Serial

В отличие от притеров, преобразователи USB-Serial гораздо менее стандартизированы. Существует несколько распространенных чипов, для которых существенно отличается установка параметров последовательного порта — битрейта, чётности и проч. К счастью, есть библиотека github.com/mik3y/usb-serial-for-android, поддерживающая практически все существующие чипы. Библиотека полностью скрывает USB API, сводя все необходимые действия к минимуму вызовов с минимумом параметров.

1. Найти и открыть устройство:

2. Установить параметры последовательного порта:

3. Читать и писать в порт:

4. По завершении работы — закрыть порт:

Резюме

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

Все приведенные примеры я взял из реального проекта, лишь исключил очевидные проверки, оставив только ключевые строки.

Источник

Как правильно идентифицировать 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 с помощью Android Device Manager.

Android Device Manager в Windows

Android Device Manager поддерживает изменение свойств профиля для отдельного виртуального устройства Android. На экранах Создание устройства и Изменение устройства в первом столбце перечислены свойства виртуального устройства, а во втором — соответствующие значения для них (как показано в данном примере):

При выборе свойства справа отображается его подробное описание. Вы можете изменить свойства профиля оборудования и свойства AVD. Свойства профиля оборудования (например, hw.ramSize и hw.accelerometer ) описывают физические характеристики эмулируемого устройства. К таким характеристикам относится размер экрана, объем доступной оперативной памяти, состояние работы акселерометра. Свойства AVD описывают работу AVD. Например, в свойствах AVD можно указать, как AVD использует видеоадаптер вашего компьютера разработчика для отрисовки.

Ниже описано, как можно изменить свойства:

Чтобы изменить логическое свойство, щелкните флажок справа от него:

Чтобы изменить свойство enum (перечисление), щелкните стрелку вниз справа от свойства и выберите новое значение.

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

Android Device Manager в macOS

Android Device Manager поддерживает изменение свойств профиля для отдельного виртуального устройства Android. На экранах Создание устройства и Изменение устройства в первом столбце перечислены свойства виртуального устройства, а во втором — соответствующие значения для них (как показано в данном примере):

При выборе свойства справа отображается его подробное описание. Вы можете изменить свойства профиля оборудования и свойства AVD. Свойства профиля оборудования (например, hw.ramSize и hw.accelerometer ) описывают физические характеристики эмулируемого устройства. К таким характеристикам относится размер экрана, объем доступной оперативной памяти, состояние работы акселерометра. Свойства AVD описывают работу AVD. Например, в свойствах AVD можно указать, как AVD использует видеоадаптер вашего компьютера разработчика для отрисовки.

Ниже описано, как можно изменить свойства:

Чтобы изменить логическое свойство, щелкните флажок справа от него:

Чтобы изменить свойство enum (перечисление), щелкните раскрывающееся меню справа от свойства и выберите новое значение.

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

Следующая таблица содержит подробное описание свойств, указанных на экранах Новое устройство и Device Editor (Редактор устройств):

Свойство	Описание	Параметры
abi.type	Тип ABI указывает тип ABI (двоичный интерфейс приложений) для эмулированного устройства. Параметр x86 предназначен для набора инструкций, обычно называемого «x86» или «IA-32». Параметр x86_64 предназначен для 64-разрядного набора инструкций x86. Вариант armeabi-v7a обозначает набор инструкций ARM с расширениями v7-a ARM. Вариант arm64-v8a обозначает набор инструкций ARM, который поддерживает AArch64.	x86, x86_64, armeabi-v7a, arm64-v8a
disk.cachePartition	Раздел кэша — определяет, использует ли эмулируемое устройство раздел /cache. Раздел /cache (изначально этот раздел пуст) предназначен для хранения часто используемых данных и компонентов приложений Android. Если здесь выбрано значение no, эмулятор не будет использовать раздел /cache и все остальные параметры будут игнорироваться.	yes (Да), no (Нет)
disk.cachePartition.path	Путь к разделу кэша — определяет файл с образом раздела кэша на компьютере разработки. Эмулятор использует этот файл в качестве раздела /cahce. Здесь можно указать абсолютный путь или путь относительно каталога данных, используемого эмулятором. Если значение не задано, эмулятор создает на компьютере разработки пустой временный файл с именем cache.img. Если заданный файл не существует, он будет создан с пустым содержимым. Этот параметр игнорируется, если параметр disk.cachePartition имеет значение disk.cachePartition .
disk.cachePartition.size	Размер раздела кэша — размер файла раздела кэша (в байтах). Обычно этот параметр использовать не нужно, если приложение не будет скачивать огромные файлы, превышающие стандартный размер кэша 66 мегабайт. Этот параметр игнорируется, если параметр disk.cachePartition имеет значение disk.cachePartition . Если в качестве значения используется целое число, оно указывает размер в байтах. Также вы можете указать размер в килобайтах, мегабайтах или гигабайтах, добавив к значению обозначение K, M или G соответственно. Минимальный размер — 9 мин , а максимальный размер — 1023G.
disk.dataPartition.initPath	Начальный путь к разделу данных — указывает исходные данные для секции данных. После очистки пользовательских данных эмулятор копирует в каталог пользовательских данных содержимое указанного файла (по умолчанию это файл userdata-qemu.img), а не использует userdata.img в качестве исходных данных.
disk.dataPartition.path	Путь к разделу данных — указывает файл для раздела пользовательских данных. Чтобы настроить сохраняемый файл пользовательских данных, введите имя файла и путь к нему на компьютере разработки. Если этот файл не существует, эмулятор создает образ из файла по умолчанию userdata.img, сохраняет его с тем именем, которое указано в параметре , и при завершении работы сохраняет в этом файле все данные пользователя. Если путь не указан, файл по умолчанию получает имя userdata-qemu.img. Специальное значение temp > заставляет эмулятор создать и использовать временный файл. Если файл данных disk.dataPartition.initPath задан, его содержимое будет скопировано в файл disk.dataPartition.path во время загрузки. Обратите внимание, что этот параметр нельзя оставлять пустым.
disk.dataPartition.size	Размер секции данных — указывает размер секции данных пользователя в байтах. Если в качестве значения используется целое число, оно указывает размер в байтах. Также вы можете указать размер в килобайтах, мегабайтах или гигабайтах, добавив к значению обозначение K, M или G соответственно. Минимальный размер — 9 мин , а максимальный размер — 1023G.
disk.ramdisk.path	Путь к виртуальному диску — путь к образу загрузочного раздела (виртуальному диску). Образ виртуального диска является подмножеством системных образов, который загружается ядром перед подключением образа системы. Образ виртуального диска обычно содержит двоичные файлы и скрипты инициализации для процессов загрузки. Если этот параметр не указан, по умолчанию используется файл ramdisk.img в системном каталоге эмулятора.
disk.snapStorage.path	Путь к хранилищу моментального снимка — путь к файла хранилища моментальных снимков, в котором сохраняются моментальные снимки. В этот файл будет сохранены все моментальные снимки, созданные во время выполнения. При работе эмулятора можно восстановить только те моментальные снимки, которые сохраняются в этот файл. Если этот параметр не указан, по умолчанию используется файл snapshots.img в каталоге данных эмулятора.
disk.systemPartition.initPath	Путь к системному разделу init — путь к копии файла системного образа, доступной только для чтения. Именно в этом разделе хранятся системные библиотеки и данные, относящиеся к уровню API, и все их вариации. Если этот путь не указан, по умолчанию используется файл system.img в системном каталоге эмулятора.
disk.systemPartition.path	Путь к системному разделу — путь к образу системного раздела, доступному для чтения и записи. Если этот путь не задан, будет создан временный файл, который затем инициализируется содержимым файла, заданного параметром disk.systemPartition.initPath .
disk.systemPartition.size	Размер системного раздела — идеальный размер системного раздела (в байтах). Этот размер не учитывается, если фактический образ системного раздела больше указанного здесь значения. В противном случае он ограничивает максимальный размер файла для системного раздела. Если в качестве значения используется целое число, оно указывает размер в байтах. Также вы можете указать размер в килобайтах, мегабайтах или гигабайтах, добавив к значению обозначение K, M или G соответственно. Минимальный размер — 9 мин , а максимальный размер — 1023G.
hw.accelerometer	Акселерометр — определяет, содержит ли эмулируемое устройство датчик акселерометра. Акселерометр помогает устройству ориентироваться в пространстве (например, используется для автоматического поворота экрана). Акселерометр передает ускорение, действующее на устройство по трем осям датчика.	yes (Да), no (Нет)
hw.audioInput	Поддержка записи звука — определяет, умеет ли эмулируемое устройство записывать звук.	yes (Да), no (Нет)
hw.audioOutput	Поддержка воспроизведения звука — определяет, умеет ли эмулируемое устройство воспроизводить звук.	yes (Да), no (Нет)
hw.battery	Поддержка аккумулятора — определяет, умеет ли эмулируемое устройство работать от аккумулятора.	yes (Да), no (Нет)
hw.camera	Поддержка камеры — определяет, есть ли камера на эмулируемом устройстве.	yes (Да), no (Нет)
hw.camera.back	Задняя камера — настраивает заднюю камеру устройства (ту, которая направлена в другую сторону от пользователя). Если вы используете веб-камеру на компьютере разработчика для имитации задней камеры на эмулируемом устройстве, присвойте этому параметру значение webcamn, где n обозначает порядковый номер камеры в системе (если есть только одна веб-камера, укажите webcam0). Если задана эмуляция, эмулятор имитирует камеру программным способом. Чтобы отключить заднюю камеру, задайте этому параметру значение none. Если вы включите заднюю камеру, обязательно включите параметр hw.camera .	emulated (эмулируется), none (нет), webcam0 (веб-камера 0)
hw.camera.front	Передняя камера — настраивает переднюю камеру устройства (ту, которая направлена на пользователя). Если вы используете веб-камеру на компьютере разработчика для имитации передней камеры на эмулируемом устройстве, присвойте этому параметру значение webcamn, где n обозначает порядковый номер камеры в системе (если есть только одна веб-камера, укажите webcam0). Если задана эмуляция, эмулятор имитирует камеру программным способом. Чтобы отключить переднюю камеру, задайте этому параметру значение none. Если вы включите переднюю камеру, обязательно включите параметр hw.camera .	emulated (эмулируется), none (нет), webcam0 (веб-камера 0)
hw.camera.maxHorizontalPixels	Максимальное количество пикселей камеры по горизонтали — настраивает максимальное разрешение (в пикселях) по горизонтали для камеры эмулированного устройства.
hw.camera.maxVerticalPixels	Максимальное количество пикселей камеры по вертикали — настраивает максимальное разрешение (в пикселях) по вертикали для камеры эмулированного устройства.
hw.cpu.arch	Архитектура ЦП — архитектура ЦП, которую будет эмулировать виртуальное устройство. Если вы используете Intel HAXM для аппаратного ускорения, выберите x86 для 32-разрядного процессора. Выберите x86_64, если вам нужно 64-разрядное устройство с ускорением HAXM. (Не забудьте установить соответствующий образ системы Intel x86 в диспетчере SDK: например, Intel x86 Atom или Intel x86 Atom_64.) Для имитации процессора ARM выберите arm (32-разрядная версия) или arm64 (64-разрядная версия). Учитывайте, что виртуальные устройства на основе ARM работают гораздо медленнее, чем на основе x86, поскольку для ARM не поддерживается аппаратное ускорение.	x86, x86_64, arm, arm64
hw.cpu.model	Модель ЦП — это значение обычно остается неопределенным (оно будет установлено в значение, производное от, если оно не задано явно). Но для экспериментов вы можете присвоить ему конкретную строку, значение которой зависит от эмулятора.
hw.dPad	Клавиши DPad — определяет, поддерживает ли эмулированное устройство навигационное устройство (DPad). Обычно DPad имеет четыре клавиши для выбора направления.	yes (Да), no (Нет)
hw.gps	Поддержка GPS — определяет наличие приемника GPS (глобальной системы позиционирования) на эмулированном устройстве.	yes (Да), no (Нет)
hw.gpu.enabled	Эмуляция GPU — определяет поддержку эмуляции GPU для эмулированного устройства. Если включена эмуляция GPU, для отрисовки 2D и 3D графики на экране применяется Open GL для встраиваемых систем (OpenGL ES). Способ реализации для эмуляции GPU определяется связанным параметром «Режим эмуляции GPU».	yes (Да), no (Нет)
hw.gpu.mode	Режим эмуляции GPU — определяет способ реализации для эмуляции GPU в эмуляторе устройства. Если выбран вариант auto, эмулятор самостоятельно выберет режимы программного и аппаратного ускорения, исходя из настроек компьютера разработки. Если выбран вариант host, эмулятор будет использовать графический процессор компьютера разработки для эмуляции GPU, чтобы ускорять отображение содержимого. Если установленный GPU не совместим с эмулятором, в Windows можно попробовать вариант angle вместо host. Режим angle использует DirectX и обеспечивает примерно такую же производительность, как вариант host. Если выбран вариант mesa, эмулятор будет использовать программную библиотеку Mesa 3D для отображения графики. Выберите вариант mesa, если работа с графическим процессором компьютера разработки вызывает какие-либо проблемы. Режим swiftshader позволяет отображать графические элементы программным способом с несколько меньшей производительностью по сравнению с GPU компьютера. Вариант off (отключение эмуляции графического оборудования) мы использовать не рекомендуем, так как некоторые элементы в этом режиме воспроизводятся неправильно.	auto (автоматически), host (компьютер), mesa, angle, swiftshader, off (отключено)
hw.gsmModem	Поддержка модема GSM — определяет наличие на эмулируемом устройстве модема, который поддерживает систему радиосвязи GSM (глобальная система связи для мобильных устройств).	yes (Да), no (Нет)
hw.initialOrientation	Начальная ориентация экрана — настраивает начальную ориентацию экрана на эмулированном устройстве (книжный или альбомный режим). В книжной ориентации высота экрана больше, чем ширина. В альбомной ориентации ширина экрана больше, чем высота. После запуска эмулированного устройства вы можете изменить на нем ориентацию, если оба этих режима поддерживает профиль устройства.	portrait (книжная), landscape (альбомная)
hw.keyboard	Поддержка клавиатуры — определяет, поддерживает ли эмулированное устройство клавиатуру QWERTY.	yes (Да), no (Нет)
hw.keyboard.charmap	Имя таблицы символов для клавиатуры — имя таблицы символов оборудования этого устройства. Примечание. Здесь следует всегда использовать значение по умолчанию qwerty2, если в образ системы не внесены необходимые изменения. Это имя отправляется в ядро во время загрузки. Если указать неправильное имя, виртуальное устройство будет недоступно для использования.
hw.keyboard.lid	Поддержка крышки клавиатуры — если включена поддержка клавиатуры, этот параметр определяет, можно ли на устройстве закрыть/спрятать и открыть/показать клавиатуру QWERTY. Этот параметр игнорируется, если для hw.keyboard указано значение false. Примечание: по умолчанию устанавливается значение false, если эмулируемое устройство предназначено для API уровня 12 или выше.	yes (Да), no (Нет)
hw.lcd.backlight	Подсветка ЖК-экрана — определяет, будет ли эмулированное устройство управлять подсветкой ЖК-экрана.	yes (Да), no (Нет)
hw.lcd.density	Плотность ЖК-экрана — плотность ЖК-экрана для эмулированного устройства, измеряется в виртуальных пикселях (dp), размер которых не зависит от плотности пикселей. Если выбрано значение 160 точек, каждый виртуальный пиксель (dp) строго соответствует одному физическому пикселю. Во время выполнения Android масштабирует все ресурсы,используя это значение, чтобы правильно отображать их на экране.	120, 160, 240, 213, 320
hw.lcd.depth	Глубина цвета ЖК-экран — глубина цвета в битах для буфера кадров эмулированного устройства, в котором сохраняется изображение для отображения на ЖК-экране. Здесь допускаются значения 16 бит (65 536 возможных цветов) или 32 бит (16 777 216 цветов с поддержкой прозрачности). Если выбрано значение 32 бита, эмулятор может работать несколько медленнее, но зато с большей точностью цветопередачи.	16, 32
hw.lcd.height	Высота ЖК-экрана в пикселях — количество пикселей по вертикали для ЖК-экрана эмулированного устройства.
hw.lcd.width	Ширина ЖК-экрана в пикселях — количество пикселей по горизонтали для ЖК-экрана эмулированного устройства.
hw.mainKeys	Аппаратные клавиши «назад» и «домой» — определяет поддержку аппаратных клавиш «назад» и «домой» для эмулированного устройства. Здесь вы можете задать значение Да, если клавиши реализованы только в программном обеспечении. Если для hw.mainKeys указать значение hw.mainKeys , эмулятор не отображает на экране кнопки навигации, но для их «нажатия» можно использовать боковую панель эмулятора.	yes (Да), no (Нет)
hw.ramSize	Объем оперативной памяти на устройстве — определяет объем физической памяти на эмулированном устройстве в мегабайтах. Значение по умолчанию этого параметра зависит от размера экрана или версии обложки. Если вы увеличите этот размер, эмуляция будет работать быстрее, но для этого потребуется больше ресурсов на компьютере разработки.
hw.screen	Тип сенсорного экрана — определяет тип экрана для эмулированного устройства. В режиме multi-touch экран отслеживает касание двумя или более пальцами. В режиме touch сенсорный экран поддерживает только события касания одним пальцем. В режиме no-touch экран не отслеживает события касания.	touch (сенсорный), multi-touch (мультисенсорный), no-touch (не сенсорный)
hw.sdCard	Поддержка карты SD — определяет поддержку событий вставки и удаления карты SD (Secure Digital) на эмулированном устройстве. Эмулятор использует подключаемые образы дисков, хранящиеся на компьютере разработчика, для имитации разделов на обычных картах SD (см. также параметр hw.sdCard.path).	yes (Да), no (Нет)
sdcard.size	Размер SDCard — указывает размер виртуального SD-файла в расположении, указанном параметром . на устройстве (в байтах). Если в качестве значения используется целое число, оно указывает размер в байтах. Также вы можете указать размер в килобайтах, мегабайтах или гигабайтах, добавив к значению обозначение K, M или G соответственно. Минимальный размер — 9 мин , а максимальный размер — 1023G.
hw.sdCard.path	Путь к образу карты SD — задает имя файла с образом раздела карты SD и путь к нему на компьютере разработки. Например, в ОС Windows этот путь может иметь значение C:\sd\sdcard.img.
hw.sensors.magnetic_field	Датчик магнитного поля — определяет поддержку датчика магнитного поля для эмулированного устройства. Датчик магнитного поля (магнитометр) сообщает напряженность окружающего магнитного поля по трем осям. Включите этот параметр, если вашему приложению нужны показания компаса. Например, приложение навигации может с помощью этого датчика определять, куда смотрит пользователь.	yes (Да), no (Нет)
hw.sensors.orientation	Ориентация датчика — определяет наличие датчика ориентации на эмулированном устройстве. Датчик ориентации измеряет угол поворота для корпуса устройства по трем физическим осям (x, y, z). Обратите внимание, что датчик ориентации объявлен устаревшим с версии ОС Android 2.2 (API уровня 8).	yes (Да), no (Нет)
hw.sensors.proximity	Датчик приближения — определяет поддержку датчика приближения для эмулированного устройства. Этот датчик измеряет расстояния до ближайшего объекта от экрана устройства. Обычно с помощью этого датчика приложения определяют, что человек держит мобильный телефон возле уха.	yes (Да), no (Нет)
hw.sensors.temperature	Датчик температуры — определяет поддержку датчика температуры для эмулированного устройства. Этот датчик измеряет температуру устройства в градусах Цельсия (° C).	yes (Да), no (Нет)
hw.touchScreen	Поддержка сенсорного экрана — определяет, поддерживает ли эмулированное устройство сенсорный экран. Сенсорный экран используется для прямого управления объектами, отображенными на экране.	yes (Да), no (Нет)
hw.trackBall	Поддержка шарового манипулятора — определяет, поддерживает ли эмулированное устройство трекбол.	yes (Да), no (Нет)
hw.useext4	Поддержка файловой системы EXT4 — определяет поддержку файловой системы Linux EXT4 для разделов эмулированного устройства. В настоящее время тип файловой системы определяется автоматически, поэтому этот параметр считается устаревшим и не учитывается.	нет
kernel.newDeviceNaming	Новая схема именования устройств для ядра — указывает, что ядро устройства требует использовать новую схему именования устройств. Обычно этот режим требуется для ядер Linux 3.10 и более поздних версий. Установите значение автоопределение, чтобы эмулятор самостоятельно принимал решение об использовании новой схемы именования устройств.	autodetect (автоопределение), yes (да), no (нет)
kernel.parameters	Параметры ядра — указывает строку параметров загрузки для ядра Linux. По умолчанию этот параметр имеет пустое значение.
kernel.path	Путь к ядру — определяет путь к ядру Linux. Если этот путь не указан, эмулятор по умолчанию ищет файл kernel-ranchu в своем системном каталоге.
kernel.supportsYaffs2	Поддержка разделов YAFFS2 — определяет, поддерживает ли ядро разделы с файловой системой YAFFS2. Обычно это требуется только для версий ядра меньше Linux 3.10. Установите значение автоопределение, чтобы эмулятор самостоятельно принимал решение о возможности подключения файловых систем YAFFS2.	autodetect (автоопределение), yes (да), no (нет)
skin.name	Имя обложки — имя для обложки эмулятора Android. Обложка — это набор файлов, которые описывают правила отображения для визуальных элементов и элементов управления. Эти правила определяют, как будет выглядеть окно AVD на компьютере разработки. От обложки зависят размер экрана, внешний вид кнопок и другие параметры оформления, но она никак не влияет на работу приложения.
skin.path	Путь к обложке — путь к каталогу, который содержит файлы обложки, имя которой указано в параметре skin.name. В этом каталоге должны размещаться файлы макета hardware.ini и файлы изображений, используемых в обложке для элементов отображения.
skin.dynamic	Динамическая обложка — определяет, является ли обложка динамической. Обложка эмулятора считается динамической, если эмулятору нужно создать обложку определенного размера на основе значений ширины и высоты экрана.	нет

Дополнительные сведения об этих свойствах см. в разделе Свойства профиля оборудования.

Источник