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

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

1. Введение

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

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

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

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

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

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

2. Ресурсы
  • Уровни требований IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  • Обзор программы совместимости Android: http://source.android.com/compatibility/index.html
  • Проект Android с открытым исходным кодом: http: //source.android.com/
  • Определения и документация API: http://developer.android.com/reference/packages.html
  • Справочник по разрешениям Android: http://developer.android.com/reference/android/Manifest.permission. html
  • android.os.Ссылка на сборку: http://developer.android.com/reference/android/os/Build.html
  • Строки разрешенных версий Android 2.1: http://source.android.com/docs/compatibility/2.1/versions .html
  • класс android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/ multipage/
  • Спецификация виртуальной машины Dalvik: доступна в исходном коде Android по адресу dalvik/docs
    •
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • Уведомления: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • Ресурсы приложения: http://code.google.com/android/reference/available-resources.html
  • Руководство по стилю значков строки состояния: http://developer.android.com/ guide/practices/ui_guideline /icon_design.html#statusbarstructure
  • Менеджер поиска: http://developer.android.com/reference/android/app/SearchManager.html
  • Тосты: http://developer.android.com/reference/android/widget /Toast.html
  • Живые обои: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • Приложения для Android :
  • http://code.google.com/p/apps-for-android Документация по инструменту (для adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  • Описание APK-файла Android: http://developer.android.com/guide/topics/fundamentals .html
  • Файлы манифеста: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • Инструмент тестирования Monkey: https://developer.android.com/studio/test/other-testing-tools/ обезьяна
  • с поддержкой нескольких экранов: http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera. html
  • Пространство координат датчика: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Справочник по безопасности и разрешениям Android: http://developer.android.com/guide/topics/security/security.html
  • Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

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

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

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

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

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

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

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

    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.1 это поле ДОЛЖНО иметь целочисленное значение 7.
    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.1-update1/ERC77/3359:userdebug/test-keys
    Отпечаток пальца НЕ ДОЛЖЕН содержать пробелов. Если другие поля, включенные в приведенный выше шаблон, содержат пробелы, их СЛЕДУЕТ заменить символом подчеркивания ASCII («_») в отпечатке пальца.
    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 определяет ряд основных приложений, таких как телефонный номеронабиратель, календарь, книга контактов, музыкальный проигрыватель и т. д. Разработчики устройств МОГУТ заменить эти приложения альтернативными версиями.

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

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

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

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

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

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

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

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

    Примечание. Этот раздел был изменен ошибкой EX6580.

    3.2.3.3.

    Пространства

    имен намерений

    Разработчики устройств НЕ ДОЛЖНЫ включать какой-либо компонент Android, который учитывает любые новые шаблоны намерений или широковещательных намерений с использованием 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. Совместимость веб-API

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

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

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

    МОГУТ отправлять пользовательскую строку пользовательского агента в автономное приложение браузера. Более того, автономный браузер МОЖЕТ быть основан на альтернативной технологии браузера (например, Firefox, Opera и т. д.). Однако даже если поставляется альтернативное приложение браузера, компонент WebView, предоставляемый сторонним приложениям, ДОЛЖЕН быть основан на WebKit, как указано выше.

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

    3.5. Совместимость поведения API.

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

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

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

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

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

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

    • java.*
    • javax.*
    • sun.*
    • android.*
    • 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.

    Приложения

    Toasts

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

    3.8.5. Живые обои

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

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

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

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

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

    • Калькулятор (включен в SDK)
    • Lunar Lander (включен в SDK)
    • Приложения «Приложения для Android» [ Ресурсы, 18 ].

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

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

    • ApiDemos (включено в SDK)
    • ManualSmokeTests (включено в CTS)

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

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

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

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

    6.

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

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

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

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

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

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

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

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

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

    8.1. Дисплей

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

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

    ширина ширины WVGA 480
    экрана (пиксели) высота (пиксели) диагональный диапазон длины (дюймы) Размер экрана Группа плотность экрана Группа
    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 Нормальная высокая
    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, как это предусмотрено в разделе 12, чтобы получить классификации для ковша, плотности и масштабирования экрана. При предоставлении этой информации реализации устройств должны реализовать их в соответствии с указанными.

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

    8.1.3.

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

    отображения метрик

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

    8.2.

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

    клавиатуры

    :

    • должны включать поддержку платформы управления входами (которая позволяет сторонним разработчикам создавать двигатели для управления входами - IE Soft Keyboard), как подробно описано на Developer.Android.com,
    • должна предоставить хотя бы одну мягкую реализацию клавиатуры (независимо от того, как Жесткая клавиатура присутствует)
    • может включать в себя дополнительные реализации мягкой клавиатуры,
    • могут включать аппаратную клавиатуру,
    • не должна включать аппаратную клавиатуру, которая не соответствует одному из форматов, указанных в android.content.res.Configuration.keyboard [ Ресурсы, 24 ] (то есть, то есть QWERTY, или 12-ключ)

    8.3.

    Реализации

    навигационных устройств без привязки

    :

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

    8.4.

    Устройства, совместимые с

    ориентацией экрана,

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

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

    8.5.

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

    ввода сенсорного экрана

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

    .

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

    USB

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

    8.7. Ключи навигации

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

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

    8.8.

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

    беспроводной сети данных

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

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

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

    8.9.

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

    камеры

    должны включать камеру. Включенная камера:

    • должна иметь разрешение не менее 2 мегапикселей
    • должна иметь либо аппаратную автоматическую фокусировку, либо автофокусировку программного обеспечения, реализованную в драйвере камеры (прозрачная для прикладного программного обеспечения)
    • может иметь фиксированные фокусировки или EDOF (расширенная глубина поле) Аппаратное обеспечение
    • может включать вспышку. Если камера включает в себя вспышку, флэш -лампа не должна быть зажжена, в то время как на поверхности предварительного просмотра камеры 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.1 SDK [ Resources, 26 ]), независимо от того, включает ли устройство Adware Autofocus или другие возможности.

    Например, камеры, которые не имеют автофокуса, все равно

    должны

    вызывать любые зарегистрированные экземпляры android.hardware.Camera.AutoFocusCallback .

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

    8.10.

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

    акселерометра

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

    8.11.

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

    Compass

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

    8.12.

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

    GPS

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

    8.13. Телефон

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

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

    8.14.

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

    памяти и хранения

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

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

    Примечание. Этот раздел был изменен с помощью ERRATUM EX6580.

    8.15.

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

    для хранения приложений

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

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

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

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

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

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

    . : Этот раздел был добавлен Erratum Ex6580.

    8.16.

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

    Bluetooth

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

    Примечание. Этот раздел был добавлен с помощью Erratum Ex6580.

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

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

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

    10. Реализации устройства совместимости модели безопасности

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

    10.1.

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

    разрешений

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

    10.2.

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

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

    должны поддерживать модель песочницы Android приложения, в которой каждое приложение работает как уникальный UID в стиле UNIX и в отдельном процессе.

    Реализации устройств должны поддерживать запуск нескольких приложений, как и тот же идентификатор пользователя Linux, при условии, что приложения соответственно подписаны и построены, как это определено в ссылке на безопасность и разрешения [ ресурсы, 28 ].

    10.3.

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

    FileSystem разрешений

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

    11. Реализация устройств для тестовых наборов совместимости

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

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

    12. Обновляемые

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

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

    • Загрузки Over-Eair (OTA) с обновлениями в автономном режиме с помощью перезагрузки
    • «привязанные» по поводу USB с обновлений с хост
    • "Offline" через перезагрузку и обновление из файла на Съемное хранилище.

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

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

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

    вы можете связаться с авторами документов по адресу compatibility@android .