Правила часового пояса

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

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

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

Обновления выполняются по следующей схеме:

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

Подробную информацию о модулях см. в разделе «Модульные системные компоненты» .

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

Примечание: Функция обновления данных о часовых поясах через APK-файл была полностью удалена начиная с Android 14 и отсутствует в исходном коде. Партнерам следует полностью перейти на основной модуль «Часовые пояса».

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

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

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

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

• Управляемый код из libcore/ (например, java.util.TimeZone ) использует файлы tzdata и tzlookup.xml .
• В коде нативной библиотеки bionic/ (например, для вызовов mktime и localtime) используется файл tzdata .
• Библиотечный код ICU4J/ICU4C, расположенный во external/icu/ использует файл .dat .

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

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

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

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

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

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

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

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

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

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

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

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

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

   Рисунок 1. Обновления приложения для работы с данными.

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

   Рисунок 2. Проверка обновления триггера.

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

     Рисунок 3. Обновление приложения данных с помощью вызова RulesManagerService.

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

     Рисунок 4. Обновления приложения для работы с данными, получение информации о дистрибутиве.

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

   Рисунок 5. Проверка завершена.

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

Надежность

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

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

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

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

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

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

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

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

• Создать собственное приложение для работы с данными.
• Включите приложения «Обновление» и «Данные» в процесс создания образа системы.
• Настройте системный сервер для включения службы RulesManagerService.

Подготовка

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

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

Создайте приложение для работы с данными.

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

Производители оборудования могут настраивать приложение «Данные», добавляя собственную иконку, название, переводы и другие параметры. Однако, поскольку приложение «Данные» нельзя запустить, его иконка отображается только на экране «Настройки > Приложения» .

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

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

Включите приложения «Обновление» и «Данные» в образ системы.

Производители оборудования должны разместить APK-файлы приложений «Обновление» и «Данные» в каталоге /system/priv-app образа системы. Для этого в сборку образа системы необходимо явно включить предварительно собранные целевые объекты приложений «Обновление» и «Данные».

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

Настройте системный сервер.

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

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

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

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

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

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

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

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

In this step, OEMs take stock Android commits for system/timezone and external/icu from the release -dev branches in AOSP and apply those commits to their copy of the Android source code.

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

Наиболее важный файл — system/timezone/output_data/distro/distro.zip , который автоматически включается при сборке APK-файла приложения «Данные».

Шаг 2: Обновите код версии приложения «Данные».

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

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

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

Шаг 3: Пересобрать, подписать, протестировать и выпустить.

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

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

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

стратегия кодирования версий приложения для работы с данными

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

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

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

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

Пример стратегии использования кода версии

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

Рисунок 6. Пример стратегии кодирования версий.

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

Название версии представляет собой удобочитаемое отображение подробностей, например: major=001,minor=001,iana=2017a, revision=1,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 вместо версии O-MR1 в /data , поскольку версия P всегда выше, чем любое приложение, предназначенное для O-MR1.

Создайте приложение для работы с данными, используя Tapas.

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

Tapas — это упрощённая версия системы сборки Android, использующая сокращённое дерево исходного кода для создания распространяемых версий приложений. Производители оборудования, знакомые со стандартной системой сборки Android, должны узнать файлы сборки из стандартной системы сборки платформы Android.

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

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

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

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

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

   <!-- 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="main"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

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

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

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

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