Редакция 1
Последнее обновление: 12 января 2015 г.

© Google Inc., 2015. Все права защищены.
совместимость@android.com

Оглавление

1. Введение

В этом документе перечислены требования, которым необходимо соответствовать, чтобы устройства были совместимы с Android 5.0.

Использование слов «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» соответствует стандарту IETF. определено в RFC2119 [ Ресурсы, 1 ].

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

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

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

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

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

2. Типы устройств

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

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

• ДОЛЖЕН иметь сенсорный экран, встроенный в устройство
• ДОЛЖЕН иметь источник питания, обеспечивающий мобильность, например, аккумулятор.

Устройство Android Television — это реализация устройства Android, которая представляет собой развлекательный интерфейс для просмотра цифровых мультимедиа, фильмов, игр, приложений и/или телепередач в прямом эфире для пользователей, сидящих на расстоянии примерно десяти футов («откинутый назад» или «10-футовый пользовательский интерфейс»). »). Телевизионные устройства Android:

• ДОЛЖЕН иметь встроенный экран ИЛИ включать порт видеовыхода, например VGA, HDMI или беспроводной порт для отображения.
• ДОЛЖНЫ объявить функции android.software.leanback и android.hardware.type.television [ Ресурсы, 3 ]

Устройство Android Watch — это реализация устройства Android, предназначенная для ношения на теле, например, на запястье, и:

• ОБЯЗАТЕЛЬНО иметь экран с физической длиной диагонали в диапазоне от 1,1 до 2,5 дюймов.
• ДОЛЖЕН объявить функцию android.hardware.type.watch
• ДОЛЖЕН поддерживать uiMode = UI_MODE_TYPE_WATCH [ Resources, 4 ]

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

2.1 Конфигурации устройства

Это сводка основных различий в конфигурации оборудования по типам устройств. (Пустые ячейки означают «МОЖЕТ»). В этой таблице описаны не все конфигурации; более подробную информацию см. в соответствующих разделах об оборудовании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ДОЛЖНО соблюдать намерение android.settings.HOME_SETTINGS отображать меню настроек приложения по умолчанию для главного экрана, если реализация устройства сообщает android.software.home_screen [ Resources, 10]
• ДОЛЖНО предоставить меню настроек, которое будет вызывать намерение android.provider.Telephony.ACTION_CHANGE_DEFAULT для отображения диалогового окна для изменения приложения SMS по умолчанию, если реализация устройства сообщает android.hardware.telephony [ Resources, 9 ]
• ДОЛЖНО соблюдать намерение android.settings.NFC_PAYMENT_SETTINGS отображать меню настроек приложения по умолчанию для Tap and Pay, если реализация устройства сообщает android.hardware.nfc.hce [ Resources, 10]

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

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

Управляемый байт-код Dalvik может вызывать собственный код, представленный в файле .apk приложения в виде файла ELF .so, скомпилированного для соответствующей аппаратной архитектуры устройства. Поскольку собственный код сильно зависит от базовой технологии процессора, Android определяет ряд двоичных интерфейсов приложений (ABI) в Android NDK. Реализации устройств ДОЛЖНЫ быть совместимы с одним или несколькими определенными ABI и ДОЛЖНЫ обеспечивать совместимость с Android NDK, как показано ниже.

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

• ДОЛЖНА включать поддержку кода, выполняющегося в управляемой среде, для вызова собственного кода с использованием стандартной семантики Java Native Interface (JNI).
• ДОЛЖЕН быть совместим с исходным кодом (т. е. совместимым с заголовком) и двоично-совместимым (для ABI) с каждой необходимой библиотекой из списка ниже.
• ДОЛЖЕН поддерживать эквивалентный 32-битный ABI, если поддерживается любой 64-битный ABI.
• ДОЛЖЕН точно сообщать о собственном двоичном интерфейсе приложения (ABI), поддерживаемом устройством, через параметры android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS и android.os.Build.SUPPORTED_64_BIT_ABIS, каждый из которых представляет собой список значений, разделенных запятыми. ABI упорядочены от наиболее предпочтительного к наименее предпочтительному.
• ДОЛЖНЫ сообщать с помощью вышеуказанных параметров только те ABI, которые задокументированы в последней версии Android NDK, «NDK Programmer's Guide | ABI Management» в каталоге docs/.
• СЛЕДУЕТ создавать с использованием исходного кода и файлов заголовков, доступных в исходном проекте Android с открытым исходным кодом.

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

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

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

Обратите внимание, что реализации устройства ДОЛЖНЫ включать libGLESv3.so и ДОЛЖНЫ символизировать ссылку (символическую ссылку) на libGLESv2.so. в свою очередь, ДОЛЖЕН экспортировать все функциональные символы OpenGL ES 3.1 и Android Extension Pack [ Resources, 11 ], как определено в выпуске NDK android-21. Хотя все символы должны присутствовать, должны быть полностью реализованы только соответствующие функции для версий и расширений OpenGL ES, фактически поддерживаемых устройством.

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

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

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

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

• Реализации устройства android.webkit.WebView ДОЛЖНЫ быть основаны на сборке Chromium из исходного проекта Android с открытым исходным кодом для Android 5.0. Эта сборка включает в себя определенный набор исправлений функциональности и безопасности для WebView [ Ресурсы, 13 ].
• Строка пользовательского агента, сообщаемая WebView, ДОЛЖНА быть в этом формате:

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, например Gecko) Версия/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

• Значение строки $(VERSION) ДОЛЖНО быть таким же, как значение для android.os.Build.VERSION.RELEASE.
• Значение строки $(MODEL) ДОЛЖНО быть таким же, как значение для android.os.Build.MODEL.
• Значение строки $(BUILD) ДОЛЖНО быть таким же, как значение для android.os.Build.ID.
• Значение строки $(CHROMIUM_VER) ДОЛЖНО соответствовать версии Chromium в исходном проекте Android с открытым исходным кодом.
• Реализации устройства МОГУТ опускать Mobile в строке пользовательского агента.

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

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

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

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

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

• кэш приложения/работа в автономном режиме [ Ресурсы, 15 ]
• тот
• геолокация [ Ресурсы, 17 ]

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

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

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

• Устройства НЕ ДОЛЖНЫ изменять поведение или семантику стандартного намерения.
• Устройства НЕ ДОЛЖНЫ изменять жизненный цикл или семантику жизненного цикла определенного типа системного компонента (например, Службы, Действия, 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, чтобы только те приложения, которые их явно используют (через механизм) зависят от увеличения использования памяти такими API.

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

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

3.7. Совместимость во время выполнения

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

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

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

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

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

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

3.8.2. Виджеты

Android определяет тип компонента, соответствующий API и жизненный цикл, который позволяет приложениям предоставлять конечному пользователю «AppWidget» [ Ресурсы, 21 ] — функцию, поддержку которой НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ в реализациях портативных устройств. Реализации устройств, поддерживающие встраивание виджетов на главный экран, ДОЛЖНЫ соответствовать следующим требованиям и декларировать поддержку функции платформы android.software.app_widgets.

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

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

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

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

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

Android включает поддержку различных уведомлений, таких как:

• Расширенные уведомления — интерактивные представления для текущих уведомлений.
• Уведомления Heads-up — пользователи Interactive Views могут действовать или отклонять действия, не выходя из текущего приложения.
• Уведомления на экране блокировки — уведомления, отображаемые на экране блокировки с детальным контролем видимости.

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

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

3.8.4. Поиск

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

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

3.8.5. Тосты

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

3.8.6. Темы

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

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

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

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

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

3.8.7. Живые обои

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

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

Реализации устройств, способные надежно запускать живые обои, как описано выше, ДОЛЖНЫ реализовывать живые обои, а при реализации ДОЛЖНЫ сообщать флаг функции платформы android.software.live_wallpaper.

3.8.8. Переключение активности

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

• ДОЛЖНЫ отображать связанные недавние события как группу, которая движется вместе.
• ДОЛЖЕН поддерживать как минимум до 20 отображаемых действий.
• ДОЛЖНО отображать как минимум названия 4 действий одновременно.
• СЛЕДУЕТ отображать цвет выделения, значок, заголовок экрана в последних
• ДОЛЖЕН реализовать поведение закрепления экрана [ Ресурсы, 33 ] и предоставить пользователю меню настроек для переключения этой функции.
• СЛЕДУЕТ отображать заключительную возможность («x»), но МОЖЕТ отложить это до тех пор, пока пользователь не будет взаимодействовать с экранами.

Реализациям устройств НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ использовать исходный пользовательский интерфейс Android (или аналогичный интерфейс на основе миниатюр) для экрана обзора.

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

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

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

3.8.10. Управление мультимедиа на экране блокировки

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

3.8.11. Мечты

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

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

Если устройство имеет аппаратный датчик (например, GPS), способный предоставлять координаты местоположения, режимы местоположения ДОЛЖНЫ отображаться в меню «Местоположение» в настройках [ Ресурсы, 37 ].

3.8.13. Юникод и шрифт

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

Android 5.0 включает поддержку шрифта Roboto 2 различной толщины: без засечек-тонкий, без засечек-легкий, без засечек-средний, без засечек-черный, без засечек-сгущенный, без засечек-сгущенный-легкий. которые ДОЛЖНЫ быть включены для языков, доступных на устройстве, и полного покрытия Unicode 7.0 латиницы, греческого языка и кириллицы, включая расширенные латинские диапазоны A, B, C и D, а также все глифы в блоке символов валют Unicode 7.0. .

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

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

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

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

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

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

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

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

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

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

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

3.12. Структура ТВ-входа

Платформа ввода Android Television (TIF) упрощает доставку живого контента на устройства Android Television. TIF предоставляет стандартный API для создания модулей ввода, управляющих устройствами Android Television. Реализации устройств Android Television ДОЛЖНЫ поддерживать инфраструктуру ввода телевидения [ Resources, 46 ].

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

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

Реализации устройств ДОЛЖНЫ устанавливать и запускать файлы Android «.apk», созданные инструментом «aapt», включенным в официальный Android SDK [ Ресурсы, 47 ].

Реализации устройств НЕ ДОЛЖНЫ расширять форматы байт-кода .apk [ Resources, 48 ​​], Android Manifest [ Resources, 49 ], Dalvik [ Resources, 20 ] или RenderScript таким образом, чтобы предотвратить правильную установку и работу этих файлов на другие совместимые устройства

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

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

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

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

5.1.1. Аудиокодеки

1 Требуется для реализаций устройств, определяющих android.hardware.microphone, но необязательно для реализаций устройств Android Watch.

2 Требуется только микширование контента 5.0/5.1; запись или рендеринг более 2 каналов не являются обязательными.

3 Требуется для портативных устройств Android.

4 Требуется для реализаций устройств, определяющих android.hardware.microphone, включая реализации устройств Android Watch.

5.1.2. Кодеки изображений

5.1.3. Видеокодеки

1 Требуется для реализаций устройств, включающих аппаратное обеспечение камеры и определяющих android.hardware.camera или android.hardware.camera.front.

2 Требуется для реализаций устройств, за исключением устройств Android Watch.

3 Для приемлемого качества потокового веб-видео и услуг видеоконференций реализации устройств СЛЕДУЕТ использовать аппаратный кодек VP8, который соответствует требованиям в [ Ресурсы, 51 ].

4 Реализации устройств ДОЛЖНЫ поддерживать запись файлов Matroska WebM.

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

Реализации устройств Android с поддержкой кодека H.264 ДОЛЖНЫ поддерживать базовый профиль уровня 3 и следующие профили кодирования видео SD (стандартной четкости), а также ДОЛЖНЫ поддерживать основной профиль уровня 4 и следующие профили кодирования видео HD (высокой четкости). Устройствам Android Television НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ кодировать видео HD 1080p со скоростью 30 кадров в секунду.

1 Если поддерживается аппаратно, но НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ для устройств Android Television.

Реализации устройств Android с поддержкой кодека VP8 ДОЛЖНЫ поддерживать профили кодирования видео SD и ДОЛЖНЫ поддерживать следующие профили кодирования видео HD (высокой четкости).

1 При поддержке аппаратного обеспечения.

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

Реализации устройства ДОЛЖНЫ поддерживать динамическое переключение разрешения видео в одном потоке для кодеков VP8, VP9, ​​H.264 и H.265.

Реализации устройств Android с декодерами H.264 ДОЛЖНЫ поддерживать базовый профиль уровня 3 и следующие профили декодирования видео SD, а также ДОЛЖНЫ поддерживать профили декодирования HD. Устройства Android Television ДОЛЖНЫ поддерживать High Profile Level 4.2 и профиль декодирования HD 1080p.

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

2 Требуется для реализации устройства Android Television.

Реализации устройств Android при поддержке кодека VP8, как описано в разделе 5.1.3 , ДОЛЖНЫ поддерживать следующие профили декодирования SD и ДОЛЖНЫ поддерживать профили декодирования HD. Устройства Android Television ДОЛЖНЫ поддерживать профиль декодирования HD 1080p.

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

2 Требуется для реализации устройства Android Television.

Реализации устройств Android при поддержке кодека VP9, ​​как описано в разделе 5.1.3 , ДОЛЖНЫ поддерживать следующие профили декодирования видео SD и ДОЛЖНЫ поддерживать профили декодирования HD. Устройствам Android Television НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ поддерживать профиль декодирования HD 1080p, а также ДОЛЖНО поддерживаться профиль декодирования UHD. Если поддерживается профиль декодирования видео UHD, он ДОЛЖЕН поддерживать глубину цвета 8 бит.

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

2 НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ для реализаций устройств Android Television, если они поддерживаются аппаратным обеспечением.

Реализации устройств Android при поддержке кодека H.265, как описано в разделе 5.1.3 , ДОЛЖНЫ поддерживать основной уровень основного профиля 3 и следующие профили декодирования видео SD, а также ДОЛЖНЫ поддерживать профили декодирования HD. Устройства Android Television ДОЛЖНЫ поддерживать основной уровень основного профиля 4.1 и профиль декодирования HD 1080p, а также ДОЛЖНЫ поддерживать профиль основного уровня Main10 уровня 5 и профиль декодирования UHD.

1 Требуется для реализации устройства Android Television, но для устройств другого типа только при их аппаратной поддержке.

2 Требуется для реализации устройства Android Television, если оно поддерживается аппаратным обеспечением.

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

Хотя некоторые требования, изложенные в этом разделе, указаны как СЛЕДУЮЩИЕ, начиная с Android 4.3, в определении совместимости для будущей версии планируется изменить их на ОБЯЗАТЕЛЬНЫЕ. Существующим и новым устройствам Android настоятельно рекомендуется соответствовать этим требованиям, иначе они не смогут обеспечить совместимость с Android при обновлении до будущей версии.

5.4.1. Захват необработанного звука

Реализации устройств, которые объявляют android.hardware.microphone, ДОЛЖНЫ разрешать захват необработанного аудиоконтента со следующими характеристиками:

• Формат : линейный PCM, 16 бит.
• Частота дискретизации : 8000, 11025, 16000, 44100.
• Каналы : Моно

Реализации устройств, которые объявляют, что android.hardware.microphone ДОЛЖНЫ позволять захват необработанного аудиоконтента со следующими характеристиками:

• Формат : линейный PCM, 16 бит.
• Частота выборки : 22050, 48000
• Каналы : Стерео

5.4.2. Захват для распознавания голоса

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

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

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

5.4.3. Захват для изменения маршрута воспроизведения

Класс android.media.MediaRecorder.AudioSource включает источник звука REMOTE_SUBMIX. Устройства, объявляющие android.hardware.audio.output, ДОЛЖНЫ правильно реализовать источник звука REMOTE_SUBMIX, чтобы, когда приложение использует API android.media.AudioRecord для записи из этого источника звука, оно могло захватывать смесь всех аудиопотоков, за исключением следующих: :

• STREAM_RING
• STREAM_ALARM
• ПОТОК_УВЕДОМЛЕНИЕ

5.5. Воспроизведение аудио

Реализации устройств, объявляющие android.hardware.audio.output, ДОЛЖНЫ соответствовать требованиям этого раздела.

5.5.1. Воспроизведение необработанного аудио

Устройство ДОЛЖНО обеспечивать воспроизведение необработанного аудиоконтента со следующими характеристиками:

• Формат : линейный PCM, 16 бит.
• Частота дискретизации : 8000, 11025, 16000, 22050, 32000, 44100.
• Каналы : моно, стерео

Устройство ДОЛЖНО обеспечивать воспроизведение необработанного аудиоконтента со следующими характеристиками:

• Частота выборки : 24000, 48000

5.5.2. Аудио эффекты

Android предоставляет API для звуковых эффектов для реализаций устройств [ Ресурсы, 52 ]. Реализации устройств, в которых объявляется функция android.hardware.audio.output:

• ДОЛЖЕН поддерживать реализации EFFECT_TYPE_EQUALIZER и EFFECT_TYPE_LOUDNESS_ENHANCER, управляемые через подклассы AudioEffect Equalizer, LoudnessEnhancer
• ДОЛЖЕН поддерживать реализацию API визуализатора, управляемую через класс Visualizer.
• СЛЕДУЕТ поддерживать реализации EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB и EFFECT_TYPE_VIRTUALIZER, управляемые через подклассы AudioEffect BassBoost, EnvironmentalReverb, PresetReverb и Virtualizer.

5.5.3. Громкость аудиовыхода

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

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

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

Для целей данного раздела используйте следующие определения:

• задержка вывода — интервал между моментом, когда приложение записывает кадр данных в формате PCM, и моментом, когда соответствующий звук может быть услышан внешним слушателем или обнаружен преобразователем.
• задержка холодного вывода — задержка вывода для первого кадра, когда система вывода звука простаивала и выключалась до запроса.
• непрерывная задержка вывода — задержка вывода для последующих кадров после того, как устройство воспроизводит звук.
• задержка ввода — интервал между представлением внешнего звука на устройстве и моментом, когда приложение считывает соответствующий кадр данных в формате PCM.
• задержка холодного ввода — сумма потерянного времени ввода и задержки ввода для первого кадра, когда система ввода звука простаивала и отключалась до запроса.
• непрерывная задержка ввода — задержка ввода для последующих кадров, пока устройство захватывает звук.
• джиттер холодного выхода — разница между отдельными измерениями значений задержки холодного выхода.
• холодный входной джиттер — Отклонение между отдельными измерениями значений задержки холодного входа.
• непрерывная задержка туда и обратно — сумма постоянной задержки ввода плюс непрерывная задержка вывода плюс 5 миллисекунд.
• API-интерфейс буферной очереди OpenSL ES PCM — набор API-интерфейсов OpenSL ES, связанных с PCM, в Android NDK; см. NDK_root/docs/opensles/index.html.

Реализации устройств, которые объявляют android.hardware.audio.output, ДОЛЖНЫ соответствовать или превосходить эти требования к выводу звука:

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

Если реализация устройства соответствует требованиям этого раздела после любой первоначальной калибровки при использовании API буферной очереди OpenSL ES PCM для непрерывной задержки вывода и задержки холодного вывода хотя бы через одно поддерживаемое устройство вывода звука, оно МОЖЕТ сообщать о поддержке звука с низкой задержкой. , сообщив о функции android.hardware.audio.low_latency через класс android.content.pm.PackageManager [ Resources, 53 ]. И наоборот, если реализация устройства не соответствует этим требованиям, оно НЕ ДОЛЖНО сообщать о поддержке звука с малой задержкой.

Реализации устройств, включающие android.hardware.microphone, ДОЛЖНЫ соответствовать следующим требованиям к входному аудио:

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

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

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

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

5.8. Безопасные медиа

Реализации устройств, поддерживающие безопасный вывод видео и способные поддерживать защищенные поверхности, ДОЛЖНЫ заявить о поддержке Display.FLAG_SECURE. Реализации устройств, которые заявляют о поддержке Display.FLAG_SECURE, если они поддерживают протокол беспроводного дисплея, ДОЛЖНЫ защищать соединение с помощью криптографически стойкого механизма, такого как HDCP 2.x или выше, для беспроводных дисплеев Miracast. Аналогичным образом, если они поддерживают проводной внешний дисплей, реализации устройства ДОЛЖНЫ поддерживать HDCP 1.2 или выше. Реализации устройств Android Television ДОЛЖНЫ поддерживать HDCP 2.2 для устройств, поддерживающих разрешение 4K, и HDCP 1.4 или выше для более низких разрешений. Первоначальная реализация Android с открытым исходным кодом включает поддержку беспроводных (Miracast) и проводных (HDMI) дисплеев, что удовлетворяет этому требованию.

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

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

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

• Android Debug Bridge (adb) [ Ресурсы, 55 ]

Реализации устройств ДОЛЖНЫ поддерживать все функции adb, как описано в Android SDK, включая dumpsys [ Ресурсы, 56 ]. Демон adb на стороне устройства ДОЛЖЕН быть неактивен по умолчанию, и ДОЛЖЕН быть доступный пользователю механизм для включения Android Debug Bridge. Если в реализации устройства отсутствует режим периферийного устройства USB, оно ДОЛЖНО реализовать Android Debug Bridge через локальную сеть (например, Ethernet или 802.11).

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

• Служба мониторинга отладки Dalvik (ddms) [ Ресурсы, 57 ]

Реализации устройств ДОЛЖНЫ поддерживать все функции ddms, как описано в Android SDK. Поскольку ddms использует adb, поддержка ddms ДОЛЖНА быть неактивной по умолчанию, но ДОЛЖНА поддерживаться каждый раз, когда пользователь активирует Android Debug Bridge, как указано выше.

• Обезьяна [ Ресурсы, 58 ]

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

• Systrace [ Resources, 59 ]

Реализации устройств должны поддерживать инструмент 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 и Windows 9 в 32-битных и 64-битных версиях.

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

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

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 для того же отпечатка для сборки. [ Ресурсы, 53]

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

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

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

• Физический диагональный размер - расстояние в дюймах между двумя противоположными углами освещенной части дисплея.
• Точки на дюйм (DPI) - количество пикселей, охватываемых линейным горизонтальным или вертикальным промежутком 1 ". Где значения DPI перечислены, как горизонтальный, так и вертикальный DPI должны попадать в диапазон.
• Соотношение сторон - отношение более длинного измерения экрана к более короткому измерению. Например, отображение 480x854 пикселей будет 854 /480 = 1,779 или примерно "16: 9".
• Зависимый от плотности пиксель (DP) -виртуальный пиксельный блок, нормализованный на экране 160 DPI, рассчитывается как: Pixels = DPS * (плотность / 160).

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

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

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

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

Кроме того,

• Устройства для часов Android должны иметь экран с физическим диагональным размером в диапазоне от 1,1 до 2,5 дюйма
• Другие типы реализаций устройств Android с физически интегрированным экраном должны иметь экран, по крайней мере, 2,5 дюйма в физическом диагональном размере.

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

Приложения необязательно указывают, какие размеры экрана они поддерживают через Атрибут в файле AndroidManifest.xml. Реализации устройств должны правильно чтить поддержку приложений для небольших, нормальных, больших и Xlarge экранов, как описано в документации Android SDK.

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

Соотношение сторон экрана должно быть значением от 1,3333 (4: 3) до 1,86 (примерно 16: 9), но устройства для наблюдения за Android могут иметь соотношение сторон 1,0 (1: 1), потому что такая реализация устройства будет использовать ui_mode_type_watch как Android.content.res.configuration.uimode.

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

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

• 120 т/д (лдпи)
• 160 т/д (мдпи)
• 213 точек на дюйм (твдпи)
• 240 точек на дюйм (HDPI)
• 320 точек на дюйм (xhdpi)
• 400 т/д (400 т/д)
• 480 точек на дюйм (xxhdpi)
• 560 т/д (560 т/д)
• 640 точек на дюйм (xxxhdpi)

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

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

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

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

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

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

Устройства должны сообщать о правильном значении текущей ориентации устройства, когда запрашиваются через android.content.res.configuration.orientation, android.view.display.getorientation () или другие API.

Устройства не должны изменять сообщаемый размер экрана или плотность при изменении ориентации.

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

Реализации устройств должны поддерживать как OpenGL ES, так и 2.0, как воплощенные и подробные в документациях Android SDK. Реализации устройств должны поддерживать OpenGL ES 3.0 или 3.1 на устройствах, способных поддержать его. Реализации устройств также должны поддерживать Android renderscript, как подробно описано в документации Android SDK [ Resources, 63 ].

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

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

В дополнение к OpenGL ES 3.1, Android предоставляет пакет расширения с интерфейсами Java [ ресурсы, 64 ] и собственной поддержкой для расширенных функциональности графики, таких как Tessellation и формат сжатия текстуры ASTC. Реализации устройств Android могут поддерживать этот пакет расширения, и - только, если полностью реализовано - и определите поддержку через флаг android.hardware.opengles.aep.

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

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

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

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

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

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

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

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

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

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

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

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

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

Android включает в себя поддержку вторичного дисплея для обеспечения возможностей обмена медиа -сайтами и API -интерфейсов разработчиков для доступа к внешним дисплеям. Если устройство поддерживает внешний дисплей либо через проводное, беспроводное или встроенное дополнительное соединение дисплея, то реализация устройства должна реализовать API диспетчера Display, как описано в документации Android SDK [ Resources, 67 ].

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

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

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

• Должен включить поддержку платформы управления вводами (которая позволяет сторонним разработчикам создавать редакторы метода ввода-мягкую клавиатуру), как подробно описано по адресу http://developer.android.com
• Должен обеспечить хотя бы одну реализацию мягкой клавиатуры (независимо от того, присутствует ли жесткая клавиатура), за исключением Android Watch Devices, где размер экрана делает менее разумным иметь мягкую клавиатуру
• Может включать дополнительные реализации мягкой клавиатуры
• Может включать аппаратную клавиатуру
• Не должен включать аппаратную клавиатуру, которая не соответствует одному из форматов, указанных в Android.content.res.configuration.keyboard [ Resources, 68 ] (Qwerty или 12-ключ)

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

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

• Может опустить опцию не касательной навигации (Trackball, D-PAD или колеса), если реализация устройства не является устройством Android Television
• Должен сообщить о правильном значении для android.content.res.configuration.navigation [ ресурсы, 68 ]
• Должен предоставить разумный альтернативный механизм пользовательского интерфейса для выбора и редактирования текста, совместимый с двигателями управления вводами. Реализация Android с открытым исходным кодом вверх по течению включает механизм выбора, подходящий для использования с устройствами, в которых отсутствуют навигационные входы, не связанные с навигацией.

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

Функции дома, Recesr и Back (сопоставлены с ключевыми событиями keyCode_home, KeyCode_App_switch, KeyCode_back, соответственно) необходимы для парадигмы навигации Android и, следовательно,;

• Реализация портативных устройств Android должна предоставлять функции дома, рецензирования и обратного.
• Реализации устройств Android Television должны предоставлять функции дома и обратной стороны.
• Реализации устройств Android Watch должны иметь домашнюю функцию для пользователя, а функция задней части, за исключением случаев, когда она находится в UI_MODE_TYPE_WATCH.
• Все другие типы реализаций устройства должны предоставлять функции дома и обратной стороны.

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

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

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

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

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

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

Android поддерживает Assist Action [ Resources, 69 ]. Реализации устройств Android, за исключением Android Watch Devices, должны все время предоставлять помощь пользователю при запуске приложений. Ассистент должен осуществляться в качестве дальнего отжатия на кнопке «Домой» или жест на ключ программного обеспечения. Эта функция может быть реализована через другую физическую кнопку, программную клавишу или жест, но должна быть доступна с одним действием (например, нажатие, дважды щелкнуть или жест), когда видны другие навигационные клавиши.

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

• Навигационные клавиши реализации устройства должны использовать отдельную часть экрана, недоступная для приложений, и не должны скрывать или иным образом мешать части экрана, доступной для приложений.
• Реализации устройства должны предоставить часть дисплея для приложений, которые соответствуют требованиям, определенным в разделе 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, 68 ] соответствует типу конкретного сенсорного экрана на устройстве

Android включает в себя поддержку различных сенсорных экранов, сенсорных колодок и поддельных устройств для ввода сенсорных. Реализации устройств на основе сенсорного экрана связаны с дисплеем [ ресурсов, 70 ], так что пользователь имеет впечатление непосредственно манипулирования элементами на экране. Поскольку пользователь непосредственно касается экрана, система не требует дополнительных возможностей, чтобы указать, что манипулируют объектами. Напротив, фальшивый сенсорный интерфейс предоставляет систему ввода пользователя, которая приближается к подмножеством возможностей сенсорного экрана. Например, мышь или пульт дистанционного управления, который приводит к экране курсора, приближается к прикосновению, но требует, чтобы пользователь был первой точкой или фокусировкой, а затем нажимает. Многочисленные входные устройства, такие как мышь, трекпад, воздушная мышь на основе гироскопии, гиро-указатель, джойстик и мультитач-трекпад, могут поддерживать фальшивые сенсорные взаимодействия. Android 5.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 в расположении указателя и отобразите визуальный указатель на экране [ ресурсы, 71 ]
• Должен сообщить о событии Touch с кодом действия, который указывает изменение состояния, которое происходит на указателе, идущем или вверх на экране [ ресурсы, 71 ]
• Необходимо поддерживать указатель вниз и вверх на объекте на экране, который позволяет пользователям эмулировать нажатие на объект на экране
• Необходимо поддерживать указатель вниз, указатель вверх, указатель вниз, затем указатель в то же место на объекте на экране в течение времени, который позволяет пользователям эмулировать двойной нажатие на объект на экране [ Ресурсы, 71 ]
• Необходимо поддерживать указатель вниз по произвольной точке на экране, указатель перемещается в любую другую произвольную точку на экране, а затем указатель вверх, что позволяет пользователям эмулировать перетаскивание прикосновения
• Необходимо поддерживать указатель вниз, а затем позволить пользователям быстро перемещать объект в другую позицию на экране, а затем укажите на экране, что позволяет пользователям бросить объект на экране

Устройства, которые объявляют поддержку Android.hardware.faketouch.multitouch.distinct, должны соответствовать требованиям для Faketouch выше, а также должны поддерживать отдельное отслеживание двух или более независимых входов указателя.

7.2.6. Поддержка игровых контроллеров

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

7.2.6.1. Сопоставления кнопок

Реализации устройств телевидения Android должны поддерживать следующие сопоставления ключей:

1 [ Ресурсы, 72 ]

2 Приведенные выше использование HID должны быть объявлены в игровой подушке CA (0x01 0x0005).

3 Это использование должно иметь логический минимум 0, логический максимум 7, физический минимум 0, физический максимум 315, единицы в градусах и размер отчета 4. Логическое значение определяется как вращение по часовой стрелке. вдали от вертикальной оси; Например, логическое значение 0 не представляет вращения, а кнопка UP нажимается, в то время как логическое значение 1 представляет собой вращение 45 градусов, а также нажимают как вверх, так и левые клавиши.

4 [ Ресурсы, 71 ]

1 [ Ресурсы, 71 ]

7.2.7. Дистанционное управление

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

• Поиск по предоставлению предоставления реализаций должен запускать KeyCode_search, когда пользователь вызывает голосовой поиск либо на физическом, либо на основе программного обеспечения.
• Навигация . Все пульты Android Television должны включать обратно, дома и выбирать кнопки и поддержку событий D-PAD [ ресурсы, 72 ].

7.3. Датчики

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

• Должен точно сообщить о наличии или отсутствии датчиков на класс Android.content.pm.packagemanager [ Resources, 53]
• Должен вернуть точный список поддерживаемых датчиков через Sensormanager.getSensorList () и аналогичные методы
• Должен вести себя разумно для всех других датчиков (например, возвращая True или False в зависимости от необходимости, когда приложения пытаются зарегистрировать слушателей, не вызывая слушателей датчиков, когда соответствующие датчики не присутствуют; и т. Д.)
• Должен сообщить о всех измерениях датчиков, используя соответствующую международную систему значений единиц (метрические) для каждого типа датчика, как определено в документации Android SDK [ ресурсы, 74 ]
• Следует сообщить о времени события в наносекундах, как это определено в документации Android SDK, представляя время, когда событие произошло, и синхронизируется с часами SystemClock.elapsedRealTimenano (). Существующим и новым устройствам Android очень настоятельно рекомендуется удовлетворить эти требования, чтобы они смогли перейти на будущие выпуски платформы, где это может стать необходимым компонентом. Ошибка синхронизации должна быть ниже 100 миллисекунд [ ресурсы, 75 ].

Список выше не является всеобъемлющим; Задокументированное поведение Android SDK и документации Android с открытым исходным кодом на датчиках [ ресурсы, 73 ] должны считаться авторитетными.

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

Некоторый датчик Android поддерживает «непрерывный» режим триггера, который непрерывно возвращает данные [ ресурсы, 77 ]. Для любого API, указанного в документации Android SDK, является непрерывным датчиком, реализации устройств должны непрерывно предоставлять периодические образцы данных, которые должны иметь джиттер ниже 3%, где дрожание определяется как стандартное отклонение разности сообщаемой значений временных тканей между последовательными. события.

Обратите внимание, что реализации устройства должны гарантировать, что поток событий датчика не должен предотвратить въезд ЦП устройства в приостановленное состояние или просыпаться из приостановки.

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

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

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

• Необходимо реализовать и сообщать датчик Type_accelerometer [ ресурсы, 78 ]
• Должен быть в состоянии сообщать о событиях до частоты не менее 100 Гц и должен сообщать о событиях не менее 200 Гц
• Должен соблюдать систему координат датчика Android, как подробно описано в API API Android [ Resources, 74 ]
• Должен быть способен измерять от свободного падения в четыре раза больше тяжести (4G) или более на любой оси
• Должен иметь разрешение не менее 8 битов и должно иметь разрешение не менее 16 бит
• Следует откалибровать во время использования, если характеристики изменяются в течение жизненного цикла и компенсируются, и сохранить параметры компенсации между перезагрузками устройства
• Должен быть компенсирован температурой
• Должен иметь стандартное отклонение не более 0,05 м/с^, где стандартное отклонение должно быть рассчитано по базисной основе для образцов, собранных в течение не менее 3 секунд с самой быстрой скоростью отбора проб
• Следует реализовать type_significant_motion, type_tilt_detector, type_step_detector, композитные датчики type_step_counter, как описано в документе Android SDK. Существующим и новым устройствам Android очень настоятельно рекомендуется реализовать композитный датчик type_significant_motion. Если какой -либо из этих датчиков реализован, сумма их энергопотребления всегда должна быть менее 4 МВт и должна быть ниже 2 МВт и 0,5 МВт для при том, когда устройство находится в динамическом или статическом состоянии.
• Если датчик гироскопа включен, должен реализовать композитные датчики type_gravity и type_linear_acceleration и должен реализовать композитный датчик Type_game_rotation_vector. Существующим и новым устройствам Android настоятельно рекомендуется реализовать датчик type_game_rotation_vector.
• Следует реализовать композитный датчик Type_Rotation_Vector, если также включен датчик гироскопа и датчик магнитометра

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

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

• Должен реализовать датчик type_magnetic_field, а также должен реализовать датчик type_magnetic_field_uncalibrated. Существующим и новым устройствам Android настоятельно рекомендуется реализовать датчик type_magnetic_field_uncalibrated.
• Должен быть в состоянии сообщать о событиях до частоты не менее 10 Гц и должен сообщать о событиях не менее 50 Гц
• Должен соблюдать систему координат датчика Android, как подробно описано в API API Android [ Resources, 74 ]
• Должен быть способен измерять от -900 мкт до +900 мкт на каждой оси перед насыщением
• Должен иметь жесткое значение смещения железа менее 700 мкт и должно иметь значение ниже 200 мкт, путем размещения магнитометра вдали от динамического (индуцированного тока) и статического (индуцированного магнитом) магнитными полями
• Должен иметь разрешение, равное или плотно, чем 0,6 мкт и должно иметь разрешение равным или плотном, чем 0,2 мкт
• Должен быть компенсирован температурой
• Необходимо поддерживать онлайн -калибровку и компенсацию смещения жесткого железа и сохранить параметры компенсации между перезагрузками устройства
• Должна иметь компенсацию мягкого железа - калибровка может быть сделана либо при использовании, либо во время производства устройства
• Должно иметь стандартное отклонение, рассчитанное по базисной основе на оси на образцах, собранных в течение не менее 3 секунд при самой быстрой скорости отбора проб, не более 0,5 мкт
• Следует реализовать композитный датчик Type_Rotation_Vector, если также включен датчик акселерометра и датчик гироскопа
• Может реализовать датчик type_geomagnetic_rotation_vector, если также реализован датчик акселерометра. Однако в случае реализации он должен потреблять менее 10 МВт и должен потреблять менее 3 МВт, когда датчик зарегистрирован для пакетного режима при 10 Гц.

7.3.3. GPS

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

7.3.4. Гироскоп

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

• Должен реализовать датчик type_gyroscope, а также должен реализовать датчик type_gyroscope_uncalibrated. Существующим и новым устройствам Android настоятельно рекомендуется реализовать датчик SENSOR_TYPE_GYROSCOPE_UNCALIBRED.
• Должен быть способен измерять изменения ориентации до 1000 градусов в секунду
• Должен быть в состоянии сообщать о событиях до частоты не менее 100 Гц и должен сообщать о событиях не менее 200 Гц
• Должен иметь разрешение на 12 бит или более и должно иметь разрешение на 16 бит или более
• Должен быть компенсирован температурой
• Должен быть откалиброван и компенсирован во время использования, и сохранить параметры компенсации между перезагрузками устройства
• Должен иметь дисперсию не больше 1E-7 Rad^2 / S^2 на Гц (дисперсия на Гц или рад^2 / с). Разница может варьироваться в зависимости от скорости отбора проб, но должна быть ограничена этим значением. Другими словами, если вы измеряете дисперсию гироскопа при скорости отбора проб 1 Гц, это должно быть не больше 1e-7 Rad^2/s^2.
• Следует реализовать композитный датчик Type_Rotation_Vector, если также включен датчик акселерометра и датчик магнитометра
• Если датчик акселерометра включен, должен реализовать композитные датчики type_gravity и type_linear_acceleration и должен реализовать композитный датчик type_game_rotation_vector. Существующим и новым устройствам Android настоятельно рекомендуется реализовать датчик type_game_rotation_vector.

7.3.5. Барометр

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

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

7.3.6. Термометр

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

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

7.3.7. Фотометр

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

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

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

• Должен измерить близость объекта в том же направлении, что и экран. То есть датчик близости должен быть ориентирован для обнаружения объектов, близких к экрану, так как основным намерением этого типа датчика является обнаружение телефона, используемый пользователем. Если реализация устройства включает датчик близости с любой другой ориентацией, оно не должно быть доступно через этот 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 и т. Д.), И другие типы реализации устройства Android должны включать поддержку одной или нескольких форм 802.11. Если реализация устройства включает в себя поддержку 802.11 и предоставляет функциональность стороннему приложению, она должна реализовать соответствующий API Android и:

• Необходимо сообщить об аппаратном флаге Android.hardware.wifi
• Должен реализовать многоадресный API, как описано в документации SDK [ Resources, 79 ]
• Необходимо поддерживать многоадресную DNS (MDNS) и не должен фильтровать пакеты MDNS (224.0.0.251) в любое время работы, включая когда экран не в активном состоянии

7.4.2.1. Wi-Fi прямой

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

• Необходимо сообщить об аппаратной функции Android.hardware.wifi.direct
• Должен поддерживать обычную операцию Wi-Fi
• Следует поддержать одновременную прямую операцию Wi-Fi и Wi-Fi

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

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

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

7.4.3. Bluetooth

Android включает в себя поддержку Bluetooth и Bluetooth Low Energy [ Resources, 82 ]. Реализации устройств, которые включают в себя поддержку Bluetooth и Bluetooth Low Energy, должны объявлять соответствующие функции платформы (android.hardware.bluetooth и android.hardware.bluetooth_le соответственно) и реализовать API платформы. Реализации устройств должны реализовать соответствующие профили Bluetooth, такие как A2DP, AVCP, OBEX и т. Д. В зависимости от устройства. Реализации устройств Android Television должны поддерживать Bluetooth и Bluetooth LE.

Реализации устройств, включая поддержку Bluetooth Low Energy:

• Должен объявить аппаратную функцию android.hardware.bluetooth_le
• Должен включить API Bluetooth на основе GATT (общий атрибут), как описано в документации SDK и [ ресурсы, 82 ]
• Должен поддерживать разгрузку логики фильтрации на чипсете Bluetooth при внедрении API Scanfilter [ ресурсы, 83 ], и должен сообщать о правильном значении, где логика фильтрации реализуется всякий раз, когда запрашивается через Android.bluetooth.bluetoothAdapter.isoffultedFilteringSupported () метод.
• Следует поддерживать разгрузку пакетного сканирования на чипсете Bluetooth, но, если не поддерживаться, должен сообщать о «false» всякий раз, когда прожигается через метод Android.bluetooth.blueToothAdapater.isOffuldScanBatchingSupported ().
• Следует поддерживать многочисленную рекламу с не менее 4 слотами, но если не поддерживаться, должна сообщать о «false» всякий раз, когда запрашивается через Android.bluetooth.bluetoothAdapter.ismultipleAdersementsePorted () метод

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

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

• Должен сообщить о функции Android.hardware.nfc из метода Android.content.pm.packagemanager.hassystemfeature () [ Resources, 53 ]
• Должен быть способен читать и писать сообщения NDEF через следующие стандарты NFC:
  • MUST be capable of acting as an NFC Forum reader/writer (as defined by the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
  • SHOULD be capable of reading and writing NDEF messages via the following NFC standards. 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. These standards are optional in this version but will be required in future versions. Existing and new devices that run this version of Android are very strongly encouraged to meet these requirements now so they will be able to upgrade to the future platform releases.
    • NfcV (ISO 15693)
  • MUST be capable of transmitting and receiving data via the following peer-to-peer standards and protocols:
    • ISO 18092
    • LLCP 1.0 (defined by the NFC Forum)
    • SDP 1.0 (defined by the NFC Forum)
    • NDEF Push Protocol [ Resources, 84 ]
    • SNEP 1.0 (defined by the NFC Forum)
  • MUST include support for Android Beam [ Resources, 85 ]:
    • MUST implement the SNEP default server. Valid NDEF messages received by the default SNEP server MUST be dispatched to applications using the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings MUST NOT disable dispatch of incoming NDEF message.
    • MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 86 ]
    • MUST implement the NPP server. Messages received by the NPP server MUST be processed the same way as the SNEP default server.
    • MUST implement a SNEP client and attempt to send outbound P2P NDEF to the default SNEP server when Android Beam is enabled. If no default SNEP server is found then the client MUST attempt to send to an NPP server.
    • 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 and MUST be able to send and receive using Android Beam, even when another proprietary NFC P2p mode is turned on
    • MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile. Device implementations MUST support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the "Connection Handover version 1.2" [ Resources, 87 ] and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [ Resources, 88 ] specs from the NFC Forum. Such an implementation MUST implement the handover LLCP service with service name "urn:nfc:sn:handover" for exchanging the handover request/select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer. For legacy reasons (to remain compatible with Android 4.1 devices), the implementation SHOULD still accept SNEP GET requests for exchanging the handover request/select records over NFC. However an implementation itself SHOULD NOT send SNEP GET requests for performing connection handover.
  • 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

(Note that publicly available links are not available for the JIS, ISO, and NFC Forum specifications cited above.)

Android 5.0 includes support for NFC Host Card Emulation (HCE) mode. If a device implementation does include an NFC controller capable of HCE and Application ID (AID) routing, then it:

• MUST report the android.hardware.nfc.hce feature constant
• MUST support NFC HCE APIs as defined in the Android SDK [ Resources, 10 ]

Additionally, device implementations MAY include reader/writer support for the following MIFARE technologies.

• MIFARE Classic
• MIFARE Ultralight
• NDEF on MIFARE Classic

Note that Android includes APIs for these MIFARE types. If a device implementation supports MIFARE in the reader/writer role, it:

• MUST implement the corresponding Android APIs as documented by the Android SDK
• MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() meth od [Resources, 53] . Note that this is not a standard Android feature and as such does not appear as a constant on the PackageManager class.
• MUST NOT implement the corresponding Android APIs nor report the com.nxp.mifare feature unless it also implements general NFC support as described in this section

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, 53] , and MUST implement the Android NFC API as a no-op.

As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a protocol-independent data representation format, device implementations MUST implement these APIs even if they do not include support for NFC or declare the android.hardware.nfc feature.

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

Device implementations MUST include support for one or more forms of data networking. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, etc.

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi).

Devices MAY implement more than one form of data connectivity.

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

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

7.5. Камеры

Device implementations SHOULD include a rear-facing camera and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

If a device implementation includes at least one camera, it SHOULD be possible for an application to simultaneously allocate 3 bitmaps equal to the size of the images produced by the largest-resolution camera sensor on the device.

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

Device implementations SHOULD include a rear-facing camera. If a device implementation includes at least one rear-facing camera, it:

• MUST report the feature flag android.hardware.camera and android.hardware.camera.any
• MUST have a resolution of at least 2 megapixels
• SHOULD have either hardware auto-focus or software auto-focus implemented in the camera driver (transparent to application software)
• MAY have fixed-focus or EDOF (extended depth of field) hardware
• MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a 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. Фронтальная камера

Device implementations MAY include a front-facing camera. If a device implementation includes at least one front-facing camera, it:

• MUST report the feature flag android.hardware.camera.any and android.hardware.camera.front
• MUST have a resolution of at least VGA (640x480 pixels)
• MUST NOT use a front-facing camera as the default for the Camera API. 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 device.
• MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in section 7.5.1
• MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
  • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation()[ Resources, 90 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
• MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. If the device implementation does not support postview, this requirement obviously does not apply.
• MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3. Внешняя камера

Device implementations with USB host mode MAY include support for an external camera that connects to the USB port. If a device includes support for an external camera, it:

• MUST declare the platform feature android.hardware.camera.external and android.hardware camera.any
• MUST support USB Video Class (UVC 1.0 or higher)
• MAY support multiple cameras

Video compression (such as MJPEG) support is RECOMMENDED to enable transfer of high-quality unencoded streams (ie raw or independently compressed picture streams). Camera-based video encoding MAY be supported. If so, a simultaneous unencoded/ MJPEG stream (QVGA or greater resolution) MUST be accessible to the device implementation.

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

Android includes two API packages to access the camera, the newer android.hardware.camera2 API expose lower-level camera control to the app, including efficient zero-copy burst/streaming flows and per-frame controls of exposure, gain, white balance gains, color conversion, denoising, sharpening, and more.

The older API package, android.hardware.Camera, is marked as deprecated in Android 5.0 but as it should still be available for apps to use Android device implementations MUST ensure the continued support of the API as described in this section and in the Android SDK .

Device implementations MUST implement the following behaviors for the camera-related APIs, for all available 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.
• If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
• For android.hardware.Camera, 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. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)
• For android.hardware.camera2, device implementations must support the android.hardware.ImageFormat.YUV_420_888 and android.hardware.ImageFormat.JPEG formats as outputs through the android.media.ImageReader API.

Device implementations MUST still implement the full Camera API included in the Android SDK documentation [ Resources, 91 ], regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. 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. That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 92 ].

Because not all device implementations can fully support all the features of the android.hardware.camera2 API, device implementations MUST report the proper level of support with the android.info.supportedHardwareLevel property as described in the Android SDK [ Resources, 93] and report the appropriate framework feature flags [ Resources, 94] .

Device implementations MUST also declare its Individual camera capabilities of android.hardware.camera2 via the android.request.availableCapabilities property and declare the appropriate feature flags [ Resources, 94] ; a device must define the feature flag if any of its attached camera devices supports the feature.

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

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

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

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

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

The memory available to the kernel and userspace on device implementations MUST be at least equal or larger than the minimum values specified by the following table. (See section 7.1.1 for screen size and density definitions.)

The minimum memory values MUST be in addition to any memory space already dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Android Television devices MUST have at least 5GB and other device implementations MUST have at least 1.5GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 5GB for Android Television devices and at least 1.5GB for other device implementations. Device implementations that run Android are very strongly encouraged to have at least 3GB 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, 95 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2. Общее хранилище приложений

Device implementations MUST offer shared storage for applications also often referred as “shared external storage”.

Device implementations MUST be configured with shared storage mounted by default, "out of the box". 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.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital (SD) card slot. If this slot is used to satisfy the shared storage requirement, the device implementation:

• MUST implement a toast or pop-up user interface warning the user when there is no SD card
• MUST include a FAT-formatted SD card 1GB in size or larger OR show on the box and other material available at time of purchase that the SD card has to be separately purchased
• MUST mount the SD card by default

Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps as included in the upstream Android Open Source Project; device implementations SHOULD use this configuration and software implementation. If a device implementation uses internal (non-removable) storage to satisfy the shared storage 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 в другом месте).

Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST allow only pre-installed & privileged Android applications with the WRITE_EXTERNAL_STORAGE permission to write to the secondary external storage, except for the 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.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol, it:

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

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

7.7. USB

Device implementations SHOULD support USB peripheral mode and SHOULD support USB host mode.

If a device implementation includes a USB port supporting peripheral mode:

• The port MUST be connectable to a USB host that has a standard type-A or type -C USB port.
• The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• The port SHOULD either be located 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 Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• It SHOULD implement the Android Open Accessory (AOA) API and specification as documented in the Android SDK documentation, and if it is an Android Handheld device it MUST implement the AOA API. Device implementations implementing the AOA specification:
  • MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 97 ]
  • MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ]
• It SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ]. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to the future platform releases.
• The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB port supporting host mode, it:

• SHOULD use a type-C USB port, if the device implementation supports USB 3.1
• MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to a standard type-A or type-C USB port
• MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables adapting the port to a standard type-A or type-C USB port
• is very strongly RECOMMENDED to implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ]
• 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, 100 ]
• SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ].

7.8. Аудио

7.8.1. Микрофон

Device implementations MAY omit a microphone. However, if a device implementation omits a microphone, it MUST NOT report the android.hardware.microphone feature constant, and MUST implement the audio recording API at least as no-ops, per section 7 . Conversely, device implementations that do possess a microphone:

• MUST report the android.hardware.microphone feature constant
• MUST meet the audio recording requirements in section 5.4
• MUST meet the audio latency requirements in section 5.6

7.8.2. Аудио выход

Device implementations including a speaker or with an audio/multimedia output port for an audio output peripheral as a headset or an external speaker:

• MUST report the android.hardware.audio.output feature constant
• MUST meet the audio playback requirements in section 5.5
• MUST meet the audio latency requirements in section 5.6

Conversely, if a device implementation does not include a speaker or audio output port, it MUST NOT report the android.hardware.audio output feature, and MUST implement the Audio Output related APIs as no-ops at least.

Android Watch device implementation MAY but SHOULD NOT have audio output, but other types of Android device implementations MUST have an audio output and declare android.hardware.audio.output.

7.8.2.1. Аналоговые аудиопорты

In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem [ Resources, 101 ], if a device implementation includes one or more analog audio ports, at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:

• MUST support audio playback to stereo headphones and stereo headsets with a microphone, and SHOULD support audio recording from stereo headsets with a microphone
• MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support audio plugs with the OMTP pin-out order
• MUST support the detection of microphone on the plugged in audio accessory, if the device implementation supports a microphone, and broadcast the android.intent.action.HEADSET_PLUG with the extra value microphone set as 1
• SHOULD support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 70 ohm or less : KEYCODE_HEADSETHOOK
  • 210–290 Ohm : KEYCODE_VOLUME_UP
  • 360–680 Ohm : KEYCODE_VOLUME_DOWN
• SHOULD support the detection and mapping to the keycode for the following range of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 110–180 Ohm: KEYCODE_VOICE_ASSIST
• MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack
• MUST be capable of driving at least 150mV +/- 10% of output voltage on a 32 Ohm speaker impedance
• MUST have a microphone bias voltage between 1.8V ~ 2.9V

8. Performance Compatibility

Some minimum performance criterias are critical to the user experience and impacts the baseline assumptions developers would have when developing an app. Android Watch devices SHOULD and other type of device implementations MUST meet the following criteria:

8.1. Согласованность пользовательского опыта

Device implementations MUST provide a smooth user interface by ensuring a consistent frame rate and response times for applications and games. Device implementations MUST meet the following requirements:

• Consistent frame latency Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.
• User interface latency Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs.
• Task switching When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.

8.2. Производительность доступа к файловому вводу-выводу

Device implementations MUST ensure file access performance consistency for read and write operations.

• Sequential write Device implementations MUST ensure a sequential write performance of 5MB/s for a 256MB file using 10MB write buffer.
• Random write Device implementations MUST ensure a random write performance of 0.5MB/s for a 256MB file using 4KB write buffer.
• Sequential read Device implementations MUST ensure a sequential read performance of 15MB/s for a 256MB file using 10MB write buffer.
• Random read Device implementations MUST ensure a random read performance of 3.5MB/s for a 256MB file using 4KB write buffer.

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, 102 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow subsections.

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

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 102 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

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

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unixstyle 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, 102 ].

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

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

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

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik Executable Format or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

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 механизм.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. Specifically, alternate runtimes:

• SHOULD install apps via the PackageManager into separate Android sandboxes ( Linux user IDs, etc.)
• MAY provide a single Android sandbox shared by all applications using the alternate runtime
• 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
• MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications
• MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. 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. If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

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

Android includes support for multiple users and provides support for full user isolation [ Resources, 103] . Device implementations MAY enable multiple users, but when enabled MUST meet the following requirements related to multi-user support [ Resources, 104 ]:

• Device implementations that do not declare the android.hardware.telephony feature flag MUST support 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.
• Conversely device implementations that declare the android.hardware.telephony feature flag MUST NOT support restricted profiles but MUST align with the AOSP implementation of controls to enable /disable other users from accessing the voice calls and SMS.
• 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, 102 ]
• Device implementations MAY support creating users and managed profiles via the android.app.admin.DevicePolicyManager APIs, and if supported, MUST declare the platform feature flag android.software.managed_users.
• Device implementations that declare the feature flag android.software.managed_users MUST use the upstream AOSP icon badge to represent the managed applications and other badge UI elements like Recents & Notifications.
• 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 primary external storage APIs MUST encrypt the contents of the SD card if multiuser 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, 105 ] for primary external storage.

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

Android includes support for warning users of any outgoing premium SMS message [ Resources, 106 ] . 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 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 implemented below the Android framework:

• MUST maintain compatibility with existing applications
• MUST NOT have a visible user interface when a security violation is detected and successfully blocked, but MAY have a visible user interface when an unblocked security violation occurs resulting in a successful exploit
• 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 or, if using a kernel other than Linux, an equivalent mandatory access control system. Devices must also meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

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

• MUST set SELinux to global enforcing mode,
• MUST configure all domains in enforcing mode. No permissive mode domains are allowed, including domains specific to a device/vendor.
• MUST NOT modify, omit, or replace the neverallow rules present within the external/sepolicy folder provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present, for both AOSP SELinux domains as well as device/vendor specific domains.

Device implementations SHOULD retain the default SELinux policy provided in the external/sepolicy folder of the upstream Android Open Source Project and only further add to this policy for their own device-specific configuration. 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 implementation has a lock screen, the device MUST support full-disk encryption of the application private data, (/data partition) as well as the SD card partition if it is a permanent, non-removable part of the device [ Resources , 107 ]. For devices supporting full-disk encryption, the full-disk encryption SHOULD be enabled all the time after the user has completed the out-of-box experience. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time without being encrypted. Other than when in active use, the encryption key SHOULD be AES encrypted with the lockscreen passcode stretched using a slow stretching algorithm (eg PBKDF2 or scrypt). If the user has not specified a lockscreen passcode or has disabled use of the passcode for encryption, the system SHOULD use a default passcode to wrap the encryption key. If the device provides a hardware-backed keystore, the password stretching algorithm MUST be cryptographically bound to that keystore. The encryption key MUST NOT be sent off the device (even when wrapped with the user passcode and/or hardware bound key). The upstream Android Open Source project provides a preferred implementation of this feature based on the linux kernel feature dm-crypt.

9.10. Проверенная загрузка

Device implementations SHOULD support verified boot for device integrity, and if the feature is supported it MUST declare the platform feature flag android.software.verified_boot. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. The upstream Android Open Source Project provides a preferred implementation of this feature based on the linux kernel feature dm-verity.

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, 108 ] 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 5.0. 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 that 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.

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

However, if the device implementation includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile, the device MUST support Over-the-air download with offline update via reboot.

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.

For device implementations that are launching with Android 5.0 and later, the update mechanism SHOULD support verifying that the system image is binary identical to expected result following an OTA. The block-based OTA implementation in the upstream Android Open Source Project, added since Android 5.0, 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.

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

You can join the android-compatibility forum [Resources, 109 ] and ask for clarifications or bring up any issues that you think the document does not cover.

14. Ресурсы

1. IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt

2. Android Open Source Project: http://source.android.com/

3. Android Television features: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android Watch feature: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API definitions and documentation: http://developer.android.com/reference/packages.html

6. Android Permissions reference: http://developer.android.com/reference/android/Manifest.permission.html

7. android.os.Build reference: http://developer.android.com/reference/android/os/Build.html

8. Android 5.0 allowed version strings: http://source.android.com//docs/compatibility/5.0/versions

9. Telephony Provider: http://developer.android.com/reference/android/provider/Telephony.html

10. Host-based Card Emulation: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. android.webkit.WebView class: http://developer.android.com/reference/android/webkit/WebView.html

13. WebView compatibility: http://www.chromium.org/

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

15. HTML5 offline capabilities: http://dev.w3.org/html5/spec/Overview.html#offline

16. HTML5 video tag: http://dev.w3.org/html5/spec/Overview.html#video

17. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C webstorage API: http://www.w3.org/TR/webstorage/

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

20. Dalvik Executable Format and bytecode specification: available in the Android source code, at dalvik/docs

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

22. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

23. Application Resources: https://developer.android.com/guide/topics/resources/available-resources.html

24. Status Bar icon style guide: http://developer.android.com/design/style/iconography.html

25. Notifications Resources: https://developer.android.com/design/patterns/notifications.html

26. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

27. Toasts: http://developer.android.com/reference/android/widget/Toast.html

28. Themes: http://developer.android.com/guide/topics/ui/themes.html

29. R.style class: http://developer.android.com/reference/android/R.style.html

30. Material design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Live Wallpapers: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Overview screen resources: http://developer.android.com/guide/components/recents.html

33. Screen pinning: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Input methods: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Media Notification: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

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

38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html

40. DevicePolicyManager reference: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. Android Device Owner App:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. Android Accessibility Service APIs: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Android Accessibility APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. Eyes Free project: http://code.google.com/p/eyes-free

45. Text-To-Speech APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. Television Input Framework: /devices/tv/index.html

47. Reference tool documentation (for adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html

48. Android apk file description: http://developer.android.com/guide/components/fundamentals.html

49. Manifest files: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Android Media Formats: http://developer.android.com/guide/appendix/media-formats.html

51. RTC Hardware Coding Requirements: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Android android.content.pm.PackageManager class and Hardware Features List:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Monkey testing tool: http://developer.android.com/tools/help/monkey.html

59. SysyTrace tool: http://developer.android.com/tools/help/systrace.html

60. Android Application Development-Related Settings:

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

61. Supporting Multiple Screens: http://developer.android.com/guide/practices/screens_support.html

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

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Android extension pack for OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Hardware Acceleration: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. EGL Extension-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

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

69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. Touch Input Configuration: http://source.android.com/docs/core/interaction/input/touch-devices

71. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

73. Android Open Source sensors: http://source.android.com/docs/core/interaction/sensors

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

75. Timestamp sensor event: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Android Open Source composite sensors: http://source.android.com/devices/sensors/composite_sensors.html

77. Continuous trigger mode: http://source.android.com/devices/sensors/base_triggers.html#continuous

78. Accelerometer sensor: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

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

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

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

83. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. NDEF Push Protocol: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

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

86. Android NFC Sharing Settings:

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

87. NFC Connection Handover: http://www.nfc-forum.org/specs/spec_list/#conn_handover

88. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. Camera orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

91. Camera: http://developer.android.com/reference/android/hardware/Camera.html

92. Camera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. Camera hardware level: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Camera version support: http://source.android.com/docs/core/camera/versioning

95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

96. Android File Transfer: http://www.android.com/filetransfer

97. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html

98. Android USB Audio: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. USB Battery Charging Specification, Revision 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

100. USB Host API: http://developer.android.com/guide/topics/usb/host.html

101. Wired audio headset: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

102. Android Security and Permissions reference: http://developer.android.com/guide/topics/security/permissions.html

103. UserManager reference: http://developer.android.com/reference/android/os/UserManager.html

104. External Storage reference: http://source.android.com/docs/core/storage

105. External Storage APIs: http://developer.android.com/reference/android/os/Environment.html

106. SMS Short Code: http://en.wikipedia.org/wiki/Short_code

107. Android Open Source Encryption: http://source.android.com/devices/tech/encryption/index.html

108. Android Compatibility Program Overview: http://source.android.com/docs/compatibility

109. Android Compatibility forum: https://groups.google.com/forum/#!forum/android-compatibility

110. WebM project: http://www.webmproject.org/

Many of these resources are derived directly or indirectly from the Android SDK, and will be functionally identical to the information in that SDK's documentation. In any cases where this Compatibility Definition or the Compatibility Test Suite disagrees with the SDK documentation, the SDK documentation is considered authoritative. Any technical details provided in the references included above are considered by inclusion to be part of this Compatibility Definition.