Использование слов «должен», «нельзя», «требуется», «должен», «не должен», «следует», «не следует», «рекомендуется», «может» и «необязательно» соответствует стандарту IETF. определено в RFC2119 [ Ресурсы, 1 ].

В этом документе «разработчик устройства» или «разработчик» — это человек или организация, разрабатывающая аппаратное/программное решение под управлением Android 4.4. «Реализация устройства» или «реализация» — это разработанное таким образом аппаратное/программное решение.

Чтобы считаться совместимыми с Android 4.4, реализации устройства ДОЛЖНЫ соответствовать требованиям, представленным в этом определении совместимости, включая любые документы, включенные посредством ссылки.

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

По этой причине проект Android с открытым исходным кодом [ Resources, 3 ] является одновременно эталоном и предпочтительной реализацией Android. Разработчикам устройств настоятельно рекомендуется в максимально возможной степени основывать свои реализации на исходном коде, доступном в проекте Android Open Source Project. Хотя некоторые компоненты гипотетически можно заменить альтернативными реализациями, такая практика настоятельно не рекомендуется, поскольку прохождение тестов программного обеспечения станет существенно сложнее. Ответственность за обеспечение полной поведенческой совместимости со стандартной реализацией Android, включая набор тестов на совместимость, лежит на разработчике. Наконец, обратите внимание, что некоторые замены и модификации компонентов явно запрещены данным документом.

2. Ресурсы

Уровни требований IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

Обзор программы совместимости Android: http://source.android.com/docs/compatibility/index.html .

Проект Android с открытым исходным кодом: http://source.android.com/

Определения API и документация: http://developer.android.com/reference/packages.html .

Ссылка на разрешения Android: http://developer.android.com/reference/android/Manifest.permission.html .

Ссылка на android.os.Build: http://developer.android.com/reference/android/os/Build.html

Строки разрешенной версии Android 4.4: http://source.android.com/docs/compatibility/4.4/versions.html .

Рендерскрипт: http://developer.android.com/guide/topics/graphics/renderscript.html .

Аппаратное ускорение: http://developer.android.com/guide/topics/graphics/hardware-accel.html .

Класс android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

Автономные возможности HTML5: http://dev.w3.org/html5/spec/Overview.html#offline .

Тег видео HTML5: http://dev.w3.org/html5/spec/Overview.html#video .

API геолокации HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API веб-хранилища HTML5/W3C: http://www.w3.org/TR/webstorage/

API HTML5/W3C IndexedDB: http://www.w3.org/TR/IndexedDB/

Спецификация виртуальной машины Dalvik: доступна в исходном коде Android по адресу dalvik/docs.

AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html .

Уведомления: http://developer.android.com/guide/topics/ui/notifiers/notifications.html .

Ресурсы приложения: http://code.google.com/android/reference/available-resources.html .

Руководство по стилю значков строки состояния: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html .

Менеджер поиска: http://developer.android.com/reference/android/app/SearchManager.html .

Тосты: http://developer.android.com/reference/android/widget/Toast.html .

Темы: http://developer.android.com/guide/topics/ui/themes.html .

Класс R.style: http://developer.android.com/reference/android/R.style.html

Живые обои: https://android-developers.googleblog.com/2010/02/live-wallpapers.html .

Администрирование устройств Android: http://developer.android.com/guide/topics/admin/device-admin.html .

Ссылка на DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html .

API службы специальных возможностей Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html .

API специальных возможностей Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html .

Проект Eyes Free: http://code.google.com/p/eyes-free .

API преобразования текста в речь: http://developer.android.com/reference/android/speech/tts/package-summary.html .

Справочная документация по инструментам (для adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html .

Описание APK-файла Android: http://developer.android.com/guide/topics/fundamentals.html .

Файлы манифеста: http://developer.android.com/guide/topics/manifest/manifest-intro.html .

Инструмент тестирования обезьян: https://developer.android.com/studio/test/other-testing-tools/monkey.

Класс Android android.content.pm.PackageManager и список аппаратных функций: http://developer.android.com/reference/android/content/pm/PackageManager.html

Поддержка нескольких экранов: http://developer.android.com/guide/practices/screens_support.html .

android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html .

android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html .

Протокол Push NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

API ориентации камеры: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

Камера: http://developer.android.com/reference/android/hardware/Camera.html .

Открытые аксессуары Android: http://developer.android.com/guide/topics/usb/accessory.html .

API USB-хоста: http://developer.android.com/guide/topics/usb/host.html .

Справочник по безопасности и разрешениям Android: http://developer.android.com/guide/topics/security/permissions.html .

Приложения для Android: http://code.google.com/p/apps-for-android .

Менеджер загрузки Android: http://developer.android.com/reference/android/app/DownloadManager.html .

Передача файлов Android: http://www.android.com/filetransfer

Форматы мультимедиа Android: http://developer.android.com/guide/appendix/media-formats.html .

Проект протокола прямой потоковой передачи HTTP: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

Передача соединения NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

Безопасное простое сопряжение Bluetooth с использованием NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

API многоадресной рассылки Wi-Fi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html .

Помощник по действиям: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST .

Спецификация зарядки USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf .

Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html .

USB-аудио для Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

Настройки общего доступа к NFC для Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS .

Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html .

Виджет блокировки и главного экрана: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html .

Ссылка на UserManager: http://developer.android.com/reference/android/os/UserManager.html .

Ссылка на внешнее хранилище: https://source.android.com/docs/core/storage.

API внешнего хранилища: http://developer.android.com/reference/android/os/Environment.html .

Короткий код SMS: http://en.wikipedia.org/wiki/Short_code

Клиент удаленного управления мультимедиа: http://developer.android.com/reference/android/media/RemoteControlClient.html .

Диспетчер дисплея: http://developer.android.com/reference/android/hardware/display/DisplayManager.html .

Мечты: http://developer.android.com/reference/android/service/dreams/DreamService.html .

Настройки, связанные с разработкой приложений Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS .

Камера: http://developer.android.com/reference/android/hardware/Camera.Parameters.html .

Расширение EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

API событий движения: http://developer.android.com/reference/android/view/MotionEvent.html .

Конфигурация сенсорного ввода: http://source.android.com/docs/core/interaction/input/touch-devices.html .

Юникод 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

Совместимость с WebView: http://www.chromium.org/

Приложение владельца устройства Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html .

Требования к кодированию оборудования RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE .

Средство разрешения контента: http://developer.android.com/reference/android/content/ContentResolver.html .

SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html

Эмуляция карты на основе хоста: http://developer.android.com/guide/topics/connectivity/nfc/hce.html .

Поставщик телефонии: http://developer.android.com/reference/android/provider/Telephony.html .

Многие из этих ресурсов прямо или косвенно получены из Android SDK и функционально идентичны информации в документации этого SDK. В любых случаях, когда данное Определение совместимости или Набор тестов совместимости не согласуются с документацией SDK, документация SDK считается авторитетной. Любые технические детали, представленные в приведенных выше ссылках, считаются частью настоящего определения совместимости.

3. Программное обеспечение

3.1. Совместимость управляемого API

Управляемая среда выполнения (на базе Dalvik) является основным средством для приложений Android. Интерфейс программирования приложений Android (API) — это набор интерфейсов платформы Android, доступных приложениям, работающим в среде управляемой виртуальной машины. Реализации устройств ДОЛЖНЫ обеспечивать полную реализацию, включая все документированное поведение, любого документированного API, предоставляемого Android SDK [ Ресурсы, 4 ].

Реализации устройств НЕ ДОЛЖНЫ исключать какие-либо управляемые API, изменять интерфейсы или сигнатуры API, отклоняться от задокументированного поведения или включать неактивные операции, за исключением случаев, когда это специально разрешено настоящим Определением совместимости.

Это определение совместимости позволяет исключить некоторые типы оборудования, для которых Android включает API, в реализациях устройств. В таких случаях API ДОЛЖНЫ присутствовать и вести себя разумным образом. См. раздел 7 для получения информации о конкретных требованиях для этого сценария.

3.2. Совместимость с программным API

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

3.2.1. Разрешения

Разработчики устройств ДОЛЖНЫ поддерживать и применять все константы разрешений, как описано на справочной странице разрешений [ Ресурсы, 5 ]. Обратите внимание, что в разделе 9 перечислены дополнительные требования, связанные с моделью безопасности Android.

3.2.2. Параметры сборки

API-интерфейсы Android включают ряд констант в классе android.os.Build [ Resources, 6 ], которые предназначены для описания текущего устройства. Чтобы обеспечить согласованные и значимые значения для разных реализаций устройств, в приведенную ниже таблицу включены дополнительные ограничения на форматы этих значений, которым ДОЛЖНЫ соответствовать реализации устройств.

Параметр	Комментарии
ВЕРСИЯ.РЕЛИЗ	Версия действующей в данный момент системы Android в удобочитаемом формате. Это поле ДОЛЖНО иметь одно из строковых значений, определенных в [ Resources, 7 ].
ВЕРСИЯ.SDK	Версия текущей системы Android в формате, доступном для кода сторонних приложений. Для Android 4.4 это поле ДОЛЖНО иметь целое значение 19.
VERSION.SDK_INT	Версия текущей системы Android в формате, доступном для кода сторонних приложений. Для Android 4.4 это поле ДОЛЖНО иметь целое значение 19.
ВЕРСИЯ.ИНКРЕМЕНТАЛЬНАЯ	Значение, выбранное разработчиком устройства, обозначающее конкретную сборку работающей в данный момент системы Android в удобочитаемом формате. Это значение НЕ ДОЛЖНО использоваться повторно для разных сборок, доступных конечным пользователям. Типичное использование этого поля — указать, какой номер сборки или идентификатор изменения системы управления версиями использовался для создания сборки. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
ДОСКА	Значение, выбранное разработчиком устройства, идентифицирующее конкретное внутреннее оборудование, используемое устройством, в удобочитаемом формате. Возможное использование этого поля — указать конкретную версию платы, питающей устройство. Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
БРЕНД	Значение, отражающее торговую марку, связанную с устройством, известную конечным пользователям. ДОЛЖНО быть в удобочитаемом формате и ДОЛЖНО представлять производителя устройства или бренд компании, под которой устройство продается. Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
CPU_ABI	Имя набора инструкций (тип ЦП + соглашение ABI) машинного кода. См. раздел 3.3: Совместимость с собственным API .
CPU_ABI2	Имя второго набора инструкций (тип ЦП + соглашение ABI) машинного кода. См. раздел 3.3: Совместимость с собственным API .
УСТРОЙСТВО	Значение, выбранное разработчиком устройства, содержащее название разработки или кодовое имя, определяющее конфигурацию аппаратных функций и промышленный дизайн устройства. Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
ОТПЕЧАТКИ ПАЛЬЦЕВ	Строка, которая однозначно идентифицирует эту сборку. Он ДОЛЖЕН быть достаточно удобочитаемым для человека. Он ДОЛЖЕН следовать этому шаблону: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Например: `acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys` Отпечаток НЕ ДОЛЖЕН содержать пробелов. Если другие поля, включенные в приведенный выше шаблон, содержат пробельные символы, их НЕОБХОДИМО заменить в отпечатке сборки другим символом, например символом подчеркивания («_»). Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII.
АППАРАТНОЕ ОБЕСПЕЧЕНИЕ	Имя оборудования (из командной строки ядра или /proc). Он ДОЛЖЕН быть достаточно удобочитаемым для человека. Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
ХОЗЯИН	Строка, однозначно идентифицирующая хост, на котором была построена сборка, в удобочитаемом формате. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
ИДЕНТИФИКАТОР	Идентификатор, выбранный разработчиком устройства для ссылки на конкретную версию, в удобочитаемом формате. Это поле может быть таким же, как android.os.Build.VERSION.INCREMENTAL, но ДОЛЖНО быть значением, достаточно значимым, чтобы конечные пользователи могли различать сборки программного обеспечения. Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
ПРОИЗВОДИТЕЛЬ	Торговое название производителя оригинального оборудования (OEM) продукта. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
МОДЕЛЬ	Значение, выбранное разработчиком устройства, содержащее имя устройства, известное конечному пользователю. Это ДОЛЖНО быть то же имя, под которым устройство продается конечным пользователям. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
ПРОДУКТ	Значение, выбранное разработчиком устройства, содержащее название разработки или кодовое название конкретного продукта (SKU), которое ДОЛЖНО быть уникальным в пределах одной торговой марки. ДОЛЖЕН быть удобочитаемым, но не обязательно предназначен для просмотра конечными пользователями. Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
СЕРИАЛ	Серийный номер оборудования, который ДОЛЖЕН быть доступен. Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^([a-zA-Z0-9]{6,20})$"` .
ТЕГИ	Разделенный запятыми список тегов, выбранный разработчиком устройства, который дополнительно отличает сборку. Например, «без знака, отладка». Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
ВРЕМЯ	Значение, представляющее отметку времени, когда произошла сборка.
ТИП	Значение, выбранное разработчиком устройства, определяющее конфигурацию сборки во время выполнения. Это поле ДОЛЖНО иметь одно из значений, соответствующих трем типичным конфигурациям среды выполнения Android: «user», «userdebug» или «eng». Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению `"^[a-zA-Z0-9.,_-]+$"` .
ПОЛЬЗОВАТЕЛЬ	Имя или идентификатор пользователя (или автоматического пользователя), создавшего сборку. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").

3.2.3. Совместимость по намерениям

Реализации устройств ДОЛЖНЫ соблюдать слабую систему намерений Android, как описано в разделах ниже. Под «уважением» подразумевается, что разработчик устройства ДОЛЖЕН предоставить действие или службу Android, которые указывают соответствующий фильтр намерения, а также привязываются и реализуют правильное поведение для каждого указанного шаблона намерения.

3.2.3.1. Основные цели приложения

Проект Android upstream определяет ряд основных приложений, таких как контакты, календарь, фотогалерея, музыкальный проигрыватель и т. д. Разработчики устройств МОГУТ заменить эти приложения альтернативными версиями.

Однако любые такие альтернативные версии ДОЛЖНЫ учитывать те же шаблоны намерений, которые предоставлены вышестоящим проектом. Например, если устройство содержит альтернативный музыкальный проигрыватель, оно все равно должно учитывать шаблон намерения, выдаваемый сторонними приложениями, для выбора песни.

Следующие приложения считаются основными системными приложениями Android:

Настольные часы
Браузер
Календарь
Контакты
Галерея
Глобальный поиск
пусковая установка
Музыка
Настройки

Основные системные приложения Android включают в себя различные компоненты действий или служб, которые считаются «общедоступными». То есть атрибут «android:exported» может отсутствовать или иметь значение «true».

Для каждого действия или службы, определенного в одном из основных системных приложений Android, которое не помечено как закрытое с помощью атрибута android:exported со значением «false», реализации устройства ДОЛЖНЫ включать компонент того же типа, реализующий один и тот же фильтр намерений. шаблоны в качестве основного системного приложения Android.

Другими словами, реализация устройства МОЖЕТ заменить основные системные приложения Android; однако, если это так, реализация устройства ДОЛЖНА поддерживать все шаблоны намерений, определенные каждым заменяемым основным системным приложением Android.

3.2.3.2. Переопределение намерения

Поскольку Android является расширяемой платформой, реализации устройства ДОЛЖНЫ позволять переопределять каждый шаблон намерения, указанный в разделе 3.2.3.1, сторонними приложениями. Вышестоящая реализация Android с открытым исходным кодом позволяет это по умолчанию; Разработчики устройств НЕ ДОЛЖНЫ присваивать специальные привилегии использованию системными приложениями этих шаблонов намерений или запрещать сторонним приложениям привязываться к этим шаблонам и брать на себя управление ими. Этот запрет, в частности, включает, помимо прочего, отключение пользовательского интерфейса «Выборщик», который позволяет пользователю выбирать между несколькими приложениями, которые обрабатывают один и тот же шаблон намерения.

Однако реализации устройств МОГУТ обеспечивать действия по умолчанию для определенных шаблонов URI (например, http://play.google.com), если действие по умолчанию предоставляет более конкретный фильтр для URI данных. Например, фильтр намерений, указывающий URI данных «http://www.android.com», является более конкретным, чем фильтр браузера для «http://». Реализации устройств ДОЛЖНЫ предоставлять пользователям пользовательский интерфейс для изменения активности по умолчанию для намерений.

3.2.3.3. Пространства имен намерений

Реализации устройств НЕ ДОЛЖНЫ включать в себя какой-либо компонент Android, который учитывает любые новые шаблоны Intent или Broadcast Intent с использованием ACTION, CATEGORY или другой ключевой строки в пространстве имен android.* или com.android.*. Разработчики устройств НЕ ДОЛЖНЫ включать какие-либо компоненты Android, которые учитывают любые новые шаблоны намерений или широковещательных намерений с использованием ДЕЙСТВИЯ, КАТЕГОРИИ или другой ключевой строки в пространстве пакета, принадлежащем другой организации. Разработчики устройств НЕ ДОЛЖНЫ изменять или расширять какие-либо шаблоны намерений, используемые основными приложениями, перечисленными в разделе 3.2.3.1. Реализации устройств МОГУТ включать шаблоны намерений, использующие пространства имен, явно и явно связанные с их собственной организацией.

Этот запрет аналогичен тому, который указан для классов языка Java в разделе 3.6.

3.2.3.4. Намерения трансляции

Сторонние приложения полагаются на платформу для трансляции определенных намерений, чтобы уведомить их об изменениях в аппаратной или программной среде. Android-совместимые устройства ДОЛЖНЫ транслировать общедоступные широковещательные намерения в ответ на соответствующие системные события. Намерения трансляции описаны в документации SDK.

3.2.3.5. Настройки приложения по умолчанию

В Android 4.4 добавлены настройки, которые позволяют пользователям выбирать приложения Home и SMS по умолчанию. Реализации устройств ДОЛЖНЫ предоставлять одинаковое меню пользовательских настроек для каждого, совместимое с шаблоном фильтра намерений и методами API, описанными в документации SDK [ Ресурсы, 91 ].

3.3. Совместимость с собственным API

3.3.1 Бинарные интерфейсы приложений

Управляемый код, работающий в Dalvik, может вызывать собственный код, представленный в файле .apk приложения в виде файла ELF .so, скомпилированного для соответствующей аппаратной архитектуры устройства. Поскольку собственный код сильно зависит от базовой технологии процессора, Android определяет ряд двоичных интерфейсов приложений (ABI) в Android NDK, в файле docs/CPU-ARCH-ABIS.html . Если реализация устройства совместима с одним или несколькими определенными ABI, ей СЛЕДУЕТ реализовать совместимость с Android NDK, как показано ниже.

Если реализация устройства включает поддержку Android ABI, она:

ДОЛЖНА включать поддержку кода, выполняющегося в управляемой среде, для вызова собственного кода с использованием стандартной семантики Java Native Interface (JNI).
ДОЛЖЕН быть совместим с исходным кодом (т. е. совместимым с заголовком) и двоично-совместимым (для ABI) с каждой необходимой библиотекой из списка ниже.
ДОЛЖЕН точно сообщать о собственном двоичном интерфейсе приложения (ABI), поддерживаемом устройством, через API android.os.Build.CPU_ABI и параметры android.os.Build.CPU_ABI2 .
ДОЛЖЕН сообщать через android.os.Build.CPU_ABI2 только те ABI, которые задокументированы в последней версии Android NDK, в файле docs/CPU-ARCH-ABIS.html
ДОЛЖЕН сообщать через android.os.Build.CPU_ABI только один из ABI, перечисленных ниже.

армеаби-v7a
х86
мипы

СЛЕДУЕТ создавать с использованием исходного кода и файлов заголовков, доступных в исходном проекте Android с открытым исходным кодом.

Следующие API-интерфейсы собственного кода ДОЛЖНЫ быть доступны для приложений, содержащих собственный код:

libc (библиотека C)
libm (математическая библиотека)
Минимальная поддержка C++.
JNI-интерфейс
liblog (ведение журнала Android)
libz (сжатие Zlib)
libdl (динамический компоновщик)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.0)
libEGL.so (собственное управление поверхностью OpenGL)
libjnigraphics.so
libOpenSLES.so (поддержка звука OpenSL ES 1.0.1)
libOpenMAXAL.so (поддержка OpenMAX AL 1.0.1)
libandroid.so (встроенная поддержка активности Android)
Поддержка OpenGL, как описано ниже.

Обратите внимание, что в будущих выпусках Android NDK может появиться поддержка дополнительных ABI. Если реализация устройства несовместима с существующим предопределенным ABI, оно вообще НЕ ДОЛЖНО сообщать о поддержке какого-либо ABI.

Обратите внимание, что реализации устройства ДОЛЖНЫ включать libGLESv3.so и ДОЛЖНЫ символизировать (символическую) ссылку на libGLESv2.so. В реализациях устройств, в которых заявлена поддержка OpenGL ES 3.0, libGLESv2.so ДОЛЖЕН экспортировать функциональные символы OpenGL ES 3.0 в дополнение к функциональным символам OpenGL ES 2.0.

Совместимость нативного кода является сложной задачей. По этой причине следует повторить, что разработчикам устройств ОЧЕНЬ настоятельно рекомендуется использовать вышестоящие реализации библиотек, перечисленных выше, чтобы обеспечить совместимость.

3.4. Веб-совместимость

3.4.1. Совместимость с веб-представлением

Реализация Android с открытым исходным кодом использует код из проекта Chromium для реализации android.webkit.WebView [ Resources, 10 ]. Поскольку разработать комплексный набор тестов для системы веб-рендеринга невозможно, разработчики устройств ДОЛЖНЫ использовать конкретную исходную сборку Chromium в реализации WebView. Конкретно:

Реализации устройства android.webkit.WebView ДОЛЖНЫ быть основаны на сборке Chromium из исходного проекта Android с открытым исходным кодом для Android 4.4. Эта сборка включает определенный набор исправлений функциональности и безопасности для WebView. [ Ресурсы, 83 ]
Строка пользовательского агента, сообщаемая WebView, ДОЛЖНА быть в этом формате:
Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Значение строки $(VERSION) ДОЛЖНО быть таким же, как значение для android.os.Build.VERSION.RELEASE .
- Значение строки $(LOCALE) является необязательным, ДОЛЖНО соответствовать соглашениям ISO для кода страны и языка и ДОЛЖНО ссылаться на текущий настроенный языковой стандарт устройства. Если этот параметр опущен, конечная точка с запятой также ДОЛЖНА быть удалена.
- Значение строки $(MODEL) ДОЛЖНО быть таким же, как значение для android.os.Build.MODEL .
- Значение строки $(BUILD) ДОЛЖНО быть таким же, как значение android.os.Build.ID .
- Значение строки $(CHROMIUM_VER) ДОЛЖНО соответствовать версии Chromium в исходном проекте Android с открытым исходным кодом.
- Реализации устройства МОГУТ опускать Mobile в строке пользовательского агента.

Компонент WebView ДОЛЖЕН включать поддержку как можно большей части HTML5 [ Ресурсы, 11 ].

3.4.2. Совместимость браузера

Реализации устройства ДОЛЖНЫ включать автономное приложение-браузер для просмотра веб-страниц обычными пользователями. Автономный браузер МОЖЕТ быть основан на браузерной технологии, отличной от WebKit. Однако даже если используется альтернативное браузерное приложение, компонент android.webkit.WebView , предоставляемый сторонним приложениям, ДОЛЖЕН быть основан на WebKit, как описано в разделе 3.4.1.

Реализации МОГУТ отправлять специальную строку пользовательского агента в автономное приложение браузера.

Автономное приложение браузера (будь то на основе исходного приложения браузера WebKit или сторонней замены) ДОЛЖНО включать поддержку как можно большей части HTML5 [ Ресурсы, 11 ]. Как минимум, реализации устройств ДОЛЖНЫ поддерживать каждый из этих API, связанных с HTML5:

кэш приложения/автономная работа [ Ресурсы, 12 ]
тег <video> [ Ресурсы, 13 ]
геолокация [ Ресурсы, 14 ]

Кроме того, реализации устройств ДОЛЖНЫ поддерживать API веб-хранилища HTML5/W3C [ Ресурсы, 15 ] и ДОЛЖНЫ поддерживать API HTML5/W3C IndexedDB [ Ресурсы, 16 ]. Обратите внимание: поскольку органы по стандартизации веб-разработки отдают предпочтение IndexedDB веб-хранилищу, ожидается, что IndexedDB станет обязательным компонентом в будущей версии Android.

3.5. Поведенческая совместимость API

Поведение каждого из типов API (управляемого, программного, собственного и веб-интерфейса) должно соответствовать предпочтительной реализации исходного проекта Android с открытым исходным кодом [ Ресурсы, 3 ]. Некоторые конкретные области совместимости:

Устройства НЕ ДОЛЖНЫ менять поведение или семантику стандартного намерения.
Устройства НЕ ДОЛЖНЫ изменять жизненный цикл или семантику жизненного цикла определенного типа системного компонента (например, Сервиса, Действия, ContentProvider и т. д.).
Устройства НЕ ДОЛЖНЫ менять семантику стандартного разрешения.

Приведенный выше список не является исчерпывающим. Набор тестов совместимости (CTS) проверяет значительные части платформы на поведенческую совместимость, но не все. Разработчик несет ответственность за обеспечение поведенческой совместимости с проектом Android с открытым исходным кодом. По этой причине разработчики устройств ДОЛЖНЫ использовать исходный код, доступный через проект Android с открытым исходным кодом, где это возможно, а не повторно реализовывать значительные части системы.

3.6. Пространства имен API

Android следует соглашениям о пространствах имен пакетов и классов, определенным языком программирования Java. Чтобы обеспечить совместимость со сторонними приложениями, разработчики устройств НЕ ДОЛЖНЫ вносить какие-либо запрещенные изменения (см. ниже) в эти пространства имен пакетов:

Джава.*
javax.*
солнце.*
андроид.*
com.android.*

К запрещенным модификациям относятся:

Реализации устройств НЕ ДОЛЖНЫ модифицировать общедоступные API на платформе Android, изменяя какие-либо методы или сигнатуры классов или удаляя классы или поля классов.
Разработчики устройств МОГУТ изменять базовую реализацию API, но такие модификации НЕ ДОЛЖНЫ влиять на заявленное поведение и подпись языка Java любых общедоступных API.
Разработчики устройств НЕ ДОЛЖНЫ добавлять какие-либо общедоступные элементы (такие как классы или интерфейсы, поля или методы к существующим классам или интерфейсам) к API-интерфейсам, указанным выше.

«Общедоступный элемент» — это любая конструкция, которая не украшена маркером «@hide», который используется в исходном коде Android. Другими словами, разработчики устройств НЕ ДОЛЖНЫ предоставлять новые API или изменять существующие API в пространствах имен, указанных выше. Разработчики устройств МОГУТ вносить модификации только для внутреннего использования, но эти модификации НЕ ДОЛЖНЫ рекламироваться или иным образом раскрываться разработчикам.

Разработчики устройств МОГУТ добавлять собственные API, но любые такие API НЕ ДОЛЖНЫ находиться в пространстве имен, принадлежащем другой организации или ссылаясь на нее. Например, разработчики устройств НЕ ДОЛЖНЫ добавлять API в com.google.* или подобное пространство имен; только Google может это сделать. Аналогично, Google НЕ ДОЛЖЕН добавлять API в пространства имен других компаний. Кроме того, если реализация устройства включает пользовательские API вне стандартного пространства имен Android, эти API ДОЛЖНЫ быть упакованы в общую библиотеку Android, чтобы увеличение использования памяти затрагивало только приложения, которые их явно используют (через механизм <uses-library> ). таких API.

Если разработчик устройства предлагает улучшить одно из пространств имен пакетов, указанных выше (например, путем добавления новых полезных функций к существующему API или добавления нового API), разработчик ДОЛЖЕН посетить source.android.com и начать процесс внесения изменений и код, согласно информации на этом сайте.

Обратите внимание, что приведенные выше ограничения соответствуют стандартным соглашениям об именовании API в языке программирования Java; цель этого раздела – просто усилить эти соглашения и сделать их обязательными путем включения в определение совместимости.

3.7. Совместимость виртуальных машин

Реализации устройств ДОЛЖНЫ поддерживать полную спецификацию байт-кода исполняемого файла Dalvik (DEX) и семантику виртуальной машины Dalvik [ Ресурсы, 17 ].

Реализации устройства ДОЛЖНЫ настроить Dalvik для выделения памяти в соответствии с исходной платформой Android и как указано в следующей таблице. (См. раздел 7.1.1 для определения размера экрана и плотности экрана.)

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

Размер экрана	Плотность экрана	Память приложений
маленький/нормальный/большой	лдпи/мдпи	16 МБ
маленький/нормальный/большой	твдпи/хдпи	32 МБ
маленький/нормальный/большой	xhdpi	64 МБ
маленький/нормальный/большой	400 точек на дюйм	96 МБ
маленький/нормальный/большой	xxhdpi	128 МБ
маленький/нормальный/большой	xxxhdpi	256 МБ
большой	мдпи	32 МБ
большой	твдпи/хдпи	64 МБ
большой	xhdpi	128 МБ
большой	400 точек на дюйм	192 МБ
большой	xxhdpi	256 МБ
большой	xxxhdpi	512 МБ

3.8. Совместимость пользовательского интерфейса

3.8.1. Панель запуска (главный экран)

Android включает в себя приложение запуска (главный экран) и поддержку сторонних приложений, заменяющих средство запуска устройства (главный экран). Реализации устройств, которые позволяют сторонним приложениям заменять главный экран устройства, ДОЛЖНЫ объявить функцию платформы android.software.home_screen .

3.8.2. Виджеты

Android определяет тип компонента, соответствующий API и жизненный цикл, который позволяет приложениям предоставлять конечным пользователям «AppWidget» [ Ресурсы, 18 ]. Реализации устройств, поддерживающие встраивание виджетов на главный экран, ДОЛЖНЫ соответствовать следующим требованиям и декларировать поддержку функции платформы android.software.app_widgets .

Средства запуска устройств ДОЛЖНЫ включать встроенную поддержку AppWidgets и предоставлять возможности пользовательского интерфейса для добавления, настройки, просмотра и удаления AppWidgets непосредственно в средстве запуска.
Реализации устройств ДОЛЖНЫ быть способны отображать виджеты размером 4 x 4 в стандартной сетке. (Подробную информацию см. в Руководстве по проектированию виджетов приложений в документации Android SDK [ Ресурсы, 18 ].
Реализации устройств, включающие поддержку экрана блокировки, ДОЛЖНЫ поддерживать виджеты приложений на экране блокировки.

3.8.3. Уведомления

Android включает API, которые позволяют разработчикам уведомлять пользователей о заметных событиях [ Ресурсы, 19 ], используя аппаратные и программные возможности устройства.

Некоторые API позволяют приложениям отправлять уведомления или привлекать внимание с помощью оборудования, в частности звука, вибрации и света. Реализации устройств ДОЛЖНЫ поддерживать уведомления, использующие аппаратные функции, как описано в документации SDK, и, насколько это возможно, с использованием аппаратных средств реализации устройства. Например, если реализация устройства включает в себя вибратор, оно ДОЛЖНО правильно реализовать API вибрации. Если в реализации устройства отсутствует аппаратное обеспечение, соответствующие API ДОЛЖНЫ быть реализованы как не требующие операций. Обратите внимание, что это поведение более подробно описано в разделе 7.

Кроме того, реализация ДОЛЖНА правильно отображать все ресурсы (значки, звуковые файлы и т. д.), предусмотренные в API [ Ресурсы, 20 ] или в руководстве по стилю значков строки состояния/системной строки [ Ресурсы, 21 ]. Разработчики устройств МОГУТ предоставлять альтернативный пользовательский интерфейс для уведомлений, чем тот, который предоставляется эталонной реализацией Android с открытым исходным кодом; однако такие альтернативные системы уведомлений ДОЛЖНЫ поддерживать существующие ресурсы уведомлений, как указано выше.

Android включает поддержку расширенных уведомлений, таких как интерактивные представления текущих уведомлений. Реализации устройств ДОЛЖНЫ правильно отображать и выполнять расширенные уведомления, как описано в API Android.

3.8.4. Поиск

Android включает API [ Ресурсы, 22 ], которые позволяют разработчикам включать поиск в свои приложения и предоставлять данные своих приложений для глобального системного поиска. Вообще говоря, эта функциональность состоит из единого общесистемного пользовательского интерфейса, который позволяет пользователям вводить запросы, отображает предложения по мере ввода пользователем и отображает результаты. API-интерфейсы Android позволяют разработчикам повторно использовать этот интерфейс для обеспечения поиска в своих собственных приложениях, а также позволяют разработчикам предоставлять результаты в общий пользовательский интерфейс глобального поиска.

Реализации устройств ДОЛЖНЫ включать единый общий общесистемный пользовательский интерфейс поиска, способный в режиме реального времени предлагать предложения в ответ на ввод пользователя. Реализации устройств ДОЛЖНЫ реализовывать API, которые позволяют разработчикам повторно использовать этот пользовательский интерфейс для обеспечения поиска в своих собственных приложениях. Реализации устройств ДОЛЖНЫ реализовывать API-интерфейсы, которые позволяют сторонним приложениям добавлять предложения в поле поиска, когда оно запускается в режиме глобального поиска. Если не установлены сторонние приложения, использующие эту функцию, поведением по умолчанию ДОЛЖНО быть отображение результатов и предложений веб-поисковой системы.

3.8.5. Тосты

Приложения могут использовать API «Toast» (определенный в [ Ресурсы, 23 ]) для отображения конечным пользователям коротких немодальных строк, которые исчезают через короткий период времени. Реализации устройств ДОЛЖНЫ отображать всплывающие уведомления от приложений конечным пользователям в наглядной форме.

3.8.6. Темы

Android предоставляет «темы» как механизм, позволяющий приложениям применять стили ко всему действию или приложению.

Android включает семейство тем «Holo» как набор определенных стилей, которые разработчики приложений могут использовать, если они хотят соответствовать внешнему виду темы Holo, определенному Android SDK [ Ресурсы, 24 ]. Реализации устройств НЕ ДОЛЖНЫ изменять какие-либо атрибуты темы Holo, доступные приложениям [ Ресурсы, 25 ].

Android также включает семейство тем «Device Default» как набор определенных стилей, которые разработчики приложений могут использовать, если они хотят соответствовать внешнему виду темы устройства, как определено разработчиком устройства. Реализации устройств МОГУТ изменять атрибуты темы DeviceDefault, доступные приложениям [ Ресурсы, 25 ].

Начиная с версии 4.4, Android теперь поддерживает новый вариант темы с полупрозрачными системными панелями, позволяющий разработчикам приложений заполнять область за строкой состояния и панелью навигации содержимым своего приложения. Чтобы обеспечить единообразный интерфейс разработчика в этой конфигурации, важно, чтобы стиль значков строки состояния сохранялся на разных реализациях устройств. Поэтому реализации устройств Android ДОЛЖНЫ использовать белый цвет для значков состояния системы (таких как уровень сигнала и уровень заряда батареи) и уведомлений, выдаваемых системой, если только значок не указывает на проблемное состояние [ Ресурсы, 25 ].

3.8.7. Живые обои

Android определяет тип компонента, соответствующий API и жизненный цикл, который позволяет приложениям предоставлять конечному пользователю один или несколько «живых обоев» [ Ресурсы, 26 ]. Живые обои — это анимация, узоры или подобные изображения с ограниченными возможностями ввода, которые отображаются в качестве обоев позади других приложений.

Аппаратное обеспечение считается способным надежно воспроизводить живые обои, если оно может запускать все живые обои без ограничений по функциональности, с разумной частотой кадров и без негативного воздействия на другие приложения. Если ограничения в аппаратном обеспечении приводят к сбою, сбоям в работе обоев и/или приложений, чрезмерному потреблению энергии процессора или аккумулятора или работе с неприемлемо низкой частотой кадров, оборудование считается неспособным использовать живые обои. Например, некоторые живые обои могут использовать контекст Open GL 1.0 или 2.0 для отображения своего содержимого. Живые обои не будут надежно работать на оборудовании, которое не поддерживает несколько контекстов OpenGL, поскольку использование контекста OpenGL в живых обоях может конфликтовать с другими приложениями, которые также используют контекст OpenGL.

Реализации устройств, способные надежно запускать живые обои, как описано выше, ДОЛЖНЫ реализовывать живые обои. Реализации устройств, которые не обеспечивают надежное использование живых обоев, как описано выше, НЕ ДОЛЖНЫ реализовывать живые обои.

3.8.8. Отображение последних приложений

Исходный код Android включает в себя пользовательский интерфейс для отображения последних приложений с использованием миниатюрного изображения графического состояния приложения на момент последнего выхода пользователя из приложения. Реализации устройства МОГУТ изменить или исключить этот пользовательский интерфейс; однако планируется, что в будущей версии Android эта функция будет использоваться более широко. В реализациях устройств настоятельно рекомендуется использовать исходный пользовательский интерфейс Android (или аналогичный интерфейс на основе эскизов) для последних приложений, иначе они могут быть несовместимы с будущей версией Android.

3.8.9. Управление вводом

Android включает поддержку управления вводом и поддержку сторонних редакторов методов ввода. Реализации устройств, которые позволяют пользователям использовать сторонние методы ввода на устройстве, ДОЛЖНЫ объявить функцию платформы android.software.input_methods и поддерживать API-интерфейсы IME, как определено в документации Android SDK.

Реализации устройств, в которых объявляется функция android.software.input_methods , ДОЛЖНЫ предоставлять доступный пользователю механизм для добавления и настройки сторонних методов ввода. Реализации устройства ДОЛЖНЫ отображать интерфейс настроек в ответ на намерение android.settings.INPUT_METHOD_SETTINGS .

3.8.10. Пульт дистанционного управления экраном блокировки мультимедиа

Android включает поддержку API удаленного управления, который позволяет мультимедийным приложениям интегрироваться с элементами управления воспроизведением, которые отображаются в удаленном представлении, например, на экране блокировки устройства [ Ресурсы, 74 ]. Реализации устройств, которые поддерживают экран блокировки на устройстве и позволяют пользователям добавлять виджеты на главный экран, ДОЛЖНЫ включать поддержку встраивания пультов дистанционного управления в экран блокировки устройства [ Ресурсы, 69 ].

3.8.11. Мечты

Android включает поддержку интерактивных заставок под названием Dreams [ Ресурсы, 76 ]. Dreams позволяет пользователям взаимодействовать с приложениями, когда зарядное устройство не используется или подключено к настольной док-станции. Реализации устройств ДОЛЖНЫ включать поддержку Dreams и предоставлять пользователям возможность настройки Dreams.

3.8.12. Расположение

Режимы местоположения ДОЛЖНЫ отображаться в меню «Местоположение» в настройках [ Ресурсы, 87 ]. Службы определения местоположения, предоставляемые через SettingInjectorService , представленные в Android 4.4, должны отображаться в том же меню местоположения [ Resources, 89 ].

3.8.13. Юникод

Android 4.4 включает поддержку цветных символов эмодзи. Реализации устройств Android ДОЛЖНЫ предоставлять пользователю метод ввода символов Emoji, определенных в Unicode 6.1 [ Resources, 82 ], и ДОЛЖНЫ быть способны отображать эти символы Emoji в цветном глифе.

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

Android включает в себя функции, которые позволяют приложениям, обеспечивающим безопасность, выполнять функции администрирования устройства на уровне системы, такие как применение политик паролей или удаленное удаление данных, через API администрирования устройств Android [ Ресурсы, 27 ]. Реализации устройств ДОЛЖНЫ обеспечивать реализацию класса DevicePolicyManager [ Resources, 28 ]. Реализации устройств, включающие поддержку экрана блокировки, ДОЛЖНЫ поддерживать полный спектр политик администрирования устройства, определенных в документации Android SDK [ Ресурсы, 27 ].

Реализации устройств МОГУТ иметь предустановленное приложение, выполняющее функции администрирования устройства, но это приложение НЕ ДОЛЖНО быть установлено «из коробки» в качестве приложения владельца устройства по умолчанию [ Ресурсы, 84 ].

3.10. Доступность

Android предоставляет уровень доступности, который помогает пользователям с ограниченными возможностями легче перемещаться по своим устройствам. Кроме того, Android предоставляет API-интерфейсы платформы, которые позволяют реализации службы специальных возможностей получать обратные вызовы для пользовательских и системных событий и генерировать альтернативные механизмы обратной связи, такие как преобразование текста в речь, тактильную обратную связь и навигацию с помощью трекбола/d-pad [ Ресурсы, 29 ]. Реализации устройств ДОЛЖНЫ обеспечивать реализацию инфраструктуры специальных возможностей Android, соответствующую реализации Android по умолчанию. В частности, реализации устройств ДОЛЖНЫ соответствовать следующим требованиям.

Реализации устройств ДОЛЖНЫ поддерживать реализации сторонних служб доступности через API-интерфейсы android.accessibilityservice [ Ресурсы, 30 ].
Реализации устройств ДОЛЖНЫ генерировать AccessibilityEvents и доставлять эти события всем зарегистрированным реализациям AccessibilityService в соответствии с реализацией Android по умолчанию.
Реализации устройств ДОЛЖНЫ предоставлять доступный пользователю механизм для включения и отключения служб специальных возможностей и ДОЛЖНЫ отображать этот интерфейс в ответ на намерение android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS .

Кроме того, реализации устройства ДОЛЖНЫ обеспечивать реализацию службы доступности на устройстве и ДОЛЖНЫ предоставлять пользователям механизм включения службы доступности во время настройки устройства. Реализация службы доступности с открытым исходным кодом доступна в проекте Eyes Free [ Ресурсы, 31 ].

3.11. Текст в речь

Android включает API, которые позволяют приложениям использовать службы преобразования текста в речь (TTS), а также позволяют поставщикам услуг предоставлять реализации служб TTS [ Ресурсы, 32 ]. Реализации устройств ДОЛЖНЫ соответствовать следующим требованиям, связанным с платформой Android TTS:

Реализации устройств ДОЛЖНЫ поддерживать API-интерфейсы платформы TTS Android и ДОЛЖНЫ включать механизм TTS, поддерживающий языки, доступные на устройстве. Обратите внимание, что исходное программное обеспечение Android с открытым исходным кодом включает в себя полнофункциональную реализацию механизма TTS.
Реализации устройств ДОЛЖНЫ поддерживать установку сторонних механизмов TTS.
Реализации устройств ДОЛЖНЫ предоставлять доступный пользователю интерфейс, который позволяет пользователям выбирать механизм TTS для использования на уровне системы.

4. Совместимость пакетов приложений

Реализации устройств должны установить и запускать файлы Android ".apk", сгенерированные инструментом «AAPT», включенным в официальный Android SDK [ Resources, 33 ].

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

5. Мультимедийная совместимость

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

5.1. Медиакодеки

Реализации устройств должны поддерживать основные форматы носителя, указанные в документации Android SDK [ Resources, 58 ], за исключением случаев, когда явно разрешен в этом документе. В частности, реализации устройств должны поддерживать форматы носителя, кодеры, декодеры, типы файлов и форматы контейнеров, определенные в приведенных ниже таблицах. Все эти кодеки предоставляются в виде программных реализаций в предпочтительной реализации Android из проекта Android с открытым исходным кодом.

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

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

Тип	Формат/Кодек	Кодер	Декодер	Подробности	Тип файла (ы) / форматы контейнеров
Аудио	MPEG-4 AAC профиль (AAC LC)	Требуется для реализаций устройств, которые включают аппаратное обеспечение микрофона и определяют `android.hardware.microphone` .	НЕОБХОДИМЫЙ	Поддержка моно/стерео/5,0/5,1* содержание со стандартными скоростями отбора проб от 8 до 48 кГц.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, декодирование в Android 3.1+, кодирование в Android 4.0+, ADIF не поддерживается) MPEG-TS (.ts, поиск недоступен, Android 3.0+)
	Профиль MPEG-4 HE AAC (AAC+)	Требуется для реализаций устройств, которые включают аппаратное обеспечение микрофона и определяют android.hardware.microphone	НЕОБХОДИМЫЙ	Поддержка моно/стерео/5,0/5,1* Содержание со стандартными скоростями отбора проб от 16 до 48 кГц.
	MPEG-4 HE AAC V2 Profile (улучшенный AAC+)		НЕОБХОДИМЫЙ	Поддержка моно/стерео/5,0/5,1* Содержание со стандартными скоростями отбора проб от 16 до 48 кГц.
	MPEG-4 Audio Object Type ER AAC ELD (расширенная низкая задержка AAC)	Требуется для реализаций устройств, которые включают аппаратное обеспечение микрофона и определяют android.hardware.microphone	НЕОБХОДИМЫЙ	Поддержка моно/стерео контента со стандартной частотой дискретизации от 16 до 48 кГц.
	АМР-НБ	Требуется для реализаций устройств, которые включают аппаратное обеспечение микрофона и определяют `android.hardware.microphone` .	НЕОБХОДИМЫЙ	От 4,75 до 12,2 кбит/с, дискретизация при 8 кГц	3GPP (.3gp)
	УПП-ВБ	Требуется для реализаций устройств, которые включают аппаратное обеспечение микрофона и определяют `android.hardware.microphone` .	НЕОБХОДИМЫЙ	9 скоростей от 6,60 кбит/с до 23,85 кбит/с с дискретизацией при 16 кГц	3GPP (.3gp)
	ФЛАК		НЕОБХОДИМЫЙ (Андроид 3.1+)	Моно/Стерео (без многоканального режима). Частота дискретизации до 48 кГц (но на устройствах с выходом 44,1 кГц рекомендуется до 44,1 кГц, поскольку понижающий преобразователь от 48 до 44,1 кГц не включает фильтр нижних частот). рекомендуется 16-битная версия; для 24-битного режима дизеринг не применяется.	Только FLAC (.flac)
	МП3		НЕОБХОДИМЫЙ	Mono/Stereo 8-320 кбит/с.	MP3 (.mp3)
	МИДИ		НЕОБХОДИМЫЙ	Тип MIDI 0 и 1. DLS версии 1 и 2. XMF и Mobile XMF. Поддержка форматов рингтонов RTTTL/RTX, OTA и iMelody.	Введите 0 и 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) ОТА (.ota) iMelody (.imy)
	Ворбис		НЕОБХОДИМЫЙ		Огг (.ogg) Матроска (.mkv)
	ПКМ/ВОЛНА	НЕОБХОДИМЫЙ	НЕОБХОДИМЫЙ	8-битный и 16-битный линейный PCM ** (ставки до предела оборудования). Должны поддерживать скорости отбора проб для записи необработанной ПКМ на частотах 8000 16000 и 44100 Гц.	ВОЛНА (.wav)
Изображение	JPEG	НЕОБХОДИМЫЙ	НЕОБХОДИМЫЙ	Базовый+прогрессивный	JPEG (.jpg)
	гифка		НЕОБХОДИМЫЙ		GIF (.gif)
	PNG	НЕОБХОДИМЫЙ	НЕОБХОДИМЫЙ		PNG (.png)
	БМП		НЕОБХОДИМЫЙ		БМП (.bmp)
	ВЕБП	НЕОБХОДИМЫЙ	НЕОБХОДИМЫЙ		ВебП (.webp)
видео	H.263	Требуется для реализаций устройств, которые включают аппаратное обеспечение камеры и определяют `android.hardware.camera` или `android.hardware.camera.front` .	НЕОБХОДИМЫЙ		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 АВК	Требуется для реализаций устройств, которые включают аппаратное обеспечение камеры и определяют `android.hardware.camera` или `android.hardware.camera.front` .	НЕОБХОДИМЫЙ	Базовый профиль (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, только AAC Audio, не иссяк, Android 3.0+)
	МПЕГ-4 СП		НЕОБХОДИМЫЙ		3GPP (.3gp)
	VP8 ****	НЕОБХОДИМЫЙ (Андроид 4.3+)	НЕОБХОДИМЫЙ (Андроид 2.3.3+)		Webm (.webm) и matroska (.mkv, android 4.0+) ***
	ВП9		НЕОБХОДИМЫЙ (Андроид 4.4+)		Webm (.webm) и matroska (.mkv, android 4.0+) ***

*ПРИМЕЧАНИЕ. Требуется только понижающая миска 5.0/5.1. запись или рендеринг более 2 каналов не являются обязательными.
** Примечание: 16-битный линейный захват PCM является обязательным. 8-битный линейный захват PCM не является обязательным.
*** ПРИМЕЧАНИЕ. Реализации устройств должны поддерживать написание файлов matroska webm.
**** ПРИМЕЧАНИЕ. Для приемлемого качества потоковой передачи веб-видео и видеоконференций, реализации устройств должны использовать аппаратный кодек VP8, который соответствует требованиям в [ ресурсах, 86 ].

5.2. Кодирование видео

Реализации устройств Android, которые включают в себя камеру сзади и объявляют android.hardware.camera , должны поддерживать следующие профили кодирования видео H.264.

	SD (низкое качество)	SD (высокое качество)	HD (при поддержке аппаратного обеспечения)
Разрешение видео	176 x 144 пк	480 x 360 px	1280 х 720 пикселей
Частота кадров видео	12 кадров в секунду	30 кадров в секунду	30 кадров в секунду
Битрейт видео	56 кбит / с	500 кбит / с или выше	2 Мбит / с или выше
Аудиокодек	AAC-LC	AAC-LC	AAC-LC
Аудиоканалы	1 (моно)	2 (стерео)	2 (стерео)
Аудио битрейт	24 кбит / с	128 кбит / с	192 Кбит/с

Реализации устройств Android, которые включают в себя камеру сзади и объявить android.hardware.camera должны поддерживать следующие профили кодирования видео VP8

	SD (низкое качество)	SD (высокое качество)	HD 720p (При поддержке аппаратного обеспечения)	HD 1080p (При поддержке аппаратного обеспечения)
Разрешение видео	320 х 180 пикселей	640 х 360 пикселей	1280 х 720 пикселей	1920 х 1080 пикселей
Частота кадров видео	30 кадров в секунду	30 кадров в секунду	30 кадров в секунду	30 кадров в секунду
Битрейт видео	800 Кбит/с	2 Мбит/с	4 Мбит/с	10 Мбит/с

5.3. Декодирование видео

Реализации устройств Android должны поддерживать следующие профили декодирования видео VP8, VP9 и H.264. Реализации устройств также должны поддерживать динамическое переключение видео разрешения в том же потоке для кодеков VP8, VP9 и H.264.

	SD (низкое качество)	SD (высокое качество)	HD 720p (При поддержке аппаратного обеспечения)	HD 1080p (При поддержке аппаратного обеспечения)
Разрешение видео	320 х 180 пикселей	640 х 360 пикселей	1280 х 720 пикселей	1920 х 1080 пикселей
Частота кадров видео	30 кадров в секунду	30 кадров в секунду	30 кадров в секунду	30 кадров в секунду
Битрейт видео	800 Кбит/с	2 Мбит/с	8 Мбит/с	20 Мбит/с

5.4. Аудио запись

Когда приложение использовало API API android.media.AudioRecord для начала записи аудио -потока, реализации устройств, которые включают аппаратное обеспечение микрофона и объявлять android.hardware.microphone , должны попробовать и записывать звук с каждым из этих поведений:

Устройство должно демонстрировать приблизительно плоскую амплитуду в зависимости от частотных характеристик; В частности, ± 3 дБ, от 100 Гц до 4000 Гц
Чувствительность аудиовхода СЛЕДУЕТ устанавливать так, чтобы источник уровня звуковой мощности (SPL) 90 дБ при частоте 1000 Гц давал среднеквадратичное значение 2500 для 16-битных выборок.
Уровни амплитуды PCM ДОЛЖНЫ линейно отслеживать изменения входного уровня звукового давления в диапазоне как минимум 30 дБ от -18 дБ до +12 дБ при уровне звукового давления 90 дБ на микрофоне.
Общее гармоническое искажение должно составлять менее 1% для 1 кГц при 90 дБ входного уровня SPL.

В дополнение к указанным выше характеристикам записи, когда приложение начало запись аудиопотока с использованием источника звука android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION :

Обработка шумоподавления, если она присутствует, ДОЛЖНА быть отключена.
Автоматическое управление усилением, если она присутствует, должен быть отключен.

От Android 4.4, android.media.MediaRecorder.AudioSource Class имеет новый аудио -источник: REMOTE_SUBMIX . Устройства должны должным образом реализовать аудио -источник REMOTE_SUBMIX , чтобы, когда приложение использует API android.media.AudioRecord для записи из этого источника аудио, оно могло запечатлеть сочетание всех аудиотоков, за исключением следующего:

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

ПРИМЕЧАНИЕ. Несмотря на то, что некоторые из указанных выше требований, указанных выше как «должны», поскольку Android 4.3, определение совместимости для будущей версии планируется изменить их на «Должен». То есть эти требования являются необязательными в Android 4.4, но потребуются будущей версией. Существующие и новые устройства, которые запускают Android , очень настоятельно рекомендуются соответствовать этим требованиям , или они не смогут достичь совместимости Android при обновлении до будущей версии.

Если платформа поддерживает технологии подавления шума, настроенные на распознавание речи, эффект ДОЛЖЕН управляться с помощью API android.media.audiofx.NoiseSuppressor . Более того, поле «UUID» для дескриптора эффекта шума должен уникально идентифицировать каждую реализацию технологии подавления шума.

5.5. Задержка звука

Задержка звука — это временная задержка при прохождении аудиосигнала через систему. Многие классы приложений полагаются на короткие задержки для достижения звуковых эффектов в реальном времени.

Для целей этого раздела:

«Выходная задержка» определяется как интервал между тем, когда приложение записывает кадр данных, кодируемых PCM, и когда соответствующий звук может быть услышан внешним слушателем или наблюдается преобразователем
«Задержка холодного вывода» определяется как задержка выходной сигналы для первого кадра, когда система аудио выходной системы была простоя и включена до запроса
«Непрерывная задержка выходного вывода» определяется как задержка выходной сигналы для последующих кадров, после того, как устройство уже воспроизводит звук
«Задержка ввода»-это интервал между тем, когда внешний звук представлен на устройство, и когда приложение считывает соответствующую кадр данных, кодируемых PCM
«Задержка холодного ввода» определяется как сумма утерянного времени ввода и задержки ввода для первого кадра, когда аудио входная система была простоя и включена до запроса
«Непрерывная задержка ввода» определяется как задержка ввода для последующих кадров, в то время как устройство уже захватывает аудио
«OpenSl ES PCM-Queue API»-это набор связанных с PCM APIS в Android NDK; См. NDK_ROOT /docs/opensles/index.html

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

задержка холодного вывода 100 миллисекунд или меньше
непрерывная задержка вывода 45 миллисекунд или меньше

Если реализация устройства соответствует требованиям этого раздела после любой первоначальной калибровки при использовании API буферной очереди OpenSL ES PCM для непрерывной задержки вывода и задержки холодного вывода хотя бы через одно поддерживаемое устройство вывода звука, оно МОЖЕТ сообщать о поддержке звука с низкой задержкой. , сообщив о функции "Android.hardware.Audio.low-Latency" через класс android.content.pm.PackageManager . [ Ресурсы, 37 ] Наоборот, если реализация устройства не соответствует этим требованиям, она не должна сообщать о поддержке аудио с низкой задержкой.

В соответствии с разделом 7.2.5 аппаратное обеспечение микрофона может быть опущено реализациями устройств.

Реализации устройств, которые включают аппаратное обеспечение микрофона и объявить android.hardware.microphone должны соответствовать этим требованиям входной аудио -задержки:

задержка холодного ввода 100 миллисекунд или меньше
непрерывная задержка ввода 50 миллисекунд или менее

5.6. Сетевые протоколы

Устройства должны поддерживать протоколы медиа -сети для воспроизведения аудио и видео, как указано в документации Android SDK [ Resources, 58 ]. В частности, устройства ДОЛЖНЫ поддерживать следующие протоколы медиасетей:

РТСП (РТП, СДП)
HTTP(S) прогрессивная потоковая передача
HTTP (S) протокол потокового потока, версия 3 [ Ресурсы, 59 ]

6. Совместимость инструментов и опций разработчика

6.1. Инструменты разработчика

Реализации устройств ДОЛЖНЫ поддерживать инструменты разработчика Android, представленные в Android SDK. В частности, устройства, совместимые с Android, должны быть совместимы с:

Android Debug Bridge (известный как ADB) [ Resources, 33 ]
Реализации устройств должны поддерживать все функции adb , как задокументировано в Android SDK. Демон adb на стороне устройства должен быть неактивным по умолчанию, и должен быть доступный пользователь механизм, чтобы включить мост отладки Android.
Android включает поддержку безопасного adb. Secure adb включает adb на известных хостах, прошедших проверку подлинности. Реализации устройств ДОЛЖНЫ поддерживать безопасный adb.
Dalvik Debug Monitor Service (известный как DDMS) [ Resources, 33 ]
Реализации устройств ДОЛЖНЫ поддерживать все функции ddms , как описано в Android SDK. Поскольку ddms использует adb , поддержка ddms должна быть неактивной по умолчанию, но должна поддерживаться всякий раз, когда пользователь активирует мост отладки Android, как указано выше.
Обезьяна [ Ресурсы, 36 ]
Реализации устройств ДОЛЖНЫ включать в себя платформу Monkey и делать ее доступной для использования приложениями.
Systrace [ Resources, 33 ]
Реализации устройств ДОЛЖНЫ поддерживать инструмент systrace, как описано в Android SDK. Systrace по умолчанию должна быть неактивна, и ДОЛЖЕН быть доступный пользователю механизм для включения Systrace.

Большинство систем на базе Linux и систем Apple Macintosh распознают устройства Android с помощью стандартных инструментов Android SDK без дополнительной поддержки; однако системам Microsoft Windows обычно требуется драйвер для новых устройств Android. (Например, для новых идентификаторов поставщиков, а иногда и для новых идентификаторов устройств требуются специальные драйверы USB для систем Windows.) Если реализация устройства не распознается инструментом adb , как предусмотрено в стандартном Android SDK, разработчики устройств ДОЛЖНЫ предоставить драйверы Windows, позволяющие разработчикам подключаться к устройство использует протокол adb . Эти драйверы должны быть предоставлены для Windows XP, Windows Vista, Windows 7 и Windows 8, как в 32-битных, так и в 64-битных версиях.

6.2. Параметры разработчика

Android включает поддержку для разработчиков, позволяющую настраивать параметры, связанные с разработкой приложений. Реализации устройства должны соблюдать Android.Settings.application_development_settings, намерение показать настройки, связанные с разработкой приложений [ ресурсы, 77 ]. Реализация Android вверх по течению по умолчанию скрывает меню «Параметры разработчика» и позволяет пользователям запускать параметры разработчика после нажатия семи (7) раз на параметрах> о устройстве> Элемент меню номера сборки. Реализации устройств ДОЛЖНЫ обеспечивать единообразие возможностей разработчика. В частности, реализации устройств ДОЛЖНЫ скрывать параметры разработчика по умолчанию и ДОЛЖНЫ предоставлять механизм включения параметров разработчика, который соответствует исходной реализации Android.

6.2.1. Экспериментальный

Android 4.4 представляет Art, экспериментальное время выполнения Android, доступное в меню «Параметры разработчика» для предварительного просмотра. Реализации устройств должны включать ART (Libart.SO) и поддержку двойной загрузки от опций разработчика, но должны сохранить Dalvik (libdvm.so) в качестве времени выполнения по умолчанию.

7. Совместимость оборудования

Если устройство включает в себя определенный аппаратный компонент, который имеет соответствующий API для сторонних разработчиков, реализация устройства ДОЛЖНА реализовать этот API, как описано в документации Android SDK. Если API в SDK взаимодействует с аппаратным компонентом, который указан как необязательный, а реализация устройства не имеет этого компонента:

Полные определения класса (как задокументировано SDK) для API -интерфейсов компонента все еще должны присутствовать
Поведение API должно быть реализовано в какой-то разумной моде в каком-то разумном состоянии
Методы API должны возвращать нулевые значения, в которых разрешено документацией SDK
Методы API должны возвращать реализации классов NO-OP, где нулевые значения не допускаются документацией SDK
Методы API не должны бросать исключения, не задокументированные документацией SDK

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

Реализации устройства должны точно сообщать о точной информации о конфигурации аппаратной обеспечения с помощью методов getSystemAvailableFeatures() и hasSystemFeature(String) в классе android.content.pm.PackageManager . [ Ресурсы, 37 ]

7.1. Дисплей и графика

Android включает в себя средства, которые автоматически регулируют активы приложений и макеты пользовательского интерфейса для устройства, чтобы гарантировать, что сторонние приложения хорошо работают в различных аппаратных конфигурациях [ ресурсы, 38 ]. Устройства ДОЛЖНЫ правильно реализовать эти API и поведение, как подробно описано в этом разделе.

Единицы, на которые ссылаются требования в этом разделе, определяются следующим образом:

«Физический диагональный размер» - это расстояние в дюймах между двумя противоположными углами освещенной части дисплея.
«DPI» (то есть «точки на дюйм») - это количество пикселей, охватываемых линейным горизонтальным или вертикальным промежутком 1 ». Где значения DPI перечислены, как горизонтальный, так и вертикальный DPI должны попадать в диапазон.
«Соотношение сторон» - это отношение более длинного измерения экрана к более короткому измерению. Например, дисплей с разрешением 480x854 пикселей будет иметь соотношение 854/480 = 1,779, или примерно «16:9».
«Независимый от плотности пиксель» или («dp»)-это виртуальный пиксельный блок, нормализованный на экране 160 dpi, рассчитываемый как: pixels = dps * (density / 160) .

7.1.1. Конфигурация экрана

Размер экрана

Framework пользовательского интерфейса Android поддерживает множество различных размеров экрана и позволяет приложениям запросить размер экрана устройства (он же «макет экрана») через android.content.res.Configuration.screenLayout с SCREENLAYOUT_SIZE_MASK . Реализации устройств должны сообщать о правильном размере экрана, как определено в документации Android SDK [ ресурсы, 38 ], и определяется платформой Android Upstream. В частности, реализации устройств должны сообщать о правильном размере экрана в соответствии со следующими измерениями экрана пикселя, независимых от логической плотности (DP).

Устройства должны иметь размеры экрана не менее 426 DP x 320 DP ('Small')
Устройства, которые сообщают об размере экрана «Нормальный», должны иметь размеры экрана не менее 480 DP x 320 DP
Устройства, которые сообщают о размере экрана «большой», должны иметь размеры экрана не менее 640 DP x 480 DP
Устройства, которые сообщают о размере экрана «xlarge», должны иметь размеры экрана не менее 960 DP x 720 DP

Кроме того, устройства должны иметь размеры экрана не менее 2,5 дюймов в физическом диагональном размере.

Устройства НЕ ДОЛЖНЫ изменять заявленный размер экрана в любое время.

Приложения необязательно указывают, какие размеры экрана они поддерживают через атрибут <supports-screens> в файле AndroidManifest.xml. Реализации устройств ДОЛЖНЫ правильно учитывать заявленную поддержку приложений для маленьких, обычных, больших и больших экранов, как описано в документации Android SDK.

Соотношение сторон экрана

Соотношение сторон должно быть значением от 1,3333 (4: 3) до 1,86 (примерно 16: 9)

Плотность экрана

Платформа пользовательского интерфейса Android определяет набор стандартных логических плотностей, которые помогают разработчикам приложений нацеливать ресурсы приложения. Реализации устройств должны сообщать о одной из следующих логических плотностей Android Framework через API android.util.DisplayMetrics и должны выполнять приложения при этой стандартной плотности.

120 DPI, известный как «LDPI»
160 DPI, известный как «MDPI»
213 DPI, известный как «TVDPI»
240 DPI, известный как «HDPI»
320 DPI, известный как 'xhdpi'
400 DPI, известный как '400DPI'
480 DPI, известный как 'xxhdpi'
640 DPI, известный как 'xxxhdpi'

Реализации устройств ДОЛЖНЫ определять стандартную плотность платформы Android, которая численно наиболее близка к физической плотности экрана, если только эта логическая плотность не приводит к тому, что заявленный размер экрана становится ниже поддерживаемого минимума. Если стандартная плотность платформы Android, численно наиболее близкая к физической плотности, приводит к размеру экрана, меньшему, чем наименьший поддерживаемый совместимый размер экрана (ширина 320 пикселей), реализации устройства ДОЛЖНЫ сообщать следующую наименьшую стандартную плотность платформы Android.

7.1.2. Отображение показателей

Реализации устройства должны сообщать о правильных значениях для всех показателей отображения, определенных в android.util.DisplayMetrics [ Resources, 39 ].

7.1.3. Ориентация экрана

Устройства должны поддерживать динамическую ориентацию путем применения для портретной или ландшафтной ориентации экрана. То есть устройство должно учитывать запрос приложения на определенную ориентацию экрана. Реализации устройства МОГУТ выбирать книжную или альбомную ориентацию по умолчанию.

Устройства ДОЛЖНЫ сообщать правильное значение текущей ориентации устройства при каждом запросе через android.content.res.Configuration.orientation, android.view.Display.getOrientation() или другие API.

Устройства НЕ ДОЛЖНЫ изменять сообщаемый размер или плотность экрана при изменении ориентации.

Устройства должны сообщать, какие ориентации экрана они поддерживают ( android.hardware.screen.portrait и/или android.hardware.screen.landscape ) и должны сообщить по крайней мере одну поддерживаемую ориентацию. Например, устройство с экраном ландшафта с фиксированной ориентацией, таким как телевидение или ноутбук, должно сообщать только о android.hardware.screen.landscape .

7.1.4. Ускорение 2D и 3D графики

Реализации устройств ДОЛЖНЫ поддерживать OpenGL ES 1.0 и 2.0, как это описано и подробно описано в документации Android SDK. Реализации устройств должны поддерживать OpenGL ES 3.0 на устройствах, способных поддерживать OpenGL ES 3.0. Реализации устройств также должны поддерживать Android Renderscript, как подробно описано в документации Android SDK [ Resources, 8 ].

Реализации устройства также должны правильно идентифицировать себя как поддержку OpenGL ES 1.0, OpenGL ES 2.0 или OpenGL ES 3.0. То есть:

Управляемые API (например, метод GLES10.getString() ) должны сообщать о поддержке OpenGL ES 1.0 и OpenGL ES 2.0
Нативные API C/C ++ OpenGL (то есть те, которые доступны для приложений через libles_v1cm.so, libles_v2.so или libegl.so), должны сообщать о поддержке OpenGL ES 1.0 и OpenGL ES 2.0.
Реализации устройств, которые объявляют поддержку OpenGL ES 3.0, должны поддерживать управляемые API OpenGL ES 3.0 и включать поддержку нативных API C/C ++. На реализациях устройств, которые объявляют поддержку OpenGL ES 3.0, LibglesV2.SO должен экспортировать символы функции OpenGL ES 3.0 в дополнение к символам функции OpenGL ES 2.0.

Реализации устройства могут реализовать любые желаемые расширения OpenGL ES. Однако реализации устройств ДОЛЖНЫ сообщать через управляемые и собственные API OpenGL ES обо всех строках расширения, которые они поддерживают, и, наоборот, НЕ ДОЛЖНЫ сообщать о строках расширения, которые они не поддерживают.

Обратите внимание, что Android включает поддержку приложений, позволяющих дополнительно указать, что им требуются определенные форматы сжатия текстур OpenGL. Эти форматы обычно зависят от поставщика. Реализации устройств не требуют от Android реализации какого-либо конкретного формата сжатия текстур. Однако им СЛЕДУЕТ точно сообщать обо всех поддерживаемых ими форматах сжатия текстур с помощью метода getString() в API OpenGL.

Android включает в себя механизм для приложений, чтобы заявить, что они хотят включить аппаратное ускорение для 2D -графики в приложении, активности, окне или уровне просмотра путем использования манифестного тега android:hardwareAccelerated или Direct API вызовы [ Ресурсы, 9 ].

В Android 4.4 реализации устройств должны обеспечить аппаратное ускорение по умолчанию и должны отключить аппаратное ускорение, если разработчик, поэтому запрашивает, устанавливает android:hardwareAccelerated="false" или отключение аппаратного ускорения непосредственно через API Android View.

Кроме того, реализации устройств должны демонстрировать поведение в соответствии с документацией Android SDK об ускорении аппаратного обеспечения [ Resources, 9 ].

Android включает объект TextureView , который позволяет разработчикам напрямую интегрировать текстуры OpenGL ES с аппаратным ускорением в качестве целей рендеринга в иерархии пользовательского интерфейса. Реализации устройств ДОЛЖНЫ поддерживать API TextureView и ДОЛЖНЫ демонстрировать согласованное поведение с вышестоящей реализацией Android.

Android включает в себя поддержку EGL_ANDROID_RECORDABLE , атрибута EGLCONFIG, который указывает, поддерживает ли EGLCONFIG рендеринг AnativeWindow, который записывает изображения на видео. Реализации устройства должны поддерживать EGL_ANDROID_RECORDABLE расширение [ Resources, 79 ].

7.1.5. Режим совместимости устаревших приложений

Android определяет «режим совместимости», в котором структура работает в «нормальном» эквивалентном (шириной 320DP) в режиме «обычный» размер экрана, чтобы получить пользу от устаревших приложений, не разработанных для старых версий Android, которые предшествуют независимости размера экрана. Реализации устройств ДОЛЖНЫ включать поддержку режима совместимости устаревших приложений, реализованного в исходном открытом исходном коде Android. То есть реализации устройств НЕ ДОЛЖНЫ изменять триггеры или пороговые значения, при которых активируется режим совместимости, и НЕ ДОЛЖНЫ изменять поведение самого режима совместимости.

7.1.6. Типы экрана

Экраны реализации устройства классифицируются как один из двух типов:

Реализации дисплея с фиксированным пикселем: экран-это одна панель, которая поддерживает только одну ширину и высоту пикселя. Обычно экран физически интегрирован с устройством. Примеры включают мобильные телефоны, планшеты и так далее.
Реализации дисплея с переменным пикселем: реализация устройства либо не имеет встроенного экрана и включает в себя порт видеовывода, такой как VGA, HDMI или беспроводной порт для отображения, или имеет встроенный экран, который может изменить размеры пикселей. Примеры включают в себя телевизоры, серийные коробки и так далее.

Реализации устройств с фиксированным пикселем

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

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

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

Например, планшет с диагональным размером 7 дюймов с разрешением 1024x600 пикселей, считается большой реализацией дисплея MDPI с фиксированным пикселем. выполняются только в большом окне MDPI, независимо от того, используется ли используется дисплей с фиксированным пикселем или порт видео.

Реализации устройств с переменным пикселем

Реализации устройств с переменным пикселем должны поддерживать как минимум один из 1280x720, 1920x1080 или 3840x2160 (то есть 720p, 1080p или 4K). Реализации устройств с дисплей с переменным пикселем не должны поддерживать какую-либо другую конфигурацию экрана или режим. Реализации устройств с экранами с переменной пикселем могут изменить конфигурацию экрана или режим во время выполнения или времени загрузки. Например, пользователь подставной коробки может заменить дисплей 720p на дисплей 1080p, и реализация устройства может соответствующим образом скорректировать.

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

1280x720 (также известный как 720p): «Большой» размер экрана, плотность «TVDPI» (213 DPI)
1920x1080 (также известный как 1080p): «большой» размер экрана, «Xhdpi» (320 dpi).
3840x2160 (также известный как 4K): «Большой» размер экрана, «XXXHDPI» (640 DPI) Плотность

Для ясности реализации устройств с переменными размерами пикселей ограничены 720p, 1080p или 4K в Android 4.4 и должны быть настроены для сообщений о размере экрана и ведрах плотности, как отмечено выше.

7.1.7. Экранная технология

Платформа Android включает API, которые позволяют приложениям отображать насыщенную графику на дисплее. Устройства ДОЛЖНЫ поддерживать все эти API, как определено в Android SDK, если это специально не разрешено в этом документе. Конкретно:

Устройства ДОЛЖНЫ поддерживать дисплеи, способные отображать 16-битную цветную графику, и ДОЛЖНЫ поддерживать дисплеи, способные отображать 24-битную цветную графику.
Устройства ДОЛЖНЫ поддерживать дисплеи, способные отображать анимацию.
Используемая технология дисплея должна иметь соотношение сторон пикселя (PAR) между 0,9 и 1,1. То есть соотношение сторон пикселя должно быть почти квадрат (1,0) с допуском 10%.

7.1.8. Внешние дисплеи

Android включает поддержку дополнительного дисплея для обеспечения возможности совместного использования мультимедиа и API-интерфейсы разработчика для доступа к внешним дисплеям. Если устройство поддерживает внешний дисплей либо через проводное, беспроводное или встроенное дополнительное соединение дисплея, то реализация устройства должна реализовать API Display Manager, как описано в документации Android SDK [ Resources, 75 ]. Реализации устройств, которые поддерживают безопасный видео вывод и способны поддерживать безопасные поверхности, должны объявить поддержку Display.FLAG_SECURE . В частности, реализации устройств, которые объявляют поддержку Display.FLAG_SECURE , должны поддерживать HDCP 2.x или выше для беспроводных дисплеев Miracast или HDCP 1.2 или выше для проводных дисплеев. Первоначальная реализация Android с открытым исходным кодом включает поддержку беспроводных (Miracast) и проводных (HDMI) дисплеев, что удовлетворяет этому требованию.

7.2. Устройства ввода

7.2.1. Клавиатура

Реализации устройства:

Должен включать поддержку платформы управления вводами (которая позволяет сторонним разработчикам создавать двигатели управления вводами - т.е. мягкая клавиатура), как подробно описано по адресу http://developer.android.com
Должен предоставить хотя бы одну реализацию мягкой клавиатуры (независимо от того, присутствует ли жесткая клавиатура)
МОЖЕТ включать дополнительные реализации программной клавиатуры.
МОЖЕТ включать аппаратную клавиатуру
Не должен включать аппаратную клавиатуру, которая не соответствует одному из форматов, указанных в android.content.res.Configuration.keyboard [ Resources, 40 ] (то есть Qwerty или 12-ключ)

7.2.2. Бесконтактная навигация

Реализации устройства:

Может опустить вариант навигации, не связанного с облечением (то есть может опустить трекбол, D-PAD или колесо)
Должен сообщить о правильном значении для android.content.res.Configuration.navigation [ ресурсы, 40 ]
ДОЛЖЕН предоставлять разумный альтернативный механизм пользовательского интерфейса для выбора и редактирования текста, совместимый с механизмами управления вводом. Вышестоящая реализация Android с открытым исходным кодом включает механизм выбора, подходящий для использования с устройствами, в которых отсутствуют сенсорные навигационные средства.

7.2.3. Навигационные ключи

Дом, рецензионные и обратные функции необходимы для парадигмы навигации Android. Реализации устройств должны всегда предоставлять эти функции пользователю всегда при запуске приложений. Эти функции МОГУТ быть реализованы с помощью специальных физических кнопок (например, механических или емкостных сенсорных кнопок) или МОГУТ быть реализованы с помощью специальных программных клавиш на отдельной части экрана, жестов, сенсорной панели и т. д. Android поддерживает обе реализации. Все эти функции ДОЛЖНЫ быть доступны одним действием (например, касанием, двойным щелчком или жестом), когда они видны.

Функции Back and Recests должны иметь видимую кнопку или значок, если только скрыто вместе с другими функциями навигации в полноэкранном режиме. Домашняя функция должна иметь видимую кнопку или значок, если только скрыто вместе с другими навигационными функциями в полноэкранном режиме.

Функция меню устарела в пользу панели действий с версии Android 4.0. Реализации устройства не должны реализовать выделенную физическую кнопку для функции меню. Если кнопка «Физическое меню» реализована и устройство запускает приложения с targetSdkVersion > 10, реализация устройства:

Для запуска устройства с Android 4.4 должно отображать кнопку переполнения действий на панели действий, когда виденная панель действий, и полученное меню переполнения действия Popu Popu не пусто.
Для существующего устройства, запускаемого с более ранней версией, но обновлением до Android 4.4, должно отображать кнопку переполнения действий на панели действий, когда виденная панель действий, и всплывающее окно переполнения, полученное в результате действия, не пусто.
Не должен изменять положение всплывающего окна переполнения действия, отображаемого путем выбора кнопки переполнения в панели действий.
Может представить всплывающее окно действию в измененной позиции на экране, когда оно отображается, выбрав кнопку «Физическое меню».

Для обратной совместимости реализации устройств должны предоставить функцию меню для приложений, когда targetSdkVersion <= 10, либо с помощью физической кнопки, программного ключа или жестов. Эта функция меню должна присутствовать, если она не скрыта вместе с другими функциями навигации.

Android поддерживает Assist Action [ Resources, 63 ]. Реализации устройств должны всегда предоставлять действие помощи пользователю при запуске приложений. Действие «Помощь» СЛЕДУЕТ реализовать в виде длительного нажатия кнопки «Домой» или жеста смахивания вверх по программной клавише «Домой». Эта функция может быть реализована через другую физическую кнопку, программную клавишу или жесты, но должна быть доступна с одним действием (например, нажатие, дважды щелкните или жест), когда видны другие навигационные клавиши.

Реализации устройства МОГУТ использовать отдельную часть экрана для отображения клавиш навигации, но в этом случае ДОЛЖНЫ соответствовать следующим требованиям:

Навигационные клавиши реализации устройства ДОЛЖНЫ использовать отдельную часть экрана, недоступную приложениям, и НЕ ДОЛЖНЫ закрывать или иным образом мешать части экрана, доступной приложениям.
Реализации устройства должны предоставить часть дисплея для приложений, которые соответствуют требованиям, определенным в разделе 7.1.1 .
Реализации устройства должны отображать навигационные клавиши, когда приложения не указывают системный режим пользовательского интерфейса, или указывать SYSTEM_UI_FLAG_VISIBLE .
Реализации устройства должны представить навигационные клавиши в ненавязчивом режиме «Низкий профиль» (например, Dimmed), когда приложения указывают SYSTEM_UI_FLAG_LOW_PROFILE .
Реализации устройства должны скрывать навигационные клавиши, когда приложения указывают SYSTEM_UI_FLAG_HIDE_NAVIGATION .

7.2.4. Сенсорный ввод

Реализации устройств должны иметь какую-то систему ввода указателя (либо мыши, либо прикосновение). Однако, если реализация устройства не поддерживает систему ввода с указателем, оно НЕ ДОЛЖНО сообщать константу функции android.hardware.touchscreen или android.hardware.faketouch . Реализации устройств, которые включают систему ввода указателя:

СЛЕДУЕТ поддерживать полностью независимо отслеживаемые указатели, если система ввода устройства поддерживает несколько указателей.
Должен сообщить о значении android.content.res.Configuration.touchscreen [ Resources, 40 ], соответствующего типу конкретного сенсорного экрана на устройстве

Android включает в себя поддержку различных сенсорных экранов, сенсорных прокладков и поддельных устройств ввода сенсорных вводов. Реализации устройств на основе сенсорного экрана связаны с дисплеем [ ресурсов, 81 ], так что пользователь имеет впечатление непосредственно манипулирования элементами на экране. Поскольку пользователь непосредственно касается экрана, системе не требуются какие-либо дополнительные возможности для указания объектов, которыми манипулируют. Напротив, ложный сенсорный интерфейс предоставляет систему пользовательского ввода, которая приближается к подмножеству возможностей сенсорного экрана. Например, мышь или пульт дистанционного управления, который управляет курсором на экране, аналогичен прикосновению, но требует, чтобы пользователь сначала навел курсор или сфокусировался, а затем щелкнул мышью. Многочисленные устройства ввода, такие как мышь, трекпад, аэромышь с гироскопом, гироскопическая указка, джойстик и мультитач-трекпад, могут поддерживать ложное сенсорное взаимодействие. Android 4.0 включает в себя константу функции android.hardware.faketouch , которая соответствует высокотехнологичному неканатному (то есть на основе указателей) устройства ввода, такого как мышь или трекпад, которое может адекватно подражать вводу на основе сенсорного. Поддержка) и указывает, что устройство поддерживает эмулированное подмножество функциональности сенсорного экрана. Реализации устройств, которые объявляют функцию фальшивого прикосновения, должны соответствовать требованиям Fake Touch в разделе 7.2.5 .

Реализации устройства ДОЛЖНЫ сообщать правильную функцию, соответствующую типу используемого входа. Реализации устройств, которые включают в себя сенсорный экран (одноразовый или лучше), должны сообщать о постоянной функции платформы android.hardware.touchscreen . Реализации устройств, которые сообщают о платформе Constant android.hardware.touchscreen , также должны сообщать о постоянной платформе android.hardware.faketouch . Реализации устройств, которые не включают сенсорный экран (и полагаются только на указательное устройство), не должны сообщать о какой -либо функции сенсорного экрана и должны сообщать только о android.hardware.faketouch , если они соответствуют требованиям поддельного сенсорного прикосновения в разделе 7.2.5 .

7.2.5. Поддельный сенсорный ввод

Реализации устройств, которые объявляют поддержку android.hardware.faketouch

Должен сообщить о позициях экрана Absolute X и Y в расположении указателя и отобразите визуальный указатель на экране [ ресурсы, 80 ]
Должен сообщить о событии Touch с кодом действия [ ресурсы, 80 ], которое указывает изменение состояния, которое происходит на указателе, down up на экране [ ресурсы, 80 ]
ДОЛЖЕН поддерживать указатель down и up на объекте на экране, что позволяет пользователям имитировать нажатие на объект на экране.
Необходимо поддерживать указатель down , указатель up , up down затем указатель в то же место на объекте на экране в течение времени, который позволяет пользователям эмулировать двойной нажатие на объект на экране [ Ресурсы, 80 ]
Необходимо поддерживать указатель down по произвольной точке на экране, указатель перемещается в любую другую произвольную точку на экране, а затем указатель up , что позволяет пользователям эмулировать перетаскивание прикосновения
ДОЛЖЕН поддерживать указатель down , чтобы пользователи могли быстро перемещать объект в другое положение на экране, а затем указатель up на экране, что позволяет пользователям бросать объект на экран.

Устройства, которые заявляют о поддержке android.hardware.faketouch.multitouch.distinct , ДОЛЖНЫ соответствовать вышеуказанным требованиям для faketouch, а также ДОЛЖНЫ также поддерживать отдельное отслеживание двух или более независимых входных указателей.

7.2.6. Микрофон

Реализации устройства могут опустить микрофон. Однако, если реализация устройства пропускает микрофон, он не должен сообщать о константе функции android.hardware.microphone и должен реализовать API аудиозаписи как NO-OPS, согласно разделу 7 . И наоборот, реализации устройств, которые обладают микрофоном:

Должен сообщить о константе функции android.hardware.microphone
Следует удовлетворить требования к качеству звука в разделе 5.4
Следует удовлетворить требования к задержке аудио в разделе 5.5

7.3. Датчики

Android включает API для доступа к различным типам датчиков. Реализации устройств обычно МОГУТ не включать эти датчики, как это предусмотрено в следующих подразделах. Если устройство включает в себя конкретный тип датчика, который имеет соответствующий API для сторонних разработчиков, реализация устройства должна реализовать тот API, как описано в документации Android SDK. Например, реализации устройства:

Должен точно сообщить о наличии или отсутствии датчиков на класс android.content.pm.PackageManager . [ Ресурсы, 37 ]
ДОЛЖЕН вернуть точный список поддерживаемых датчиков через SensorManager.getSensorList() и аналогичные методы.
ДОЛЖЕН вести себя разумно для всех других API датчиков (например, возвращая true или false в зависимости от ситуации, когда приложения пытаются зарегистрировать прослушиватели, не вызывая прослушиватели датчиков, когда соответствующие датчики отсутствуют и т. д.)
Должен сообщить о всех измерениях датчиков, используя соответствующую международную систему значений единиц (IE метрики) для каждого типа датчика, как определено в документации Android SDK [ ресурсы, 41 ]

Приведенный выше список не является исчерпывающим; Задокументированное поведение Android SDK должно считаться авторитетным.

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

Android включает в себя понятие «потокового» датчика, который непрерывно возвращает данные, а не только при изменении данных. Реализации устройства должны непрерывно предоставлять периодические образцы данных для любого API, указанного в документации Android SDK, как датчик потоковой передачи. Обратите внимание, что реализации устройства должны гарантировать, что потоковой датчики не должен предотвратить въезд процессора устройства в состояние приостановки или просыпаться из подвесного состояния.

7.3.1. Акселерометр

Реализации устройства ДОЛЖНЫ включать 3-осевой акселерометр. Если реализация устройства включает 3-осевой акселерометр, оно:

Должен иметь возможность провести мероприятия на 120 Гц или более. Обратите внимание, что, хотя приведенная выше частота акселерометра указана как «должна» для Android 4.4, определение совместимости для будущей версии планируется изменить их на «Должен». То есть эти стандарты являются необязательными в Android, но потребуются в будущих версиях. Существующие и новые устройства, которые запускают Android
Необходимо соответствовать системе координат датчика Android, как подробно описано в API API Android (см. [ Resources, 41 ])
Должен быть способен измерять от свободного падения до дважды тяжести (2 г) или более на любом трехмерном векторе
Должен иметь 8-битный точность или больше
Должен иметь стандартное отклонение не больше 0,05 м/с^2

7.3.2. Магнитометр

Реализации устройства должны включать 3-осевой магнитометр (т.е. Compass.) Если устройство действительно включает в себя 3-осевой магнитометр, оно:

Должен быть в состоянии проводить мероприятия при 10 Гц или более
Должен соблюдать систему координат датчика Android, как подробно описано в API API Android (см. [ Ресурсы, 41 ]).
Должен быть способен выборки целого ряда прочности поля, адекватных для покрытия геомагнитного поля
Должен иметь 8-битный точность или больше
Должен иметь стандартное отклонение не более 0,5 мкт

7.3.3. GPS

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

7.3.4. Гироскоп

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

Должен быть компенсирован температурой.
Должен быть способен измерять изменения ориентации до 5,5*Радианов PI/секунду (то есть приблизительно 1000 градусов в секунду).
Должен иметь возможность провести мероприятия на 200 Гц или более. Обратите внимание, что хотя приведенная выше частота гироскопа указана как «должна» для Android 4.4, определение совместимости для будущей версии планируется изменить их на «Должен». То есть эти стандарты являются необязательными в Android, но потребуются в будущих версиях. Существующие и новые устройства, которые запускают Android , очень настоятельно рекомендуются соответствовать этим требованиям , чтобы они могли перейти на будущие выпуски платформы.
Должен иметь 12-битный точность или больше
Должен иметь дисперсию не больше 1E-7 Rad^2 / S^2 на Гц (дисперсия на Гц или рад^2 / с). Разница может варьироваться в зависимости от скорости отбора проб, но должна быть ограничена этим значением. Другими словами, если вы измеряете дисперсию гироскопа при скорости отбора проб 1 Гц, это должно быть не больше 1e-7 Rad^2/s^2.
Должен иметь временные метки как можно ближе, когда аппаратное событие произошло, насколько это возможно. Постоянная задержка должна быть удалена.

7.3.5. Барометр

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

Должен быть в состоянии проводить мероприятия при 5 Гц или более
Должен иметь достаточную точность, чтобы обеспечить оценку высоты
Должен быть компенсирован температурой

7.3.6. Термометр

Реализации устройства могут включать экологический термометр (т.е. датчик температуры). Если присутствует, он должен быть определен как SENSOR_TYPE_AMBIENT_TEMPERATURE , и он должен измерить температуру окружающей среды (комната) в градусах по Цельсию.

Реализации устройства могут, но не должны включать датчик температуры процессора. Если присутствует, он должен быть определен как SENSOR_TYPE_TEMPERATURE , он должен измерить температуру процессора устройства, и он не должен измерять какую -либо другую температуру. Обратите внимание, что тип датчика SENSOR_TYPE_TEMPERATURE был устарел в Android 4.0.

7.3.7. Фотометр

Реализации устройства могут включать фотометр (т.е. датчик окружающей среды.)

7.3.8. Датчик приближения

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

7.4. Возможность подключения к данным

7.4.1. Телефония

«Телефония», используемая API API Android, и этот документ относится специально для оборудования, связанного с размещением голосовых вызовов и отправкой SMS -сообщений через сеть GSM или CDMA. Несмотря на то, что эти голосовые вызовы могут или не могут быть переключены на пакетах, они предназначены для целей Android, которые считаются независимыми от любого подключения данных, которые могут быть реализованы с использованием той же сети. Другими словами, функциональность и API -интерфейсы Android «Телефония» относятся специально для голосовых вызовов и SMS; Например, реализации устройств, которые не могут размещать вызовы или отправлять/получать SMS-сообщения, не должны сообщать о функции «Android.hardware.telephony» или любые суб-функции, независимо от того, используют ли они сотовую сеть для подключения данных.

Android может использоваться на устройствах, которые не включают аппаратное обеспечение телефона. То есть Android совместим с устройствами, которые не являются телефонами. Однако, если внедрение устройства включает в себя GSM или CDMA The Dephony, она должна реализовать полную поддержку API для этой технологии. Реализации устройств, которые не включают аппаратное обеспечение телефона, должны реализовать полные API в качестве OPS.

7.4.2. IEEE 802.11 (Wi-Fi)

Реализации устройств Android должны включать поддержку одной или нескольких форм 802.11 (b/g/a/n и т. Д.) Если реализация устройства включает в себя поддержку 802.11, она должна реализовать соответствующий API Android.

Реализации устройств должны реализовать многоадресный API, как описано в документации SDK [ Resources, 62 ]. Реализации устройств, которые включают поддержку Wi-Fi, должны поддерживать многоадресную DNS (MDN). Реализации устройства не должны фильтровать пакеты MDNS (224.0.0.251) в любое время работы, включая, когда экран не находится в активном состоянии.

7.4.2.1. Wi-Fi прямой

Реализации устройств должны включать поддержку Wi-Fi Direct (Wi-Fi-одноранговый). Если реализация устройства включает в себя поддержку Wi-Fi Direct, оно должно реализовать соответствующий API Android, как описано в документации SDK [ Resources, 68 ]. Если реализация устройства включает в себя поддержку Wi-Fi Direct, то это:

Должен поддерживать обычную операцию Wi-Fi
Следует поддержать одновременную прямую операцию Wi-Fi и Wi-Fi

7.4.2.2. Настройка туннелированного прямого соединения Wi-Fi

Реализации устройства должны включать поддержку настройки прямого канала Wi-Fi-прямой ссылки (TDLS), как описано в документации Android SDK [ Resources, 85 ]. Если реализация устройства включает поддержку TDLS и TDLS включена API Wifimanager, устройство:

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

7.4.3. Bluetooth

Реализации устройства должны включать приемопередатчик Bluetooth. Реализации устройств, которые включают в себя приемопередатчик Bluetooth, должны включать API Bluetooth на основе RFCOMM, как описано в документации SDK, и объявить аппаратную функцию Android.hardware.bluetooth [ ресурсы, 42 ]. Реализации устройств должны реализовать соответствующие профили Bluetooth, такие как A2DP, AVRCP, OBEX и т. Д. В зависимости от устройства.

Device implementations that do include support for Bluetooth GATT (generic attribute profile) to enable communication with Bluetooth Smart or Smart Ready devices MUST enable the GATT-based Bluetooth API as described in the SDK documentation and declare hardware feature android.hardware.bluetooth_le [ Resources, 42 ].

7.4.4. Ближнеполевая связь

Реализации устройств должны включать приемопередатчик и связанное с ним аппаратное обеспечение для связи с ближним полем (NFC). If a device implementation does include NFC hardware, then it:

MUST report the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method. [ Resources, 37 ]
Должен быть способен читать и писать сообщения NDEF через следующие стандарты NFC:
- Должен быть способен выступать в качестве читателя/писателя Forum Forum NFC (как определено технической спецификацией NFC Forum NFCFORUM-TS-DigitalProtocol-1.0) через следующие стандарты NFC:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - Isodep (ISO 14443-4)
  - Типы тегов форума NFC 1, 2, 3, 4 (определено форумом NFC)
Должен быть способен читать и писать сообщения NDEF через следующие стандарты NFC. Note that while the NFC standards below are stated as "SHOULD", the Compatibility Definition for a future version is planned to change these to "MUST". That is, these standards are optional in this version but will be required in future versions. Существующие и новые устройства, которые запускают эту версию Android , очень настоятельно рекомендуются удовлетворить эти требования , чтобы они могли обновить до будущих выпусков платформы.
- NFCV (ISO 15693)
Должен быть способен передавать и получать данные с помощью следующих одноранговых стандартов и протоколов:
- ISO 18092
- LLCP 1.0 (определяется форумом NFC)
- SDP 1.0 (определяется форумом NFC)
- NDEF Push Protocol [ Resources, 43 ]
- Snep 1.0 (определяется форумом NFC)
MUST include support for Android Beam [ Resources, 65 ]:
- Должен реализовать сервер SNEP по умолчанию. Допустимые сообщения NDEF, полученные на сервере SNEP по умолчанию, должны быть направлены на приложения с использованием намерения Android.nfc.Action_ndef_discovered. Отключение луча Android в настройках не должна отключить отправку входящего сообщения NDEF.
- Device implementations MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 67 ].
- Должен реализовать сервер АЭС. Сообщения, полученные сервером NPP, должны обрабатываться так же, как сервер SNEP по умолчанию.
- Необходимо реализовать клиент SNEP и попытаться отправить исходящий P2P NDEF на сервер SNEP по умолчанию при включении BEAM Android. Если SNEP -сервер по умолчанию не найден, клиент должен попытаться отправить на сервер АЭС.
- MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
- SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages.
- SHOULD enable Android Beam by default
- Необходимо поддерживать передачу соединения NFC в Bluetooth, когда устройство поддерживает профиль нажатия объекта Bluetooth. Device implementations must support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the "Connection Handover version 1.2" [ Resources, 60 ] and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [ Resources, 61 ] specs from Форум NFC. Такая реализация должна реализовать службу Handover LLCP с именем службы «Урн: NFC: SN: Handover» для обмена запросом на передачу/выбора записей по NFC, и она должна использовать профиль нажатия объекта Bluetooth для фактической передачи данных Bluetooth. По установлению причинам (чтобы оставаться совместимыми с устройствами Android 4.1), реализация все равно должна принять запросы Snep Get для обмена запросом на передачу/выбора записей над NFC. Однако сама реализация не должна отправлять Snep Get запросы на выполнение обработки соединения.
MUST poll for all supported technologies while in NFC discovery mode.
SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked.

(Обратите внимание, что общедоступные ссылки недоступны для спецификаций JIS, ISO и NFC, упомянутых выше.)

Android 4.4 introduces support for NFC Host Card Emulation (HCE) mode. Если реализация устройства включает в себя контроллер NFC, способный к маршрутизации HCE и идентификатора приложения (помощь), то это:

Должен сообщить о константу функции android.hardware.nfc.hce
MUST support NFC HCE APIs as defined in the Android SDK [ Resources, 90 ]

Кроме того, реализации устройств могут включать поддержку чтения/писателя для следующих технологий MIFARE.

MIFARE Classic (NXP MF1S503x [ Resources, 44 ], MF1S703x [ Resources, 45 ])
MIFARE Ultralight (NXP MF0ICU1 [ Resources, 46 ], MF0ICU2 [ Resources, 47 ])
NDEF on MIFARE Classic (NXP AN130511 [ Resources, 48 ], AN130411 [ Resources, 49 ])

Обратите внимание, что Android включает API для этих типов MIFARE. Если реализация устройства поддерживает MIFARE в роли читателя/писателя, это:

Должен реализовать соответствующие API Android, как задокументировано Android SDK
MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. [ Resources, 37 ] Note that this is not a standard Android feature, and as such does not appear as a constant on the PackageManager class.
Не должен реализовать соответствующие API API Android и сообщать о функции com.nxp.mifare, если это также не реализует общую поддержку NFC, как описано в этом разделе

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 37 ], and MUST implement the Android NFC API as a no-op.

Поскольку классы android.nfc.NdefMessage и android.nfc.NdefRecord представляют собой независимый от протокола формат представления данных, реализации устройств должны реализовать эти API, даже если они не включают поддержку NFC или объявляют функцию Android.hardware.nfc.

7.4.5. Минимальные возможности сети

Реализации устройства должны включать поддержку одной или нескольких форм сети данных. В частности, реализации устройств должны включать поддержку хотя бы одного стандарта данных, способного составлять 200 кбит/с или более. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

Реализации устройств, где стандарт физической сети (например, Ethernet) является основным соединением для передачи данных, также должна включать поддержку, по крайней мере, один общий стандарт беспроводной передачи данных, такой как 802.11 (Wi-Fi).

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

7.4.6. Синхронизировать настройки

Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns "true" [ Resources, 88 ].

7.5. Камеры

Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. Задняя камера-это камера, расположенная на боковой стороне устройства напротив дисплея; То есть он изображает сцены на дальней стороне устройства, как традиционная камера. Фронтальная камера-это камера, расположенная на той же стороне устройства, что и дисплей; То есть камера обычно используется для изображения пользователя, например, для видеоконференций и аналогичных приложений.

7.5.1. Задняя камера

Реализации устройства должны включать камеру, обращенную к задней части. If a device implementation includes a rear-facing camera, it:

Должен иметь разрешение не менее 2 мегапикселей
SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
Может иметь аппаратное обеспечение с фиксированным фокусом или эдофом (расширенная глубина полета)
Может включать вспышку. Если камера включает в себя вспышку, флэш -лампа не должна быть зажжена, в то время как на поверхности предварительного просмотра камеры android.hardware.camera.previewCallback на поверхности предварительного просмотра камеры, если приложение явно не включило FLASH_MODE_AUTO FLASH_MODE_ON Camera.Parameters Object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

7.5.2. Фронтальная камера

Реализации устройства могут включать фронтальную камеру. If a device implementation includes a front-facing camera, it:

MUST have a resolution of at least VGA (that is, 640x480 pixels)
Не должен использовать фронтальную камеру в качестве по умолчанию для API камеры. That is, the camera API in Android has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the устройство.
MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
Должен горизонтально отражать (т.е. зеркало) поток, отображаемый приложением в камере, следующим образом:

Если реализация устройства способна поворачиваться пользователем (например, автоматически через акселерометр или вручную через пользовательский ввод), предварительный просмотр камеры должен быть зеркальным горизонтально относительно текущей ориентации устройства.
If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 50 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
В противном случае предварительный просмотр должен быть зеркал вдоль горизонтальной оси устройства по умолчанию.

Необходимо отражать изображение, отображаемое пост -просмотром так же, как и потоки изображения предварительного просмотра камеры. (If the device implementation does not support postview, this requirement obviously does not apply.)
Не должен отражать окончательные захваченные неподвижные изображения или видеопотоки, возвращаемые к обратным вызовам приложений или привержены хранилищу СМИ

7.5.3. Поведение API камеры

Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int) , then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
Если приложение регистрирует экземпляр android.hardware.Camera.PreviewCallback , и система вызывает метод onPreviewFrame() , когда формат предварительного просмотра является YCBCR_420_SP, данные в byte[] , передаваемые в onPreviewFrame() , должны быть в формате Encoding NV21. То есть NV21 должен быть по умолчанию.
Device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (Аппаратный видеокодер и камера может использовать любой собственный формат пикселей, но реализация устройства должна поддерживать преобразование в YV12.)

Device implementations MUST implement the full Camera API included in the Android SDK documentation [ Resources, 51 ]), regardless of whether the device includes hardware autofocus or other capabilities. Например, камеры, в которых не хватает автофокуса, все равно должны вызывать любые зарегистрированные экземпляры android.hardware.Camera.AutoFocusCallback (даже если это не имеет отношения к неавтофокусной камере.) Обратите внимание, что это относится к фронтальным камерам; Например, даже если большинство фронтальных камер не поддерживают автофокус, обратные вызовы API все еще должны быть «фальшивыми», как описано.

Реализации устройств должны распознавать и чтить каждое имя параметра, определенное как постоянное в классе android.hardware.Camera.Parameters , если базовое оборудование поддерживает эту функцию. Если аппаратное обеспечение устройства не поддерживает функцию, API должен вести себя как задокументированное. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . То есть реализации устройств должны поддерживать все стандартные параметры камеры, если оборудование позволяет, и не должно поддерживать пользовательские типы параметров камеры. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Реализации устройств должны транслировать намерение Camera.ACTION_NEW_PICTURE всякий раз, когда камера сделана новая картина, а запись изображения была добавлена в медиа -магазин.

Реализации устройств должны транслировать намерение Camera.ACTION_NEW_VIDEO всякий раз, когда камера записана новое видео, а запись изображения была добавлена в медиа -магазин.

7.5.4. Ориентация камеры

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

7.6. Память и хранение

7.6.1. Минимальная память и хранилище

Device implementations MUST have at least 340MB of memory available to the kernel and userspace. The 340MB MUST be in addition to any memory dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations with less than 512MB of memory available to the kernel and userspace MUST return the value "true" for ActivityManager.isLowRamDevice() .

Device implementations MUST have at least 1GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 1GB. Device implementations that run Android are very strongly encouraged to have at least 2GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. Реализация устройства менеджера загрузки должна быть способна загружать отдельные файлы не менее 100 МБ в размере в местоположение «кэш» по умолчанию.

7.6.2. Shared External Storage

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

Реализации устройства должны быть настроены с помощью общего хранилища, установленного по умолчанию, «из коробки». If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Реализации устройства должны обеспечивать соблюдение в соответствии с документами android.permission.WRITE_EXTERNAL_STORAGE разрешение на это общее хранилище. В противном случае общее хранилище должно быть подлежит записи любым приложением, которое получает это разрешение.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps. The upstream Android Open Source Project includes an implementation that uses internal device storage for shared external storage APIs; Реализации устройств должны использовать эту конфигурацию и реализацию программного обеспечения.

Независимо от формы используемого хранилища, реализации устройств должны предоставить некоторый механизм для доступа к содержимому общему хранилищу с хост -компьютера, такого как USB -хранилище (UMS) или протокол передачи среды (MTP). Реализации устройств могут использовать USB Mass Storage, но должны использовать протокол передачи носителя. If the device implementation supports Media Transfer Protocol:

The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
The device implementation SHOULD report a USB device class of 0x00 .
The device implementation SHOULD report a USB interface name of 'MTP'.

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

It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST NOT allow Android applications to write to the secondary external storage, except for their package-specific directories on the secondary external storage, but SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

7.7. USB

Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

If a device implementation includes a USB client port:

the port MUST be connectable to a USB host with a standard USB-A port
the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android are very strongly encouraged to meet these requirements in Android so they will be able to upgrade to the future platform releases
the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Androidare very strongly encouraged to meet these requirements in Android so they will be able to upgrade to future platform releases.
if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android are very strongly encouraged to meet these requirements so they will be able to upgrade to the future platform releases
Значение IserialNumber в дескрипторе стандартного устройства USB должно быть равным значению Android.os.build.serial.

If a device implementation includes a USB host port:

it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. Совместимость производительности

Device implementations MUST meet the key performance metrics of an Android- compatible device defined in the table below:

Метрика	Performance Threshold	Комментарии
Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms Contacts: less than 700ms Settings: less than 700ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

9. Совместимость моделей безопасности

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. Реализации устройства должны поддерживать установку самоподнегиваемых приложений, не требуя никаких дополнительных разрешений/сертификатов от любых третьих лиц/органов власти. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

9.1. Разрешения

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. В частности, реализации должны обеспечивать каждое разрешение, определенное, как описано в документации SDK; Никакие разрешения не могут быть пропущены, изменены или игнорированы. Реализации могут добавлять дополнительные разрешения, при условии, что новые строки идентификатора разрешения не находятся в Android.* Пространство имен.

9.2. UID и изоляция процессов

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

9.3. Разрешения файловой системы

Device implementations MUST support the Android file access permissions model as defined in the Security and Permissions reference [ Resources, 54 ].

9.4. Альтернативные среды выполнения

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. Однако такие альтернативные среды выполнения не должны ставить под угрозу модель безопасности Android или безопасность установленных приложений Android, как описано в этом разделе.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

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

Альтернативные время выполнения должны соблюдать модель Android Sandbox. Конкретно:

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

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

При установке приложений альтернативное время выполнения должно получить согласие пользователя на разрешения Android, используемые приложением. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . Если среда выполнения не записывает возможности приложений таким образом, среда выполнения должна перечислить все разрешения, удерживаемые самой средой выполнения при установке любого приложения, используя это время выполнения.

9.5. Многопользовательская поддержка

Android includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support [ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]
Android includes support for restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments. Device implementations that include support for multiple users MUST include support for restricted profiles. The upstream Android Open Source Project includes an implementation that satisfies this requirement.

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage.

9.6. Премиальное SMS-предупреждение

Android includes support for warning users for any outgoing premium SMS message [ Resources, 73 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7. Функции безопасности ядра

The Android Sandbox includes features that can use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features, if implemented below the Android framework:

MUST maintain compatibility with existing applications
MUST not have a visible user interface, even when violations are detected
SHOULD NOT be user or developer configurable

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

it MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis with:

domains that are in enforcing mode in the upstream Android Open Source implementation (such as installd, netd, and vold) MUST be in enforcing mode
domain(s) for third-party applications SHOULD remain in permissive mode to ensure continued compatibility

it SHOULD load policy from /sepolicy file on the device
it MUST support dynamic updates of the SELinux policy file without requiring a system image update
it MUST log any policy violations without breaking applications or affecting system behavior

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. Device implementations MUST be compatible with the upstream Android Open Source Project.

9.8. Конфиденциальность

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

9.9. Полнодисковое шифрование

IF the device has lockscreen, the device MUST support full-disk encryption.

10. Тестирование совместимости программного обеспечения

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Набор тестов совместимости

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.4. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

10.2. CTS-верификатор

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. Reference Applications

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Google Play Store)

Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

11. Обновляемое программное обеспечение

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

12. Журнал изменений документа

The following table contains a summary of the changes to the Compatibility Definition in this release.

Section(s)	Summary of change
3.2.2. Параметры сборки	Revised descriptions of BRAND, DEVICE, and PRODUCT. SERIAL is now required.
3.2.3.5. Настройки приложения по умолчанию	New section that adds requirement to comply with new default application settings
3.3.1 Бинарные интерфейсы приложений	Clarified allowed values for the `android.os.Build.CPU_ABI` and `android.os.Build.CPU_ABI2` parameters.
3.4.1. Совместимость с веб-представлением	Added Chromium as required WebView implementation.
3.7. Virtual Machine Compatibility	Added requirement for xxhdpi and 400dpi screen densities.
3.8.6. Темы	Updated to reflect use of translucent system bars.
3.8.12. Расположение	New section that adds requirement location settings be centralized.
3.8.13. Юникод	New section that adds requirement for emoji support.
3.9. Администрирование устройства	Noted preinstalled administrative applications cannot be the default Device Owner application.
5.1. Медиакодеки	Added VP9 decoder requirement. Added recommended specification for hardware VP8 codecs.
5.3. Декодирование видео	Added VP9. Added recommendation for dynamic resolution switching.
5.4. Аудио запись	Added `REMOTE_SUBMIX` as new required audio source. Made use of `android.media.audiofx.NoiseSuppressor` API a requirement.
6.2.1 Experimental	New section that introduces the ART runtime and requires Dalvik as the default runtime.
7.1.1. Конфигурация экрана	Replaced 1.85 aspect ratio with 1.86. Added 400dpi screen density.
7.1.6. Screen Types	Added 640 dpi (4K) resolution configuration.
7.2.3. Navigation keys	Added Recents function as essential; demoted Menu function in priority.
7.3.6. Термометр	Added SENSOR_TYPE_AMBIENT_TEMPERATURE as recommended thermometer.
7.4.2.2. Настройка туннелированного прямого соединения Wi-Fi	New section that adds support for Wi-Fi Tunneled Direct Link Setup (TDLS).
7.4.4. Ближнеполевая связь	Added Host Card Emulation (HCE) as a requirement. Replaced SNEP GET with Logical Link Control Protocol (LLCP) and added the Bluetooth Object Push Profile as a requirement.
7.4.6. Синхронизировать настройки	New section that adds requirement auto-sync data be enabled by default.
7.6.1. Минимальная память и хранилище	Added `ActivityManager.isLowRamDevice()` setting requirement for devices with less than 512MB of memory. Increased storage requirements from 512MB and 1GB to 1GB and 2GB, respectively.
7.6.2. Shared "External" Storage	Editorial fixes such as change of section name, and moved text that fits in this section from section 9.5. Noted applications may write to their package-specific directories on secondary external storage.
7.7. USB	Added requirement all devices report a USB serial number.
9.5. Многопользовательская поддержка	Moved non multi-user specific text to section 7.6.2.
9.7. Функции безопасности ядра	Rewritten to note switch of SELinux to enforcing mode and requirement SELinux output not be rendered in the user interface.
9.8. Конфиденциальность	New section that adds requirement audio and video recording must trigger continuous notifications to the user.
9.9. Полнодисковое шифрование	New section that adds requirement devices with lockscreen support full-disk encryption.
12. Журнал изменений документа	New section that summarizes changes in the CDD by section.

13. Свяжитесь с нами

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

Определение совместимости Android 4.4

Оглавление

1. Введение