1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ДОЛЖЕН объявить функцию android.hardware.type.automotive.
• ДОЛЖЕН поддерживать uiMode = UI_MODE_TYPE_CAR [ Resources, 5 ].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3.2. Разрешение намерения

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

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

Однако реализации устройств МОГУТ обеспечивать действия по умолчанию для определенных шаблонов URI (например, http://play.google.com), когда действие по умолчанию предоставляет более конкретный атрибут для URI данных. Например, шаблон фильтра намерений, определяющий URI данных «http://www.android.com», является более конкретным, чем основной шаблон намерений браузера для «http://».

Android также включает в себя механизм, позволяющий сторонним приложениям объявлять авторитетное поведение связывания приложений по умолчанию для определенных типов намерений веб-URI [ Ресурсы, 140 ]. Когда такие авторитетные декларации определены в шаблонах фильтров намерений приложения, реализации устройств:

• ДОЛЖЕН попытаться проверить любые фильтры намерений, выполнив шаги проверки, определенные в спецификации ссылок на цифровые активы [ Ресурсы, 141 ], как это реализовано диспетчером пакетов в исходном проекте Android с открытым исходным кодом.
• ДОЛЖЕН попытаться проверить фильтры намерений во время установки приложения и установить все успешно проверенные фильтры намерений UIR в качестве обработчиков приложений по умолчанию для их UIR.
• МОЖЕТ установить определенные фильтры намерений URI в качестве обработчиков приложений по умолчанию для своих URI, если они успешно проверены, но другие фильтры-кандидаты URI не проходят проверку. Если реализация устройства делает это, она ДОЛЖНА предоставить пользователю соответствующие переопределения шаблона для каждого URI в меню настроек.
• ДОЛЖЕН предоставить пользователю элементы управления ссылками на приложения для каждого приложения в настройках следующим образом:
  • Пользователь ДОЛЖЕН иметь возможность целостно переопределить поведение ссылок приложения по умолчанию, чтобы приложение было всегда открытым, всегда спрашивать или никогда не открывать, что должно одинаково применяться ко всем кандидатам на фильтры намерений URI.
  • Пользователь ДОЛЖЕН иметь возможность видеть список возможных фильтров намерений URI.
  • Реализация устройства МОЖЕТ предоставить пользователю возможность переопределить определенные фильтры намерений-кандидатов URI, которые были успешно проверены, для каждого фильтра намерения.
  • Реализация устройства ДОЛЖНА предоставлять пользователям возможность просматривать и переопределять определенные фильтры намерений-кандидатов URI, если реализация устройства позволяет некоторым фильтрам намерений-кандидатов URI пройти проверку успешно, в то время как некоторые другие могут потерпеть неудачу.

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

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

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

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

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

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

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

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

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

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

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

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

• ДОЛЖЕН включать поддержку кода, выполняющегося в управляемой среде, для вызова собственного кода с использованием стандартной семантики Java Native Interface (JNI).
• ДОЛЖЕН быть совместим с исходным кодом (т. е. совместимым с заголовком) и двоично-совместимым (для ABI) с каждой необходимой библиотекой из списка ниже.
• ДОЛЖЕН поддерживать эквивалентный 32-битный ABI, если поддерживается любой 64-битный ABI.
• ДОЛЖЕН точно сообщать о собственном двоичном интерфейсе приложения (ABI), поддерживаемом устройством, через параметры android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS и android.os.Build.SUPPORTED_64_BIT_ABIS, каждый из которых представляет собой список значений, разделенных запятыми. ABI упорядочены от наиболее предпочтительного к наименее предпочтительному.
• ДОЛЖНЫ сообщать через вышеуказанные параметры только те ABI, которые задокументированы и описаны в последней версии документации по управлению ABI Android NDK [ Resources, 12 ] и ДОЛЖНЫ включать поддержку расширения Advanced SIMD (также известного как NEON) [ Resources, 13 ]
• СЛЕДУЕТ создавать с использованием исходного кода и файлов заголовков, доступных в исходном проекте Android с открытым исходным кодом.

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

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

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

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

Реализации устройств, если они включают в себя собственную библиотеку с именем libvulkan.so, ДОЛЖНЫ экспортировать функциональные символы и предоставлять реализацию API Vulkan 1.0 и расширений VK_KHR_surface, VK_KHR_swapchain и VK_KHR_android_surface, как определено Khronos Group и пройти тесты на соответствие Khronos.

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

3.3.2. Совместимость с 32-битным собственным кодом ARM

Архитектура ARMv8 не поддерживает некоторые операции ЦП, включая некоторые операции, используемые в существующем собственном коде. На 64-битных устройствах ARM следующие устаревшие операции ДОЛЖНЫ оставаться доступными для 32-битного собственного кода ARM либо посредством встроенной поддержки ЦП, либо посредством программной эмуляции:

• Инструкции SWP и SWPB
• Инструкция SETEND
• Барьерные операции CP15ISB, CP15DSB и CP15DMB

Устаревшие версии Android NDK использовали /proc/cpuinfo для обнаружения функций ЦП из 32-битного собственного кода ARM. Для совместимости с приложениями, созданными с использованием этого NDK, устройства ДОЛЖНЫ включать следующие строки в /proc/cpuinfo, когда он читается 32-битными приложениями ARM:

• «Функции:», за которым следует список любых дополнительных функций ЦП ARMv7, поддерживаемых устройством.
• «Архитектура ЦП:», за которой следует целое число, описывающее максимальную поддерживаемую устройством архитектуру ARM (например, «8» для устройств ARMv8).

Эти требования применяются только тогда, когда /proc/cpuinfo читается 32-битными приложениями ARM. Устройствам НЕ СЛЕДУЕТ изменять /proc/cpuinfo при чтении 64-разрядными приложениями ARM или не-ARM.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Джава.*
• Javax.*
• солнце.*
• Android.*
• com.android.*

Запрещенные модификации включают :

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

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

Реализации устройств могут добавлять пользовательские API, но любые такие API не должны находиться в пространстве имен, принадлежащих или ссылается на другую организацию. Например, реализаторы устройства не должны добавлять API в com.google.* Или аналогичное пространство имен: только Google может сделать это. Точно так же Google не должен добавлять API в пространства имен других компаний. Кроме того, если реализация устройства включает в себя пользовательские API за пределами стандартного пространства имен Android, эти API должны быть упакованы в библиотеку Shared Android, чтобы увеличить память, которые явно используют их (через LT; используют Librarygt; механизм). Использование таких API.

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