Правила часовых поясов

Android - 10 раз уменьшает значимость механизм обновления данных зоны APK на основе (доступный в Android 8.1 и Android 9) и заменяет его с APEX на основе механизма обновления программного модуля . AOSP продолжает включать код платформы, необходимый OEM-производителям для включения обновлений на основе APK, поэтому устройства, обновляющиеся до Android 10, по-прежнему могут получать обновления данных о часовых поясах, предоставляемые партнерами, через APK. Однако механизм обновления APK не следует использовать на производственном устройстве, которое также получает обновления модулей, поскольку обновление на основе APK заменяет обновление на основе APEX (то есть устройство, получившее обновление APK, будет игнорировать обновления на основе APEX. ).

Обновление часовых поясов (Android 10+)

Модуль данных о часовых поясах, поддерживаемый в Android 10 и более поздних версиях, обновляет летнее время (DST) и часовые пояса на устройствах Android, стандартизируя данные, которые могут часто меняться по религиозным, политическим и геополитическим причинам.

Обновления используют следующий процесс:

  1. IANA выпускает обновление для базы данных часовых поясов выпускает обновление в ответ на один или несколько правительств изменяющегося правило зоны времени в своих странах.
  2. Google или партнер Android готовит обновление модуля данных о часовых поясах (файл APEX), содержащее обновленные часовые пояса.
  3. Устройство конечного пользователя загружает обновление, перезагружается, затем применяет изменения, после чего данные часового пояса устройства содержат новые данные часового пояса из обновления.

Подробные сведения о модулях см модульные компоненты системы .

Обновление часовых поясов (Android 8.1–9)

В Android 8.1 и Android 9 OEM-производители могут использовать механизм на основе APK для отправки обновленных данных правил часовых поясов на устройства без необходимости обновления системы. Этот механизм позволяет пользователям получать своевременные обновления (таким образом, продлевая полезный срок службы устройства Android) и позволяет партнерам Android тестировать обновления часовых поясов независимо от обновлений образа системы.

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

Исходный код и данные часового пояса Android

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

  • Управляемый код из libcore/ (например, java.util.TimeZone ) использует tzdata и tzlookup.xml файлы.
  • Машинный код библиотеки в bionic/ (например, для mktime , LocalTime системные вызовы) использует tzdata файл.
  • ICU4J / ICU4C код библиотеки в external/icu/ использует ОИТ .dat файл.

Эти библиотеки следить за файлами наложений , которые могут присутствовать в /data/misc/zoneinfo/current директории. Overlay файлы , как ожидается, содержат улучшенные данные правила часовых поясов, что позволяет устройствам быть обновлены без обновления /system .

Компоненты системы Android, которым требуются данные правил часовых поясов, сначала проверяют следующие места:

  • libcore/ и bionic/ код использовать /data копирования из tzdata и tzlookup.xml файлов.
  • ICU4J / ICU4C использовать код файлы в /data и попадают обратно в /system файлов для данных, нет (для форматов, локализованных строк и т.д.).

Файлы дистрибутива

DISTRO .zip файлы содержат файлы данных , необходимые для заполнения /data/misc/zoneinfo/current каталог. Файлы дистрибутива также содержат метаданные, которые позволяют устройствам обнаруживать проблемы с версией.

Формат файла дистрибутива зависит от версии Android, поскольку содержимое меняется в зависимости от версии ICU, требований платформы Android и других изменений выпуска. Android предоставляет файлы дистрибутива для поддерживаемых выпусков Android для каждого обновления IANA (в дополнение к обновлению системных файлов платформы). Чтобы поддерживать свои устройства в актуальном состоянии, OEM-производители могут использовать эти файлы дистрибутива или создавать свои собственные, используя дерево исходных текстов Android (которое содержит скрипты и другие файлы, необходимые для создания файлов дистрибутива).

Компоненты обновления часового пояса

Обновление правил часового пояса включает в себя передачу файлов дистрибутива на устройство и безопасную установку файлов, содержащихся внутри. Для переноса и установки требуется следующее:

  • Функциональные службы платформы ( timezone.RulesManagerService ), которая по умолчанию отключена. OEM-производители должны включить эту функциональность через конфигурацию. RulesManagerService работает в операции обновления зоны процесса сервера системы и временных этапов путем записи /data/misc/zoneinfo/staged . RulesManagerService может также заменить или удалить уже поставил операции.
  • TimeZoneUpdater , nonupdateable приложение системы (иначе приложение Updater). OEM-производители должны включить это приложение в образ системы устройств, использующих эту функцию.
  • OEM TimeZoneData , изменяемое приложение системы (аки приложения Data) , который несет дистрибутив файлы на устройство и делает их доступными для приложения Updater. OEM-производители должны включить это приложение в образ системы устройств, использующих эту функцию.
  • tzdatacheck , время загрузки двоичный требуется для правильной и безопасной эксплуатации обновления часовых поясов.

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

Установка дистрибутива

Процесс установки дистрибутива включает следующие шаги:

  1. Приложение Данных обновляются через загрузку приложения магазина или sideload. Система серверный процесс (через timezone.RulesManagerServer/timezone.PackageTracker классов) следит за изменениями в сконфигурированной, OEM-специфических, данных имя приложения пакета.

    Обновления данных приложения
    Обновления приложений Рисунок 1. Данные
  2. Триггера процесса системы сервера проверка обновлений вещательного целенаправленное намерение с уникальным, одноразовым маркером на Updater App. Системный сервер отслеживает самый последний сгенерированный им токен, чтобы определить, когда завершилась последняя запущенная им проверка; любые другие токены игнорируются.

    Обновление триггера
    Рисунок 2. Запуск проверки обновлений
  3. Во время проверки обновлений, приложение Updater выполняет следующие задачи:
    • Запрашивает текущее состояние устройства, вызывая RulesManagerService.

      Вызов RulesManagerService
      Рисунок 3. Данные обновления приложений, вызывая RulesManagerService
    • Запрашивает приложение Data, запрашивая четко определенный URL-адрес ContentProvider и спецификации столбца, чтобы получить информацию о дистрибутиве.

      Получить информацию о дистрибутиве
      Обновления приложений Рисунок 4. Данные, получить информацию о дистрибутиве
  4. Updater приложение выполняет соответствующее действие , основанное на информации , которую он имеет. Доступные действия включают:
    • Запросить установку. Данные Distro считываются из приложения Data и передаются в RulesManagerService на системном сервере. RulesManagerService подтверждает, что версия и содержимое формата дистрибутива подходят для устройства, и выполняет этап установки.
    • Запрос деинсталлировать (это редко). Например, если обновленный APK в /data отключения или удален , и устройство возвращается к версии , присутствующую в /system .
    • Ничего не делать. Происходит, когда обнаруживается, что дистрибутив приложения Data недействителен.
    Во всех случаях приложение Updater вызывает RulesManagerService с проверочным токеном, чтобы системный сервер знал, что проверка завершена и успешно.

    Проверка завершена
    Рисунок 5. Проверка завершена
  5. Перезагрузка и тздатачек. При следующей загрузке устройства двоичный файл tzdatacheck выполняет любую поэтапную операцию. Бинарный файл tzdatacheck может выполнять следующие задачи:
    • Выполните поставил операцию обработки создания, замены и / или удаление из /data/misc/zoneinfo/current файлы перед открылись и начали использовать файлы и другие компоненты системы.
    • Убедитесь , что файлы /data являются правильными для текущей версии платформы, которая не может быть в случае , если устройство только что получило обновление системы и дистрибутивы версии формата изменилась.
    • Убедитесь в том, что IANA правила версии такой же или новее , чем версия в /system . Это защищает от обновления системы , оставляя устройство со взрослыми времени данных правил зоны , чем присутствует в /system изображения.

Надежность

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

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

Безопасность

Если этот параметр включен, код RulesManagerService на системном сервере выполняет несколько проверок, чтобы гарантировать безопасность использования системы.

  • Проблемы, указывающие на плохо настроенный образ системы, препятствуют загрузке устройства; примеры включают плохой Updater или данных конфигурации приложения или приложения Updater или данных , не будучи в /system/priv-app .
  • Проблемы, указывающие на то, что установлено плохое приложение Data, не препятствуют загрузке устройства, но препятствуют запуску проверки обновлений; Примеры включают отсутствие необходимых системных разрешений или приложение данных не предоставляет ContentProvider для ожидаемого URI.

Права доступа к файлу для /data/misc/zoneinfo каталогов исполняются с использованием правил SELinux. Как и с любым APK, приложение данных должны быть подписаны одним и тем же ключом , используемым для подписания /system/priv-app версии. Предполагается, что приложение Data будет иметь специальное имя пакета и ключ для конкретного производителя оборудования.

Интеграция обновлений часовых поясов

Чтобы включить функцию обновления часового пояса, OEM-производители обычно:

  • Создайте собственное приложение Data.
  • Включите приложения Updater и Data в сборку образа системы.
  • Настройте системный сервер, чтобы включить RulesManagerService.

Подготовка

Перед началом работы OEM-производители должны ознакомиться со следующей политикой, вопросами обеспечения качества и безопасности:

  • Создайте специальный ключ подписи для своего приложения Data.
  • Создайте стратегию выпуска и управления версиями для обновлений часовых поясов, чтобы понять, какие устройства будут обновляться и как они могут гарантировать, что обновления устанавливаются только на тех устройствах, которые в них нуждаются. Например, OEM-производители могут захотеть иметь одно приложение данных для всех своих устройств или могут выбрать разные приложения данных для разных устройств. Решение влияет на выбор имени пакета, возможно, на используемые коды версий и стратегию обеспечения качества.
  • Узнайте, хотят ли они использовать стандартные данные часового пояса Android из AOSP или создать свои собственные.

Создание приложения данных

AOSP включает в себя все правила исходного кода и сборки , необходимые для создания приложения данных в packages/apps/TimeZoneData , с инструкциями и примеры шаблонов для AndroidManifest.xml и других файлов , находящихся в packages/apps/TimeZoneData/oem_template . Примеры шаблонов включают как цель сборки для реального APK-файла приложения Data, так и дополнительные цели для создания тестовых версий приложения Data.

OEM-производители могут настроить приложение Data с помощью собственного значка, имени, переводов и других деталей. Однако, как приложение данных не может быть запущена, иконка появляется только на экране Настройки> Приложения.

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

OEM - производители должны установить приложение уже настроенными данных в системе изображение устройства в /system/priv-app . Чтобы включить прекомпилированное APK - (генерируемые в процессе сборки тапас) в системе изображения, производители могут копировать файлы примеров в packages/apps/TimeZoneData/oem_template/data_app_prebuilt . Примеры шаблонов также включают цели сборки для включения тестовых версий приложения Data в наборы тестов.

Включение приложений Updater и Data в образ системы

OEM - производители должны размещать приложения APK - Updater и данных в /system/priv-app каталога системного образа. Для этого сборка образа системы должна явно включать предварительно созданные цели приложения Updater и приложения данных.

Приложение Updater должно быть подписано ключом платформы и включено, как любое другое системное приложение. Целевой определен в packages/apps/TimeZoneUpdater как TimeZoneUpdater . Включение приложения данных зависит от OEM-производителя и целевого имени, выбранного для предварительной сборки.

Настройка системного сервера

Чтобы включить обновления часовых поясов, производители могут конфигурировать сервер системы путем переопределения свойств конфигурации , определенные в frameworks/base/core/res/res/values/config.xml .

Имущество Описание Требуется переопределение?
config_enableUpdateableTimeZoneRules
Должен быть установлен true для того, чтобы RulesManagerService. да
config_timeZoneRulesUpdateTrackingEnabled
Должен быть установлен true , чтобы система прослушивания изменений в приложение Data. да
config_timeZoneRulesDataPackage
Имя пакета OEM-приложения Data. да
config_timeZoneRulesUpdaterPackage
Настроен для приложения Updater по умолчанию. Изменяйте только при предоставлении другой реализации приложения Updater. Нет
config_timeZoneRulesCheckTimeMillisAllowed
Время между проверкой обновлений, инициированной RulesManagerService, и ответом на установку, удаление или бездействие. После этого может быть сгенерирован спонтанный триггер надежности. Нет
config_timeZoneRulesCheckRetryCount
Число последовательных неудачных проверок обновлений, разрешенных до того, как RulesManagerService перестанет генерировать новые. Нет

Переопределения конфигурации должны быть в образе системы (не от поставщика или другого), поскольку неправильно настроенное устройство может отказаться от загрузки. Если переопределения конфигурации были в образе поставщика, обновление до образа системы без приложения Data (или с другими именами пакетов приложения Data / Updater) будет считаться неправильной конфигурацией.

xTS тестирование

xTS - это любой набор тестов для OEM, который похож на стандартные наборы тестов Android, использующие Tradefed (например, CTS и VTS). OEM-производители, у которых есть такие комплекты тестов, могут добавить тесты обновления часовых поясов Android, представленные в следующих местах:

  • packages/apps/TimeZoneData/testing/xts включает в себя код , необходимый для базового автоматизированного функционального тестирования.
  • packages/apps/TimeZoneData/oem_template/xts содержит структуру каталогов образца для включения тестов в Tradefed-как XTS люкса. Как и в случае с другими каталогами шаблонов, OEM-производители должны копировать и настраивать их в соответствии со своими потребностями.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt содержит конфигурацию сборки времени для включения предварительно встроенные тестовые APK - необходимые испытания.

Создание обновлений часового пояса

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

Поскольку приложение данных содержат файлы дистрибутива тесно связан с версиями Android, производители должны создать новую версию приложения данных для все поддерживаемого Android - релиза , что OEM хочет обновить. Например, если OEM-производитель хочет предоставить обновления для устройств Android 8.1, 9 и 10, он должен выполнить процесс трижды.

Шаг 1. Обновление файлов данных системы / часового пояса и внешних файлов / icu

На этом этапе производители подытожить Android фиксаций для system/timezone и external/icu от выпуска -dev ветвей в AOSP и применять эти коммиты их копии исходного кода Android.

AOSP патч система / часовой пояс содержит обновленные файлы в system/timezone/input_data и system/timezone/output_data . OEM - производителям , которым необходимо сделать дополнительные локальные исправления может изменить входные файлы затем использовать файлы в system/timezone/input_data и external/icu для создания файлов в output_data .

Самый важный файл system/timezone/output_data/distro/distro.zip , который автоматически включается , когда данные приложения APK построен.

Шаг 2. Обновление кода версии приложения Data

На этом этапе OEM-производители обновляют код версии приложения Data. Сборки автоматически подбирает distro.zip , но новая версия приложения Data должна иметь новую версию кода , так что это признается новым , и используются для замены предустановленного приложения данных или приложения данных , установленное на устройстве предыдущего обновления.

При создании приложения данных с использованием файлов , скопированных из package/apps/TimeZoneData/oem_template/data_app , вы можете найти название версии кода / версия применительно к АПК в Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Подобные записи можно найти в testing/Android.mk (однако, тестовая версия кода должна быть выше , чем версия образа системы). Для получения дополнительной информации см схема примера кода версии стратегии ; если используется примерная схема или аналогичная схема, коды тестовой версии не нужно обновлять, потому что они гарантированно будут выше, чем коды реальной версии.

Шаг 3. Восстановление, подписание, тестирование и выпуск

На этом этапе OEM-производители восстанавливают APK с помощью тапа, подписывают сгенерированный APK, затем тестируют и выпускают APK:

  • Для невыпущенных устройств (или при подготовке обновления системы для выпущенного устройства) отправьте новые APK-файлы в предварительно созданный каталог приложения Data, чтобы убедиться, что образ системы и тесты xTS имеют самые последние APK. OEM-производители должны проверить, что новый файл работает правильно (то есть он проходит CTS и любые автоматические и ручные тесты, специфичные для OEM).
  • Для выпущенных устройств, которые больше не получают обновления системы, подписанный APK может быть выпущен только через магазин приложений.

OEM-производители несут ответственность за обеспечение качества и тестирование обновленного приложения Data на своих устройствах перед выпуском.

Стратегия кода версии приложения данных

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

Код версии APK должен включать следующую информацию:

  • Версия формата дистрибутива (основная + дополнительная)
  • Увеличивающийся (непрозрачный) номер версии

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

Пример стратегии кода версии

Этот пример схемы нумерации версий гарантирует, что более высокие версии формата дистрибутива заменят более низкие версии формата дистрибутива. AndroidManifest.xml использует android:minSdkVersion , чтобы гарантировать , что старые устройства не получают версии с более высокой версией формата дистрибутив , чем они могут справиться.

Проверка версии
Рисунок 6. Пример стратегии версии кода
Пример Ценить Цель
Y Зарезервированный Позволяет использовать альтернативные схемы / тестовые APK-файлы в будущем. Первоначально (неявно) 0. Поскольку базовый тип является 32-битным типом int со знаком, эта схема поддерживает до двух будущих ревизий схемы нумерации.
01 Версия основного формата Отслеживает версию основного формата с 3 десятичными цифрами. Формат дистрибутива поддерживает 3 десятичных цифры, но здесь используются только 2 цифры. Маловероятно, что он достигнет 100 с учетом ожидаемого значительного увеличения на каждый уровень API. Основная версия 1 эквивалентна уровню API 27.
1 Версия второстепенного формата Отслеживает версию второстепенного формата с 3 десятичными цифрами. Формат дистрибутива поддерживает 3 десятичных цифры, но здесь используется только 1 цифра. Вряд ли дойдет до 10.
Икс Зарезервированный 0 для производственных выпусков (и может быть другим для тестовых APK).
ZZZZZ Непрозрачный номер версии Десятичное число выделяется по запросу. Включает пробелы, позволяющие при необходимости обновлять межстраничные объявления.

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

Название версии является читаемым человеком представлением деталей, например: major=001,minor=001,iana=2017a, revision=1,respin=2 . Примеры приведены в следующей таблице.

# Код версии minSdkVersion {Версия основного формата}, {Версия второстепенного формата}, {Версия правил IANA}, {Версия}
1 11000010 O-MR1 основной = 001, второстепенный = 001, iana = 2017a, редакция = 1
2 21000010 п основной = 002, второстепенный = 001, iana = 2017a, редакция = 1
3 11000020 O-MR1 основной = 001, второстепенный = 001, iana = 2017a, редакция = 2
4 11000030 O-MR1 основной = 001, второстепенный = 001, iana = 2017b, редакция = 1
5 21000020 п основной = 002, второстепенный = 001, iana = 2017b, редакция = 1
6 11000040 O-MR1 основной = 001, второстепенный = 001, iana = 2018a, редакция = 1
7 21000030 п основной = 002, второстепенный = 001, iana = 2018a, редакция = 1
8 1123456789 - -
9 11000021 O-MR1 major = 001, minor = 001, iana = 2017a, revision = 2, respin = 2
  • В примерах 1 и 2 показаны две версии APK для одного и того же выпуска IANA 2017a с разными версиями основного формата. 2 численно больше 1, что необходимо для обеспечения того, чтобы более новые устройства получали версии более высокого формата. MinSdkVersion гарантирует, что версия P не будет поставляться на устройства O.
  • Пример 3 представляет собой исправление / исправление для 1 и численно больше 1.
  • Примеры 4 и 5 показывают выпуски 2017b для O-MR1 и P. Будучи численно выше, они заменяют предыдущие выпуски IANA / версии Android своих соответствующих предшественников.
  • Примеры 6 и 7 показывают выпуски 2018a для O-MR1 и P.
  • Пример 8 демонстрирует использование Y для полной замены схемы Y = 0.
  • Пример 9 демонстрирует использование промежутка между 3 и 4 для повторного вращения apk.

Поскольку каждое устройство поставляется с APK-файлом по умолчанию с соответствующей версией в образе системы, нет риска установки версии O-MR1 на устройство P, потому что оно имеет более низкий номер версии, чем версия образа системы P. Устройство с версией O-MR1 , установленной в /data , который затем получает обновление системы для P использует /system версию в предпочтении к версии О-MR1 в /data , так как Р версия всегда выше , чем любая программа предназначена для O- MR1.

Создание приложения данных с помощью тапас

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

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

Создание манифеста

Сокращенное дерево исходного кода обычно достигается с помощью настраиваемого файла манифеста, который относится только к проектам Git, необходимым системе сборки и для сборки приложения. После того, как, следуя инструкции в Создании приложения данных , производители должны иметь по крайней мере два OEM-специфические Git проектов , созданные с помощью файлов шаблонов под packages/apps/TimeZoneData/oem_template :

  • Один из проектов Git содержит приложение файлы , такие как манифест и файлы сборки , необходимые для создания файла приложения APK (например, vendor/ oem /apps/TimeZoneData ). Этот проект также содержит правила сборки для тестовых APK-файлов, которые могут использоваться тестами xTS.
  • Один проект Git содержит подписанные APK, созданные сборкой приложения, для включения в сборку образа системы и тесты xTS.

Сборка приложения использует несколько других проектов Git, которые используются совместно со сборкой платформы или содержат библиотеки кода, не зависящие от OEM.

Следующий фрагмент манифеста содержит минимальный набор проектов Git, необходимых для поддержки сборки O-MR1 приложения данных о часовых поясах. OEM-производители должны добавить свои проекты Git для OEM-производителей (которые обычно включают проект, содержащий сертификат подписи) в этот манифест и могут соответствующим образом настроить различные ветви.

   <!-- Tapas Build -->
    <project
        path="build"
        name="platform/build">
        <copyfile src="core/root.mk" dest="Makefile" />
    </project>
    <project
        path="prebuilts/build-tools"
        name="platform/prebuilts/build-tools"
        clone-depth="1" />
    <project
        path="prebuilts/go/linux-x86"
        name="platform/prebuilts/go/linux-x86"
        clone-depth="1" />
    <project
        path="build/blueprint"
        name="platform/build/blueprint" />
    <project
        path="build/kati"
        name="platform/build/kati" />
    <project
        path="build/soong"
        name="platform/build/soong">
        <linkfile src="root.bp" dest="Android.bp" />
        <linkfile src="bootstrap.bash" dest="bootstrap.bash" />
    </project>

    <!-- SDK for system / public API stubs -->
    <project
        path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth="1" />
    <!-- App source -->
    <project
        path="system/timezone"
        name="platform/system/timezone" />
    <project
        path="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZoneData" />
    <!-- Enable repohooks -->
    <project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Запуск сборки тапас

После того, как установлено исходное дерево, вызовите тапас строить , используя следующие команды:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

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