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

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

Оглавление

1. Введение

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

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

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

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

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

Обратите внимание, что это определение совместимости выпущено в соответствии с обновлением 2.3.3 для Android, которое соответствует уровню API 10. Это определение устарело и заменяет определение совместимости для версий Android 2.3, предшествующих 2.3.3. (То есть версии 2.3.1 и 2.3.2 устарели.) Будущие Android-совместимые устройства под управлением Android 2.3 ДОЛЖНЫ поставляться с версией 2.3.3 или новее.

2. Ресурсы

1. Уровни требований IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. Обзор программы совместимости Android: http://source.android.com/docs/compatibility/index.html .
3. Проект Android с открытым исходным кодом: http://source.android.com/
4. Определения API и документация: http://developer.android.com/reference/packages.html .
5. Ссылка на разрешения Android: http://developer.android.com/reference/android/Manifest.permission.html .
6. Ссылка на android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Строки разрешенной версии Android 2.3: http://source.android.com/docs/compatibility/2.3/versions.html .
8. Класс android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Автономные возможности HTML5: http://dev.w3.org/html5/spec/Overview.html#offline .
11. Тег видео HTML5: http://dev.w3.org/html5/spec/Overview.html#video .
12. API геолокации HTML5/W3C: http://www.w3.org/TR/geolocation-API/
13. API веб-базы данных HTML5/W3C: http://www.w3.org/TR/webdatabase/
14. API HTML5/W3C IndexedDB: http://www.w3.org/TR/IndexedDB/
15. Спецификация виртуальной машины Dalvik: доступна в исходном коде Android по адресу dalvik/docs.
16. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html .
17. Уведомления: http://developer.android.com/guide/topics/ui/notifiers/notifications.html .
18. Ресурсы приложения: http://code.google.com/android/reference/available-resources.html .
19. Руководство по стилю значков строки состояния: http://developer.android.com/guide/practices/ui_guideline/icon_design.html#statusbarstructure.
20. Менеджер поиска: http://developer.android.com/reference/android/app/SearchManager.html .
21. Тосты: http://developer.android.com/reference/android/widget/Toast.html .
22. Живые обои: https://android-developers.googleblog.com/2010/02/live-wallpapers.html .
23. Справочная документация по инструментам (для adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html .
24. Описание APK-файла Android: http://developer.android.com/guide/topics/fundamentals.html .
25. Файлы манифеста: http://developer.android.com/guide/topics/manifest/manifest-intro.html .
26. Инструмент тестирования обезьян: https://developer.android.com/studio/test/other-testing-tools/monkey.
27. Список функций оборудования Android: http://developer.android.com/reference/android/content/pm/PackageManager.html .
28. Поддержка нескольких экранов: http://developer.android.com/guide/practices/screens_support.html .
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html .
31. Пространство координат датчика: http://developer.android.com/reference/android/hardware/SensorEvent.html .
32. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html .
33. Протокол Push NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. API ориентации камеры: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html .
42. Справочник по безопасности и разрешениям Android: http://developer.android.com/guide/topics/security/security.html .
43. Приложения для Android: http://code.google.com/p/apps-for-android .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Многие разработчики и приложения полагаются на поведение класса android.webkit.WebView [ Resources, 8 ] для своих пользовательских интерфейсов, поэтому реализация WebView должна быть совместима со всеми реализациями Android. Точно так же полноценный современный веб-браузер играет центральную роль в пользовательском опыте Android. Реализации устройства ДОЛЖНЫ включать версию android.webkit.WebView , соответствующую исходному программному обеспечению Android, и ДОЛЖНЫ включать современный браузер с поддержкой HTML5, как описано ниже.

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

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

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

Компонент WebView ДОЛЖЕН включать поддержку как можно большей части HTML5 [ Resources, 9 ]. Как минимум, реализации устройств ДОЛЖНЫ поддерживать каждый из этих API, связанных с HTML5 в WebView:

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

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

API-интерфейсы HTML5, как и все API-интерфейсы JavaScript, ДОЛЖНЫ быть отключены по умолчанию в WebView, если только разработчик явно не включит их через обычные API-интерфейсы Android.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализации устройств с экранами, классифицированными как средняя или низкая плотность, ДОЛЖНЫ настроить Dalvik для выделения не менее 16 МБ памяти для каждого приложения. Реализации устройств с экранами, классифицированными как высокая или сверхвысокая плотность, ДОЛЖНЫ настроить Dalvik на выделение не менее 24 МБ памяти для каждого приложения. Обратите внимание, что реализации устройства МОГУТ выделять больше памяти, чем указано в этих цифрах.

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

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

3.8.1. Виджеты

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

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

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

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

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

3.8.3. Поиск

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

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

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

3.8.4. тосты

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

3.8.5. Живые обои

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

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

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

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

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

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

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

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

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

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

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

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

5.1.1. Медиа-декодеры

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

5.1.2. Медиа -кодеры

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

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

В дополнение к перечисленным выше энкодерам, реализации устройств должны включать энкодер H.264. Обратите внимание, что определение совместимости для будущей версии планируется изменить это требование на «Должен». То есть кодирование H.264 является необязательным в Android 2.3, но потребуется будущей версией. Существующие и новые устройства, которые запускают Android 2.3 , очень настоятельно рекомендуются удовлетворить это требование в Android 2.3 , или они не смогут достичь совместимости Android при обновлении до будущей версии.

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

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

• Обработка шума, если она присутствует, должна быть отключена.
• Автоматическое управление усилением, если он присутствует, должен быть отключен.
• Устройство должно демонстрировать приблизительно плоскую амплитуду в зависимости от частотных характеристик; В частности, ± 3 дБ, от 100 Гц до 4000 Гц
• Аудио входная чувствительность должна быть установлена ​​так, чтобы источник уровня звука 90 дБ (SPL) при 1000 Гц дает среднеквадратичную среду 5000 для 16-битных образцов.
• Уровни амплитуды PCM должны линейно отслеживать входные изменения SPL, по крайней мере, в диапазоне 30 дБ от -18 дБ до +12 дБ Re 90 дБ на микрофоне.
• Общее гармоническое искажение должно составлять менее 1% от 100 Гц до 4000 Гц при входном уровне SPL 90 дБ.

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

5.3. Аудио задержка

Аудиозадерживание широко определяется как интервал между применением запрашивает воспроизведение аудио или операцию записи, и когда реализация устройства фактически начинает работу. Многие классы приложений полагаются на короткие задержки, чтобы достичь эффектов в реальном времени, таких как звуковые эффекты или общение VoIP. Реализации устройств, которые включают в себя аппаратное обеспечение микрофона и объявлять android.hardware.microphone , должны соответствовать всем требованиям задержки звука, изложенными в этом разделе. См. Раздел 7 для получения подробной информации о условиях, при которых аппаратное обеспечение микрофона может быть опущено реализациями устройств.

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

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

Используя приведенные выше определения, реализации устройств должны демонстрировать каждое из этих свойств:

• Холодная выходная задержка 100 миллисекунд или менее
• Задержка теплого выхода в 10 миллисекунд или менее
• Непрерывная задержка выходной продукции 45 миллисекунд или менее
• задержка холода 100 миллисекунд или менее
• непрерывная задержка ввода 50 миллисекунд или менее

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

Если реализация устройства соответствует требованиям этого раздела, оно может сообщать о поддержке аудио с низкой задержкой, сообщив о функции «Android.hardware.Audio.low-Latency» через класс android.content.pm.PackageManager . [ Ресурсы, 27 ] Наоборот, если реализация устройства не соответствует этим требованиям, она не должна сообщать о поддержке аудио с низкой задержкой.

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

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

• Android Debug Bridge (известный как ADB) [ Resources, 23 ]
  Реализации устройств должны поддерживать все функции adb , как задокументировано в Android SDK. Демон adb на стороне устройства должен быть неактивным по умолчанию, но должен быть доступный пользователь механизм для включения моста отладки Android.
• Dalvik Debug Monitor Service (известный как DDMS) [ Resources, 23 ]
  Реализации устройств должны поддерживать все функции ddms , как задокументировано в Android SDK. Поскольку ddms использует adb , поддержка ddms должна быть неактивной по умолчанию, но должна поддерживаться всякий раз, когда пользователь активирует мост отладки Android, как указано выше.
• Обезьяна [ Ресурсы, 26 ]
  Реализации устройства должны включать в себя структуру обезьяны и сделать ее доступным для использования приложений.

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

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

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

Если устройство включает в себя конкретный аппаратный компонент, который имеет соответствующий 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 . [ Ресурсы, 27 ]

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

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

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

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

• Экраны должны быть не менее 2,5 дюймов в физическом диагональном размере
• Плотность должна быть не менее 100 DPI
• Соотношение сторон должно быть между 1,333 (4: 3) до 1,779 (16: 9)
• Используемая технология дисплея состоит из квадратных пикселей

Реализации устройств с экраном встречи Приведенные выше требования считаются совместимыми, и никаких дополнительных действий не требуется. Реализация Android Framework автоматически вычисляет характеристики отображения, такие как ведро размера экрана и ведро плотности. В большинстве случаев рамочные решения являются правильными. Если используются платтные вычисления по умолчанию, никаких дополнительных действий не требуется. Реалисты устройств, желающие изменить по умолчанию или использовать экран, который не соответствует приведенным выше требованиям, должны связаться с командой совместимости Android для руководства, как предусмотрено в разделе 12.

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

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

Реализации устройства должны использовать только отображения с одной статической конфигурацией. То есть реализации устройств не должны включать несколько конфигураций экрана. Например, поскольку типичное телевидение поддерживает множество разрешений, таких как 1080p, 720p и т. Д., Эта конфигурация не совместима с Android 2.3. (Однако поддержка таких конфигураций находится под следствием и планируется для будущей версии Android.)

7.1.2. Показать метрики

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

7.1.3. Объявленная поддержка экрана

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

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

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

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

7.1.5. 3D графическая ускорение

Реализации устройств должны поддерживать OpenGL ES 1.0, как того требует API Android 2.3. Для устройств, у которых отсутствует 3D-аппаратное обеспечение ускорения, программная реализация OpenGL ES 1.0 обеспечивается проектом Upstream Android с открытым исходным кодом. Реализации устройства должны поддерживать OpenGL ES 2.0.

Реализации могут опустить открытую поддержку GL ES 2.0; Однако, если поддержка опущена, реализации устройств не должны сообщать о поддержке OpenGL ES 2.0. В частности, если в реализации устройства не хватает поддержки OpenGL ES 2.0:

• Управляемые API (например, метод GLES10.getString() не должны сообщать о поддержке для OpenGL ES 2.0
• Нативные API C/C ++ OpenGL (то есть те, которые доступны для приложений через libles_v1cm.so, libles_v2.so или libegl.so) не должны сообщать о поддержке OpenGL ES 2.0.

И наоборот, если реализация устройства поддерживает OpenGL ES 2.0, она должна точно сообщить о том, что поддержка через только что перечисленные маршруты.

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

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

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

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

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

• Должен включить поддержку платформы управления входами (которая позволяет сторонним разработчикам создавать двигатели управления вводами - т.е. мягкая клавиатура), как подробно описано на Developer.android.com
• Должен предоставить хотя бы одну реализацию мягкой клавиатуры (независимо от того, присутствует ли жесткая клавиатура)
• Может включать дополнительные реализации мягкой клавиатуры
• Может включать аппаратную клавиатуру
• Не должен включать аппаратную клавиатуру, которая не соответствует одному из форматов, указанных в android.content.res.Configuration.keyboard [ Resources, 30 ] (то есть Qwerty или 12-ключ)

7.2.2. Не касательная навигация

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

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

7.2.3. Клавиши навигации

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

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

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

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

• Должен иметь сенсорный экран
• Может иметь либо емкостный или резистивный сенсорный экран
• Должен сообщить о значении android.content.res.Configuration [ Resources, 30 ], отражая соответствующий типу конкретного сенсорного экрана на устройстве
• Следует поддерживать полностью независимо отслеживаемые указатели, если сенсорный экран поддерживает несколько указателей

7.3. Датчики

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

• Должен точно сообщить о наличии или отсутствии датчиков на класс android.content.pm.PackageManager . [ Ресурсы, 27 ]
• Должен вернуть точный список поддерживаемых датчиков через SensorManager.getSensorList() и аналогичные методы
• Должен вести себя разумно для всех других датчиков (например, возвращая True или False в зависимости от необходимости, когда приложения пытаются зарегистрировать слушателей, не вызывая слушателей датчиков, когда соответствующие датчики не присутствуют; и т. Д.)

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

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

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

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

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

• Должен быть в состоянии проводить мероприятия при 50 Гц или более
• Должен соблюдать систему координат датчика Android, как подробно описано в API API Android (см. [ Resources, 31 ])
• Должен быть способен измерять от свободного падения до дважды тяжести (2 г) или более на любом трехмерном векторе
• Должен иметь 8-битный точность или больше
• Должен иметь стандартное отклонение не больше 0,05 м/с^2

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

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

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

7.3.3. GPS

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

7.3.4. Гироскоп

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

• Должен быть способен измерять изменение ориентации до 5,5*Радиан PI/секунду (то есть приблизительно 1000 градусов в секунду)
• Должен быть в состоянии проводить мероприятия при 100 Гц или более
• Должен иметь 8-битный точность или больше

7.3.5. Барометр

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

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

7.3.7. Термометр

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

7.3.7. Фотометр

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

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

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

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

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

7.4.1. Телефония

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

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

7.4.2. IEEE 802.11 (Wi -Fi)

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

7.4.3. Bluetooth

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

Набор тестов на совместимость включает в себя случаи, которые охватывают базовую работу API Bluetooth API Android RFCOMM. Однако, поскольку Bluetooth является протоколом связи между устройствами, он не может быть полностью протестирован с помощью модульных тестов, работающих на одном устройстве. Следовательно, реализации устройства также должны пройти процедуру теста на Bluetooth, управляемую человеком, описанную в Приложении A.

7.4.4. Связанное общение

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

• Должен сообщить о функции Android.hardware.nfc из метода android.content.pm.PackageManager.hasSystemFeature() . [ Ресурсы, 27 ]
• Должен быть способен читать и писать сообщения NDEF через следующие стандарты NFC:
  • Должен быть способен выступать в качестве читателя/писателя Forum Forum NFC (как определено технической спецификацией NFC Forum NFCFORUM-TS-DigitalProtocol-1.0) через следующие стандарты NFC:
    • NFCA (ISO14443-3A)
    • NFCB (ISO14443-3B)
    • NFCF (JIS 6319-4)
    • NFCV (ISO 15693)
    • Isodep (ISO 14443-4)
    • Типы тегов форума NFC 1, 2, 3, 4 (определено форумом NFC)
  • Должен быть способен передавать и получать данные с помощью следующих одноранговых стандартов и протоколов:
    • ISO 18092
    • LLCP 1.0 (определяется форумом NFC)
    • SDP 1.0 (определяется форумом NFC)
    • NDEF Push Protocol [ Resources, 33 ]
  • Необходимо сканировать на все поддерживаемые технологии, находясь в режиме NFC Discovery.
  • Должен быть в режиме обнаружения NFC, пока устройство бодрствует с активным экраном.

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

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

  • Mifare Classic (NXP MF1S503X [ Resources, 34 ], MF1S703X [ Resources, 35 ])
  • Mifare Ultralight (NXP MF0ICU1 [ Resources, 36 ], MF0ICU2 [ Resources, 37 ])
  • NDEF ON MIFARE CLASSIC (NXP AN130511 [ Resources, 38 ], AN130411 [ Resources, 39 ])

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

  • Должен реализовать соответствующие API Android, как задокументировано Android SDK
  • Должен сообщить о функции com.nxp.mifare из метода android.content.pm.PackageManager.hasSystemFeature() . [ Ресурсы, 27 ] Обратите внимание, что это не стандартная функция Android, и поэтому не появляется как постоянная в классе PackageManager .
  • Не должен реализовать соответствующие API API Android и сообщать о функции com.nxp.mifare, если это также не реализует общую поддержку NFC, как описано в этом разделе

  Если реализация устройства не включает в себя аппаратное обеспечение NFC, она не должна объявлять функцию Android.hardware.nfc из android.content.pm.PackageManager.hasSystemFeature() Метод [ ресурсы, 27 ], и должен реализовать Android 2.3 NFC API как no-op.

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

  7.4.5. Минимальная сеть

  Реализации устройства должны включать поддержку одной или нескольких форм сети данных. В частности, реализации устройств должны включать поддержку хотя бы одного стандарта данных, способного составлять 200 кбит/с или более. Примеры технологий, которые удовлетворяют этим требованиям, включают Edge, HSPA, EV-DO, 802.11g, Ethernet и т. Д.

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

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

  7.5. Камеры

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

  7.5.1. Сзади камера

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

  • Должен иметь разрешение не менее 2 мегапикселей
  • Должен иметь либо аппаратный автофокус, либо программный автомат, реализованный в драйвере камеры (прозрачный для прикладного программного обеспечения)
  • Может иметь аппаратное обеспечение с фиксированным фокусом или эдофом (расширенная глубина полета)
  • Может включать вспышку. 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 a front-facing camera, it:

  • MUST have a resolution of at least VGA (that is, 640x480 pixels)
  • MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android 2.3 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 Устройство.
  • 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, 40 ] 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 data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, 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. Camera API Behavior

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

  1. 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.
  2. 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.
  3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

  Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), 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.

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

  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, a 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. Память и хранение

  The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

  7.6.1. Minimum Memory and Storage

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

  Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

  Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

  The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

  7.6.2. Application Shared Storage

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

  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 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 MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

  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 or Media Transfer Protocol.

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

  Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

  7.7. USB

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

  • MUST implement a USB client, connectable to a USB host with a standard USB-A port
  • MUST implement the Android Debug Bridge over USB (as described in Section 7)
  • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
  • SHOULD use the micro USB form factor on the device side
  • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

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

  Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

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

  9. Security Model Compatibility

  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, 42 ] 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 sub-sections.

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

  Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. 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 and Process Isolation

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

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

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

  9.4. Alternate Execution Environments

  Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine 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 <uses-permission> mechanism.

  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. Конкретно:

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

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

  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. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . 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.

  10. Software Compatibility Testing

  The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. 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 2.3 available from the Android Open-Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

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

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

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

  MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

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

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

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

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

  10.3. Справочные приложения

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

  • The "Apps for Android" applications [ Resources, 43 ].
  • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

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

  11. Updatable Software

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

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

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

  The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

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

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

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

  Appendix A - Bluetooth Test Procedure

  The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

  The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

  The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

  Настройка и установка

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

  Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

  Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

  Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

  Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

  Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.