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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Android 10 прекращает поддержку механизма обновления данных часового пояса на основе APK (доступного в Android 8.1 и Android 9) и заменяет его механизмом обновления модулей на основе APEX . AOSP 8.1–13 по-прежнему включают код платформы, необходимый 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)

Примечание: Функция механизма обновления данных часового пояса на основе APK полностью удалена с Android 14 и далее и не может быть найдена в исходном коде. Партнеры должны полностью перейти на модуль Time Zone Mainline.

В 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/ использует файл icu .dat .

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

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

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

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

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

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

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

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

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

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

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

Процесс установки дистрибутива включает в себя следующие этапы:

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

   Рисунок 1. Обновления приложения «Данные».

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

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

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

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

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

Подготовка

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

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

Создать приложение для обработки данных

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

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

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

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

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

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

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

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

Чтобы включить обновления часовых поясов, OEM-производители могут настроить системный сервер, переопределив свойства конфигурации, определенные в 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 относится к любому OEM-специфическому тестовому набору, который похож на стандартные тестовые наборы Android, использующие Tradefed (например, CTS и VTS). OEM-производители, у которых есть такие тестовые наборы, могут добавлять тесты обновления часового пояса Android, представленные в следующих местах:

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

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

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

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

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

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

Патч AOSP system/timezone содержит обновленные файлы в 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-файла приложения Data.

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

На этом этапе OEM-производители обновляют код версии приложения Data. Сборка автоматически подхватывает distro.zip , но новая версия приложения Data должна иметь новый код версии, чтобы она распознавалась как новая и использовалась для замены предварительно загруженного приложения 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: Перекомпиляция, подписание, тестирование и выпуск

На этом этапе OEM-производители перестраивают APK с помощью tapas, подписывают сгенерированный 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. Пример стратегии кода версии.

Схема могла бы быть упакована лучше, если бы вместо десятичной использовалась двоичная система, но эта схема имеет преимущество в том, что ее может прочитать человек. Если весь диапазон чисел исчерпан, имя пакета приложения 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.

Создайте приложение Data с помощью тапов

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

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

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

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

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

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

Следующий фрагмент манифеста содержит минимальный набор проектов Git, необходимых для поддержки сборки O-MR1 приложения Time Zone Data. OEM-производители должны добавить свои OEM-специфичные проекты 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 для тестирования. Эти файлы можно поместить в каталог prebuilds для включения в образ системы и/или распространения через магазин приложений для совместимых устройств.