Определение совместимости с 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 с открытым исходным кодом [ Ресурсы, 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/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/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. Живые обои: http://developer.android.com/resources/articles/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. Инструмент тестирования Monkey: http://developer.android.com/guide/developing/tools/monkey.html .
  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 .

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

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

Платформа Android включает в себя набор управляемых 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 в удобочитаемом формате. Это поле ДОЛЖНО иметь одно из строковых значений, определенных в [ Ресурсы, 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 Разделенный запятыми список тегов, выбранных разработчиком устройства, которые дополнительно отличают сборку. Например, «без знака, отладка». Это поле НЕ ДОЛЖНО быть нулевым или пустой строкой (""), но одиночный тег (например, "выпуск") в порядке.
android.os.Build.TIME Значение, представляющее отметку времени, когда произошла сборка.
android.os.Build.TYPE Значение, выбранное разработчиком устройства, определяющее конфигурацию среды выполнения сборки. Это поле ДОЛЖНО иметь одно из значений, соответствующих трем типичным конфигурациям среды выполнения Android: «user», «userdebug» или «eng».
android.os.Build.USER Имя или идентификатор пользователя (или автоматизированного пользователя), сгенерировавшего сборку. Нет никаких требований к конкретному формату этого поля, за исключением того, что оно НЕ ДОЛЖНО быть нулевым или пустой строкой ("").

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработчики устройств НЕ ДОЛЖНЫ включать какие-либо компоненты Android, которые учитывают любые новые шаблоны Intent или Broadcast Intent с использованием ACTION, CATEGORY или другой ключевой строки в пространстве имен android.*. Разработчики устройств НЕ ДОЛЖНЫ включать какие-либо компоненты Android, которые учитывают любые новые шаблоны Intent или Broadcast Intent с использованием ACTION, CATEGORY или другой ключевой строки в пространстве пакета, принадлежащем другой организации. Разработчики устройств НЕ ДОЛЖНЫ изменять или расширять какие-либо шаблоны намерений, используемые основными приложениями, перечисленными в разделе 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 Open Source. Поскольку реализации 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 Browser или на его замене от стороннего производителя) ДОЛЖНО включать поддержку HTML5 [ Ресурсы , 9 ], насколько это возможно. Как минимум, реализации устройств ДОЛЖНЫ поддерживать геолокацию HTML5, кэш приложений и API базы данных, а также тег <video> в автономном приложении браузера.

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

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

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

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

Compatibility Test Suite (CTS) тестирует значительную часть платформы на поведенческую совместимость, но не всю. Ответственность за обеспечение поведенческой совместимости с проектом Android с открытым исходным кодом лежит на разработчике.

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

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

  • Ява.*
  • javax.*
  • солнце.*
  • андроид.*
  • ком.андроид.*

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

  • Реализации устройств НЕ ДОЛЖНЫ изменять общедоступные 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 Executable (DEX) и семантику виртуальной машины Dalvik [ Ресурсы, 10 ].

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

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

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

3.8.1. Виджеты

Android определяет тип компонента и соответствующий API и жизненный цикл, который позволяет приложениям предоставлять «AppWidget» конечному пользователю [ Ресурсы, 11 ]. Эталонный выпуск Android с открытым исходным кодом включает приложение Launcher, которое включает в себя элементы пользовательского интерфейса, позволяющие пользователю добавлять, просматривать и удалять 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 ].
  • Replica Island (доступно в Android Market; требуется только для устройств, поддерживающих OpenGL ES 2.0)

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

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

  • ApiDemos (входит в состав SDK)
  • ManualSmokeTests (входит в состав CTS)

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

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

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

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

6. Совместимость с мультимедиа

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

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

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

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

Аудио
Имя Кодер Декодер Подробности Формат файла/контейнера
AAC LC/LTP Икс Моно/стереоконтент в любой комбинации стандартных битрейтов до 160 кбит/с и частот дискретизации от 8 до 48 кГц 3GPP (.3gp) и MPEG-4 (.mp4, .m4a). Нет поддержки необработанного AAC (.aac)
НЕ-ААСv1 (ААС+) Икс
HE-AACv2 (расширенный AAC+) Икс
АМР-НБ Икс Икс От 4,75 до 12,2 кбит/с при частоте дискретизации 8 кГц 3GPP (.3gp)
АМР-ВБ Икс 9 скоростей от 6,60 кбит/с до 23,85 кбит/с при частоте дискретизации 16 кГц 3GPP (.3gp)
MP3 Икс Моно/стерео 8–320 кбит/с с постоянной (CBR) или переменной скоростью передачи данных (VBR) MP3 (.mp3)
МИДИ Икс MIDI Type 0 и 1. DLS Version 1 и 2. XMF и Mobile XMF. Поддержка форматов рингтонов RTTTL/RTX, OTA и iMelody. Введите 0 и 1 (.mid, .xmf, .mxmf). Также RTTTL/RTX (.rtttl, .rtx), OTA (.ota) и iMelody (.imy)
Огг Ворбис Икс Огг (.ogg)
ПКМ Икс 8- и 16-битный линейный PCM (скорость до предела аппаратного обеспечения) ВОЛНА (.wav)
Изображение
JPEG Икс Икс базовый+прогрессивный
гифка Икс
PNG Икс Икс
БМП Икс
видео
Н.263 Икс Икс файлы 3GPP (.3gp)
Н.264 Икс Файлы 3GPP (.3gp) и MPEG-4 (.mp4)
Простой профиль MPEG4 Икс Файл 3GPP (.3gp)

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

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

Когда приложение использовало API android.media.AudioRecord для начала записи аудиопотока, реализациям устройств СЛЕДУЕТ сэмплировать и записывать аудио с каждым из следующих вариантов поведения:

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

Примечание. Несмотря на то, что требования, изложенные выше, указаны как «СЛЕДУЕТ» для 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) [ Ресурсы, 19 ]
    Реализации устройств ДОЛЖНЫ поддерживать все функции adb , как описано в Android SDK. Демон adb на стороне устройства ДОЛЖЕН быть неактивным по умолчанию, но ДОЛЖЕН быть доступный пользователю механизм для включения моста отладки Android.
  • Служба монитора отладки Dalvik (известная как ddms) [ Ресурсы, 19 ]
    Реализации устройств ДОЛЖНЫ поддерживать все функции ddms , как описано в Android SDK. Поскольку ddms использует adb , поддержка ddms ДОЛЖНА быть неактивной по умолчанию, но ДОЛЖНА поддерживаться всякий раз, когда пользователь активирует мост отладки Android, как указано выше.
  • Обезьяна [ Ресурсы, 22 ]
    Реализации устройств ДОЛЖНЫ включать инфраструктуру Monkey и делать ее доступной для использования приложениями.

8. Аппаратная совместимость

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

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

  • определения классов для API компонента ДОЛЖНЫ присутствовать
  • поведение API ДОЛЖНО быть реализовано как отсутствие операций каким-либо разумным образом.
  • Методы API ДОЛЖНЫ возвращать нулевые значения, если это разрешено документацией SDK.
  • Методы API ДОЛЖНЫ возвращать недействующие реализации классов, где нулевые значения не разрешены документацией 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 Обычный Высокая
ФВВГА 480 854 3,5 - 4,0 Обычный Высокая
WVGA 480 800 4,8 - 5,5 Большой Середина
ФВВГА 480 854 5,0 - 5,8 Большой Середина

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

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

  • Реализации устройств ДОЛЖНЫ интерпретировать ресурсы в .apk, в которых отсутствует квалификатор плотности, как имеющие по умолчанию «средний» (известный как «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 [ Ресурсы, 26 ].

8.1.4. Заявленная поддержка экрана

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

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

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

  • ДОЛЖНА включать поддержку платформы управления вводом (которая позволяет сторонним разработчикам создавать механизмы управления вводом, т. е. программную клавиатуру), как описано на сайте developer.android.com.
  • ОБЯЗАТЕЛЬНО предусмотреть хотя бы одну программную клавиатуру (независимо от наличия жесткой клавиатуры)
  • МОЖЕТ включать дополнительные реализации программной клавиатуры
  • МОЖЕТ включать аппаратную клавиатуру
  • НЕ ДОЛЖЕН включать аппаратную клавиатуру, которая не соответствует одному из форматов, указанных в файле android.content.res.Configuration.keyboard [ Ресурсы, 25 ] (то есть QWERTY или 12-клавишная)

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

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

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

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

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

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

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

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

  • ОБЯЗАТЕЛЬНО иметь сенсорный экран
  • МОЖЕТ иметь емкостной или резистивный сенсорный экран
  • ДОЛЖЕН сообщать значение android.content.res.Configuration [ Ресурсы, 25 ], отражающее соответствие типу конкретного сенсорного экрана на устройстве.
  • СЛЕДУЕТ поддерживать полностью независимо отслеживаемые указатели, если сенсорный экран поддерживает несколько указателей.

8.6. USB

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

  • ДОЛЖЕН реализовать USB-клиент, подключаемый к USB-хосту со стандартным портом USB-A.
  • НЕОБХОДИМО внедрить Android Debug Bridge через USB (как описано в разделе 7)
  • ДОЛЖЕН реализовать спецификацию запоминающего устройства USB, чтобы позволить хосту, подключенному к устройству, получить доступ к содержимому тома /sdcard.
  • СЛЕДУЕТ использовать форм-фактор micro USB на стороне устройства
  • МОЖЕТ включать нестандартный порт на стороне устройства, но в этом случае ДОЛЖЕН поставляться с кабелем, способным подключить нестандартную распиновку к стандартному порту USB-A.
  • СЛЕДУЕТ реализовать поддержку спецификации USB Mass Storage (чтобы с хост-компьютера можно было получить доступ к съемному или фиксированному хранилищу на устройстве)

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

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

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

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

Реализации устройств ДОЛЖНЫ включать поддержку беспроводной высокоскоростной передачи данных. В частности, реализации устройств ДОЛЖНЫ включать поддержку по крайней мере одного стандарта беспроводной передачи данных со скоростью 200 Кбит/с или выше. Примеры технологий, удовлетворяющих этому требованию, включают EDGE, HSPA, EV-DO, 802.11g и т. д.

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

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

8.9. Камера

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

  • ОБЯЗАТЕЛЬНО иметь разрешение не менее 2 мегапикселей
  • СЛЕДУЕТ иметь либо аппаратную автофокусировку, либо программную автофокусировку, реализованную в драйвере камеры (прозрачную для прикладного программного обеспечения).
  • МОЖЕТ иметь оборудование с фиксированным фокусом или EDOF (расширенная глубина резкости).
  • МОЖЕТ включать вспышку. Если камера оснащена вспышкой, индикатор вспышки НЕ ДОЛЖЕН гореть, пока экземпляр android.hardware.Camera.PreviewCallback зарегистрирован на поверхности предварительного просмотра камеры, за исключением случаев, когда приложение явно включило вспышку, включив атрибуты FLASH_MODE_AUTO или FLASH_MODE_ON Объект Camera.Parameters . Обратите внимание, что это ограничение не применяется к встроенному системному приложению камеры устройства, а только к сторонним приложениям, использующим 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(), должны быть в формате кодировки NV21. (Это формат, изначально используемый аппаратным семейством 7k.) То есть NV21 ДОЛЖЕН быть по умолчанию.

Реализации устройств ДОЛЖНЫ реализовывать полный API камеры, включенный в документацию Android 2.2 SDK [ Ресурсы, 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, как подробно описано в Android API (см. [ Ресурсы, 28 ]).

8.11. Компас

Реализации устройств ДОЛЖНЫ включать 3-осевой компас и ДОЛЖНЫ быть в состоянии доставлять события с частотой 10 Гц или выше. Система координат, используемая компасом, ДОЛЖНА соответствовать системе координат датчика Android, определенной в Android API (см. [ Ресурсы, 28 ]).

8.12. GPS

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

8.13. Телефония

Android 2.2 МОЖЕТ использоваться на устройствах без телефонного оборудования. То есть Android 2.2 совместим с устройствами, не являющимися телефонами. Однако, если реализация устройства включает телефонию GSM или CDMA, она ДОЛЖНА реализовать полную поддержку API для этой технологии. Реализации устройств, которые не включают аппаратное обеспечение телефонии, ДОЛЖНЫ реализовывать полные API-интерфейсы как no-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 для этого общего хранилища. В противном случае общее хранилище ДОЛЖНО быть доступно для записи любым приложением, получившим это разрешение.

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

Независимо от формы используемого общего хранилища, общее хранилище ДОЛЖНО реализовывать запоминающее устройство USB, как описано в Разделе 8.6. При поставке общее хранилище ДОЛЖНО быть смонтировано с файловой системой FAT.

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

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

8.16. Bluetooth

Реализации устройства ДОЛЖНЫ включать приемопередатчик Bluetooth. Реализации устройств ДОЛЖНЫ включать API Bluetooth на основе RFCOMM, как описано в документации SDK [ Ресурсы, 30 ]. Реализации устройств СЛЕДУЕТ реализовывать соответствующие профили Bluetooth, такие как A2DP, AVRCP, OBEX и т. д., соответствующие устройству.

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

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

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

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

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

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

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

Реализации устройств ДОЛЖНЫ поддерживать модель разрешений Android, как определено в документации для разработчиков Android [ Ресурсы, 29 ]. В частности, реализации ДОЛЖНЫ применять каждое разрешение, определенное, как описано в документации SDK; никакие разрешения не могут быть пропущены, изменены или проигнорированы. Реализации МОГУТ добавлять дополнительные разрешения, при условии, что новые строки идентификатора разрешения не находятся в пространстве имен android.*.

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

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

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

Реализации устройств ДОЛЖНЫ поддерживать модель разрешений на доступ к файлам Android, как определено в документе «Безопасность и разрешения» [ Ресурсы, 29 ].

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

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

Альтернативные среды выполнения ДОЛЖНЫ быть приложениями Android и соответствовать стандартной модели безопасности Android, как описано в разделе 10.

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

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

Альтернативные среды выполнения ДОЛЖНЫ соответствовать модели песочницы Android. Конкретно:

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

Альтернативные среды выполнения НЕ ДОЛЖНЫ запускаться, предоставляться или предоставлять другим приложениям какие-либо привилегии суперпользователя (root) или любого другого идентификатора пользователя.

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

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

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

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

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

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

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

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

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

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 thid-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

13. Contact Us

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

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.