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

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

Оглавление

1. Введение
2. Ресурсы
3. Программное обеспечение
3.1. Совместимость управляемого API
3.2. Совместимость с программным API
3.3. Совместимость с собственным API
3.4. Веб-совместимость
3.5. Поведенческая совместимость API
3.6. Пространства имен API
3.7. Совместимость виртуальных машин
3.8. Совместимость пользовательского интерфейса
4. Совместимость эталонного программного обеспечения
5. Совместимость пакетов приложений
6. Мультимедийная совместимость
7. Совместимость инструментов разработчика
8. Совместимость оборудования
9. Совместимость производительности
10. Совместимость моделей безопасности
11. Набор тестов на совместимость
12. Обновляемое программное обеспечение
13. Свяжитесь с нами
Приложение A. Процедура проверки Bluetooth

1. Введение

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

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

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

Чтобы считаться совместимым с Android 2.2, реализации устройства:

  • ДОЛЖЕН соответствовать требованиям, представленным в данном определении совместимости, включая любые документы, включенные посредством ссылки.
  • ДОЛЖЕН пройти самую последнюю версию пакета тестов на совместимость Android (CTS), доступную на момент завершения внедрения программного обеспечения устройства. (CTS доступен как часть проекта Android с открытым исходным кодом [ Ресурсы, 2 ].) CTS тестирует многие, но не все, компоненты, описанные в этом документе.

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

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.2: http://source.android.com/docs/compatibility/2.2/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. Спецификация виртуальной машины Dalvik: доступна в исходном коде Android по адресу dalvik/docs.
  11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html .
  12. Уведомления: http://developer.android.com/guide/topics/ui/notifiers/notifications.html .
  13. Ресурсы приложения: http://code.google.com/android/reference/available-resources.html .
  14. Руководство по стилю значков строки состояния: http://developer.android.com/guide/practices/ui_guideline/icon_design.html#statusbarstructure.
  15. Менеджер поиска: http://developer.android.com/reference/android/app/SearchManager.html .
  16. Тосты: http://developer.android.com/reference/android/widget/Toast.html .
  17. Живые обои: https://android-developers.googleblog.com/2010/02/live-wallpapers.html .
  18. Приложения для Android: http://code.google.com/p/apps-for-android .
  19. Справочная документация по инструментам (для adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html .
  20. Описание APK-файла Android: http://developer.android.com/guide/topics/fundamentals.html .
  21. Файлы манифеста: http://developer.android.com/guide/topics/manifest/manifest-intro.html .
  22. Инструмент тестирования обезьян: https://developer.android.com/studio/test/other-testing-tools/monkey.
  23. Список функций оборудования Android: http://developer.android.com/reference/android/content/pm/PackageManager.html .
  24. Поддержка нескольких экранов: http://developer.android.com/guide/practices/screens_support.html .
  25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html .
  26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html .
  28. Пространство координат датчика: http://developer.android.com/reference/android/hardware/SensorEvent.html .
  29. Справочник по безопасности и разрешениям Android: http://developer.android.com/guide/topics/security/security.html .
  30. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html .

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

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

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

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

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

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

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

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

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

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

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

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

Параметр Комментарии
android.os.Build.VERSION.RELEASE Версия действующей в данный момент системы Android в удобочитаемом формате. Это поле ДОЛЖНО иметь одно из строковых значений, определенных в [ Resources, 7 ].
android.os.Build.VERSION.SDK Версия текущей системы Android в формате, доступном для кода сторонних приложений. Для Android 2.2 это поле ДОЛЖНО иметь целое значение 8.
android.os.Build.VERSION.INCREMENTAL Значение, выбранное разработчиком устройства, обозначающее конкретную сборку выполняющейся в данный момент системы Android в удобочитаемом формате. Это значение НЕ ДОЛЖНО использоваться повторно для разных сборок, доступных конечным пользователям. Типичное использование этого поля — указать, какой номер сборки или идентификатор изменения системы управления версиями использовался для создания сборки. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.BOARD Значение, выбранное разработчиком устройства, идентифицирующее конкретное внутреннее оборудование, используемое устройством, в удобочитаемом формате. Возможное использование этого поля — указать конкретную версию платы, питающей устройство. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.BRAND Значение, выбранное разработчиком устройства, определяющее название компании, организации, физического лица и т. д., создавшего устройство, в удобочитаемом формате. Это поле можно использовать для указания OEM-производителя и/или оператора связи, продавшего устройство. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.DEVICE Значение, выбранное разработчиком устройства, определяющее конкретную конфигурацию или версию корпуса (иногда называемое «промышленным дизайном») устройства. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.FINGERPRINT Строка, которая однозначно идентифицирует эту сборку. Он ДОЛЖЕН быть достаточно удобочитаемым для человека. Он ДОЛЖЕН следовать этому шаблону:
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Например:
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
Отпечаток НЕ ДОЛЖЕН содержать пробелов. Если другие поля, включенные в приведенный выше шаблон, содержат пробельные символы, их НЕОБХОДИМО заменить в отпечатке сборки другим символом, например символом подчеркивания («_»).
android.os.Build.HOST Строка, однозначно идентифицирующая хост, на котором была построена сборка, в удобочитаемом формате. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.ID Идентификатор, выбранный разработчиком устройства для ссылки на конкретную версию, в удобочитаемом формате. Это поле может быть таким же, как android.os.Build.VERSION.INCREMENTAL, но ДОЛЖНО быть значением, достаточно значимым, чтобы конечные пользователи могли различать сборки программного обеспечения. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.MODEL Значение, выбранное разработчиком устройства, содержащее имя устройства, известное конечному пользователю. Это ДОЛЖНО быть то же имя, под которым устройство продается конечным пользователям. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.PRODUCT Значение, выбранное разработчиком устройства, содержащее имя разработки или кодовое имя устройства. ДОЛЖЕН быть удобочитаемым, но не обязательно предназначен для просмотра конечными пользователями. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").
android.os.Build.TAGS Разделенный запятыми список тегов, выбранных разработчиком устройства, которые дополнительно различают сборку. Например, «без знака, отладка». Это поле НЕ ДОЛЖНО быть нулевым или содержать пустую строку (""), но достаточно одного тега (например, "release").
android.os.Build.TIME Значение, представляющее отметку времени, когда произошла сборка.
android.os.Build.TYPE Значение, выбранное разработчиком устройства, определяющее конфигурацию сборки во время выполнения. Это поле ДОЛЖНО иметь одно из значений, соответствующих трем типичным конфигурациям среды выполнения Android: «user», «userdebug» или «eng».
android.os.Build.USER Имя или идентификатор пользователя (или автоматического пользователя), создавшего сборку. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").

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

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

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

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

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

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

  • Настольные часы
  • Браузер
  • Календарь
  • Калькулятор
  • Камера
  • Контакты
  • Электронная почта
  • Галерея
  • Глобальный поиск
  • пусковая установка
  • LivePicker (то есть приложение для выбора живых обоев; МОЖЕТ быть опущено, если устройство не поддерживает живые обои, согласно разделу 3.8.5.)
  • Обмен сообщениями (также известный как «Mms»)
  • Музыка
  • Телефон
  • Настройки
  • Диктофон

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

  • libc (библиотека C)
  • libm (математическая библиотека)
  • JNI-интерфейс
  • libz (сжатие Zlib)
  • liblog (ведение журнала Android)
  • Минимальная поддержка C++.
  • Поддержка OpenGL, как описано ниже.

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

Эти библиотеки ДОЛЖНЫ быть совместимыми по исходному коду (т. е. совместимыми по заголовку) и двоично-совместимыми (для данной архитектуры процессора) с версиями, предоставляемыми в Bionic проектом Android с открытым исходным кодом. Поскольку реализации Bionic не полностью совместимы с другими реализациями, такими как библиотека GNU C, разработчики устройств ДОЛЖНЫ использовать реализацию Android. Если разработчики устройств используют другую реализацию этих библиотек, они ДОЛЖНЫ обеспечить совместимость заголовков, двоичных файлов и поведения.

Реализации устройства ДОЛЖНЫ точно сообщать о собственном двоичном интерфейсе приложения (ABI), поддерживаемом устройством, через API android.os.Build.CPU_ABI . ABI ДОЛЖЕН быть одной из записей, задокументированных в последней версии Android NDK, в файле docs/CPU-ARCH-ABIS.txt . Обратите внимание, что в дополнительных выпусках Android NDK может появиться поддержка дополнительных 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.2. Эта сборка включает определенный набор исправлений функциональности и безопасности для 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, кэша приложений и API геолокации [ Ресурсы, 9 ]. WebView ДОЛЖЕН включать поддержку тега HTML5 <video> . API-интерфейсы HTML5, как и все API-интерфейсы JavaScript, ДОЛЖНЫ быть отключены по умолчанию в WebView, если только разработчик явно не включит их через обычные API-интерфейсы Android.

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

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

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

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

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

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

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

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

Набор тестов совместимости (CTS) проверяет значительные части платформы на поведенческую совместимость, но не все. Разработчик несет ответственность за обеспечение поведенческой совместимости с проектом 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 или добавления нового API), разработчик ДОЛЖЕН посетить source.android.com и начать процесс внесения изменений и код, согласно информации на этом сайте.

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

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

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

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

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

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

3.8.1. Виджеты

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

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

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

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

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

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

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

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

3.8.4. Тосты

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

3.8.5. Живые обои

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

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

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

4. Совместимость эталонного программного обеспечения

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

  • Калькулятор (включен в SDK)
  • Лунный посадочный модуль (включен в SDK)
  • Приложения «Приложения для Android» [ Ресурсы, 18 ].
  • Остров реплик (доступен на Android Market; требуется только для реализаций устройств, поддерживающих OpenGL ES 2.0)

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

Кроме того, реализации устройства ДОЛЖНЫ тестировать каждый пункт меню (включая все подменю) каждого из этих приложений дымового тестирования:

  • ApiDemos (включен в SDK)
  • ManualSmokeTests (входит в CTS)

Каждый тестовый пример в приведенных выше приложениях ДОЛЖЕН корректно выполняться на реализации устройства.

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

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

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

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

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

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

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

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

Аудио
Имя Кодер Декодер Подробности Формат файла/контейнера
AAC LC/LTP Икс Содержание моно/стерео в любой комбинации стандартных скоростей битов до 160 кбит/с и скорости отбора проб от 8 до 48 кГц 3GPP (.3GP) и MPEG-4 (.mp4, .m4a). Нет поддержки сырого AAC (.AAC)
HE-AACV1 (AAC+) Икс
HE-AACV2 (усиление AAC+) Икс
AMR-NB Икс Икс От 4,75 до 12,2 кбит / с. 3gpp (.3gp)
AMR-WB Икс 9 ставок от 6,60 кбит/с до 23,85 кбит/с. Обработанные при 16 кГц 3gpp (.3gp)
МП3 Икс Mono/Stereo 8-320 кбит/с. Mp3 (.mp3)
МИДИ Икс MIDI Тип 0 и 1. DLS версия 1 и 2. XMF и мобильный XMF. Поддержка форматов рингтона RTTTL/RTX, OTA и Imelody Тип 0 и 1 (.mid, .xmf, .mxmf). Также rtttl/rtx (.rtttl, .rtx), Ota (.ota) и Imelody (.imy)
Огг Ворбис Икс Ogg (.ogg)
PCM Икс 8- и 16-битный линейный PCM (оценки до предела аппаратного обеспечения) Волна (.wav)
Изображение
JPEG Икс Икс база+прогрессивный
гифка Икс
PNG Икс Икс
BMP Икс
видео
H.263 Икс Икс Файлы 3GPP (.3gp)
H.264 Икс Файлы 3GPP (.3gp) и MPEG-4 (.mp4)
MPEG4 простой профиль Икс Файл 3GPP (.3gp)

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

6.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.2, определение совместимости для будущей версии планируется изменить их на «Должен». То есть эти требования являются необязательными в Android 2.2, но потребуются будущей версией. Существующие и новые устройства, которые запускают Android 2.2 Android , очень настоятельно рекомендуются соответствовать этим требованиям в Android 2.2 , или они не смогут достичь совместимости Android при обновлении до будущей версии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. Отображать

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

Для Android 2.2 это наиболее распространенные конфигурации дисплея:

Тип экрана Ширина (пиксели) Высота (пиксели) Диагональный диапазон длины (дюймы) Группа размера экрана Группа плотности экрана
QVGA 240 320 2.6 - 3.0 Маленький Низкий
WQVGA 240 400 3.2 - 3.5 Нормальный Низкий
FWQVGA 240 432 3.5 - 3.8 Нормальный Низкий
HVGA 320 480 3.0 - 3.5 Нормальный Середина
WVGA 480 800 3.3 - 4.0 Нормальный Высокий
FWVGA 480 854 3.5 - 4,0 Нормальный Высокий
WVGA 480 800 4.8 - 5,5 Большой Середина
FWVGA 480 854 5.0 - 5.8 Большой Середина

Реализации устройств, соответствующие одной из стандартных конфигураций, приведенных выше, должны быть настроены, чтобы сообщить указанный размер экрана в приложениях через android.content.res.Configuration [ Resources, 24 ].

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

  • Реализации устройств должны интерпретировать ресурсы в .PK, в котором отсутствует квалификатор плотности в качестве дефолта «среды» (известный как «MDPI» в документации SDK.)
  • При работе на «низкой» экране плотности реализации устройства должны сокращать средние/MDPI активы в 0,75.
  • При работе на «высокой» экране плотности реализации устройств должны увеличить средние/MDPI активы в 1,5.
  • Реализации устройства не должны масштабироваться активами в диапазоне плотности и должны масштабироваться активы именно этими факторами между диапазонами плотности.

8.1.2. Нестандартные конфигурации дисплея

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.5. Ввод сенсорного экрана

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

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

8.6. USB

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

  • Необходимо реализовать USB-клиент, подключаемый к USB-хосту со стандартным портом USB-A
  • Должен реализовать мост отладки Android через USB (как описано в разделе 7)
  • Необходимо реализовать спецификацию массового хранения USB, чтобы дать хосту, подключенному к устройству, доступ к содержимому объема /SDCARD
  • Следует использовать форм -фактор Micro USB на стороне устройства
  • Может включать нестандартный порт на стороне устройства, но если это так, если это так, чтобы поставить с помощью кабеля, способного подключить пользовательскую рутинную расписание к стандартному порту USB-A
  • Следует реализовать поддержку спецификации массового хранения USB (так что можно получить либо съемное, либо фиксированное хранилище на устройстве с хост -ПК)

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

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

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

8.8. Беспроводная сеть данных

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

Если реализация устройства включает в себя конкретную модальность, для которой Android SDK включает API (то есть WiFi, GSM или CDMA), реализация должна поддерживать API.

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

8.9. Камера

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

  • Должен иметь разрешение не менее 2 мегапикселей
  • Должен иметь либо аппаратный автофокус, либо программный автомат, реализованный в драйвере камеры (прозрачный для прикладного программного обеспечения)
  • Может иметь аппаратное обеспечение с фиксированным фокусом или эдофом (расширенная глубина полета)
  • Может включать вспышку. Если камера включает в себя вспышку, флэш -лампа не должна быть зажжена, в то время как на поверхности предварительного просмотра камеры android.hardware.camera.previewCallback на поверхности предварительного просмотра камеры, если приложение явно не включило FLASH_MODE_AUTO FLASH_MODE_ON Camera.Parameters Object. Обратите внимание, что это ограничение применяется не к встроенному приложению системной камеры устройства, а только к сторонним приложениям с использованием Camera.PreviewCallback .

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

  1. Если приложение никогда не вызывало android.hardware.camera.parameters.setpreviewformat (int), то устройство должно использовать Android.hardware.pixelformat.ycbcr_420_SP для предварительного просмотра данных, предоставленных для приложений.
  2. Если приложение регистрирует экземпляр Android.hardware.camera.previewCallback, и система вызывает метод OnPreviewFrame (), когда формат предварительного просмотра является YCBCR_420_SP, данные в формате BYTE [], передаваемые в OnPreviewFrame (), должны быть в формате Encoding NV21. (Это формат, используемый изначально в семействе оборудования 7K.) То есть NV21 должен быть по умолчанию.

Реализации устройств должны реализовать полный API камеры, включенный в документацию Android 2.2 SDK [ Resources, 27 ]), независимо от того, включает ли устройство аппаратное автофокус или другие возможности. Например, камеры, в которых не хватает автофокуса, все равно должны вызывать любые зарегистрированные экземпляры android.hardware.Camera.AutoFocusCallback .

Реализации устройств должны распознавать и чтить каждое имя параметра, определенное как постоянное в классе android.hardware.Camera.Parameters , если базовое оборудование поддерживает эту функцию. Если аппаратное обеспечение устройства не поддерживает функцию, API должен вести себя как задокументированное. И наоборот, реализации устройств не должны соблюдать или распознавать констант строковых, передаваемые методу android.hardware.Camera.setParameters() , отличный от тех, которые документированы как константы на android.hardware.Camera.Parameters . То есть реализации устройств должны поддерживать все стандартные параметры камеры, если оборудование позволяет, и не должно поддерживать пользовательские типы параметров камеры.

Реализации устройства могут включать фронтальную камеру. Однако, если реализация устройства включает в себя фронтальную камеру, API камеры, реализованный на устройстве, не должен использовать фронтальную камеру по умолчанию. То есть API камеры в Android 2.2 предназначен только для камер, обращенных к задней части, и реализации устройств не должны повторно использовать или перегружать API, чтобы действовать на фронтальную камеру, если он присутствует. Обратите внимание, что любые пользовательские API, добавленные реализаторами устройства для поддержки фронтальных камер, должны соблюдать разделы 3.5 и 3.6; Например, если пользовательский подкласс android.hardware.Camera или Camera.Parameters предоставляется для поддержки фронтальных камер, он не должен быть расположен в существующем пространстве имен, как описано в разделах 3.5 и 3.6. Обратите внимание, что включение фронтальной камеры не соответствует требованиям, чтобы устройства включали камеру, обращенную к задней части.

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

Реализации устройства должны включать 3-осевой акселерометр и должны иметь возможность доставлять события при 50 Гц или более. Система координат, используемая акселерометром, должна соответствовать системе координат датчика Android, как подробно описано в API APIS Android (см. [ Ресурсы, 28 ]).

8.11. Компас

Реализации устройства должны включать 3-осевой компас и должны иметь возможность доставлять события 10 Гц или более. Система координат, используемая компасом, должна соответствовать системе координат датчика Android, как это определено в API Android (см. [ Ресурсы, 28 ]).

8.12. GPS

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

8.13. Телефония

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

См. Также раздел 8.8, беспроводная сеть данных.

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

Реализации устройств должны иметь не менее 92 МБ памяти, доступной для ядра и пользователя. 92 МБ должны быть в дополнение к любой памяти, посвященной аппаратным компонентам, таким как радио, память и т. Д., Это не находится под управлением ядра.

Реализации устройств должны иметь не менее 150 МБ нелетую хранилища для пользовательских данных. То есть раздел /data должен быть не менее 150 МБ.

Помимо приведенных выше требований, реализации устройств должны иметь не менее 128 МБ памяти, доступной для ядра и пользователя, в дополнение к любой памяти, посвященной аппаратным компонентам, которая не находится под управлением ядра. Реализации устройств должны иметь не менее 1 ГБ нелетую памяти для пользовательских данных. Обратите внимание, что эти более высокие требования планируются стать жесткими минимумами в будущей версии Android. Реализации устройств настоятельно рекомендуется соответствовать этим требованиям сейчас, иначе они могут не иметь права на совместимость для будущей версии Android.

8.15. Приложение общее хранилище

Реализации устройств должны предлагать общее хранилище для приложений. Предоставленное общее хранилище должно быть не менее 2 ГБ в размере.

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

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

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

Независимо от формы используемого общего хранилища, общее хранилище должно реализовать USB Mass Storage, как описано в разделе 8.6. Как отправлено из коробки, общее хранилище должно быть установлено с помощью жирной файловой системы.

Это иллюстрирует, чтобы рассмотреть два общих примера. Если реализация устройства включает в себя слот SD-карты для удовлетворения требований общего хранения, жирная SD-карта размером 2 ГБ должна быть включена в устройство, которое продается пользователям, и должна быть установлена ​​по умолчанию. В качестве альтернативы, если реализация устройства использует внутреннее фиксированное хранилище для удовлетворения этого требования, это хранилище должно быть размером 2 ГБ или больше, отформатировано в виде жира, и установлено на /sdcard (или /sdcard быть символической связью с физическим место установлен в другом месте.)

Реализации устройств, которые включают несколько путей общего хранения (например, как слот SD -карты, так и общее внутреннее хранилище), должны изменить основные приложения, такие как Сканер СМИ и ContentProvider, для прозрачной поддержки файлов, размещенных в обоих местах.

8.16. Bluetooth

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

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

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

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

Метрика Порог производительности Комментарии
Время запуска приложения Следующие приложения должны запустить в течение указанного времени.
  • Браузер: менее 1300 мс
  • MMS/SMS: менее 700 мс
  • Тревога: менее 650 мс
 Время запуска измеряется как общее время для завершения загрузки активности по умолчанию для приложения, включая время, необходимое для запуска процесса Linux, загрузить пакет Android в VM Dalvik и вызовать Oncreate.
Одновременные приложения Когда было запущено несколько приложений, повторное запуск уже запускающегося приложения после его запуска должно занять меньше, чем в оригинальном времени запуска.

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

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

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

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

10.2. Изоляция UID и процесса

Реализации устройств должны поддерживать модель песочницы Android приложения, в которой каждое приложение работает как уникальный UID в стиле UNIX и в отдельном процессе. Реализации устройств должны поддерживать запуск нескольких приложений, что и тот же идентификатор пользователя Linux, при условии, что приложения соответствуют и построены, как определено в ссылке на безопасность и разрешения [ Resources, 29 ].

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

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

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

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

Альтернативные время выполнения должны быть приложениями для Android и соблюдать стандартную модель безопасности Android, как описано в другом месте в разделе 10.

Альтернативное время выполнения не должно быть предоставлено доступом к ресурсам, защищенным разрешениями, не запрашиваемыми в файле AndroidManifest.xml от среды выполнения через механизм <uses-permission> .

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

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

  • Альтернативные время выполнения должны установить приложения через PackageManager в отдельные песочницы Android (то есть идентификаторы пользователей Linux и т. Д.)
  • Альтернативные время выполнения могут предоставить одну песочницу Android, общую все приложения, используя альтернативное время выполнения.
  • Альтернативные время выполнения и установленные приложения с использованием альтернативного времени выполнения не должны повторно использовать песочницу любого другого приложения, установленного на устройстве, за исключением стандартных механизмов Android общего идентификатора пользователя и сертификата подписи
  • Альтернативные время выполнения не должны запускаться, предоставлять или предоставлять доступ к песочнице, соответствующим другим приложениям Android.

Альтернативные время выполнения не должны быть запущены, быть предоставлены или предоставлять другие приложения любые привилегии суперпользователя (root) или любого другого идентификатора пользователя.

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

При установке приложений альтернативное время выполнения должно получить согласие пользователя на разрешения Android, используемые приложением. То есть, если приложению необходимо использовать ресурс устройства, для которого существует соответствующее разрешение на андроид (например, камера, GPS и т. Д.), Альтернативное время выполнения должно сообщить пользователю, что приложение сможет получить доступ к этому ресурсу . Если среда выполнения не записывает возможности приложений таким образом, среда выполнения должна перечислить все разрешения, удерживаемые самой средой выполнения при установке любого приложения, используя это время выполнения.

11. Набор тестов на совместимость

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

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

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

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

Любой метод может быть использован при условии, что он может заменить полную программу, предварительно установленную на устройстве. Например, любой из следующих подходов удовлетворит это требование:

  • Загрузка Over-Air (OTA) с обновлением в автономном режиме через перезагрузку
  • «Привязанные» обновления по USB с хост -ПК
  • «Офлайн» обновления через перезагрузку и обновление из файла на съемном хранилище

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

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

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

Вы можете связаться с авторами документов по адресу compatibility@android.com для разъяснений и поднять любые проблемы, которые, по вашему мнению, документ не охватывает.

Приложение A - процедура тестирования Bluetooth

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

Процедура тестирования основана на приложении BluetoothHat Sample, включенном в дерево проекта с открытым исходным кодом Android. Процедура требует двух устройств:

  • 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.

Setup and Installation

  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.