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

В 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 прекратил предоставлять исправления часовых поясов для Android 10 в августе 2026 года. Последним исправлением стала версия TZDB 2026c. Производители оригинального оборудования могут продолжить поддержку Android 10.

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

Примечание. Механизм обновления данных о часовых поясах на основе APK полностью удален из Android 14 и более поздних версий. Его нет в исходном коде. Партнерам следует полностью перейти на модуль Mainline для часовых поясов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Рисунок 2. Запустить проверку обновлений.

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

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

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

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

Подготовка

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

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

Как создать приложение для работы с данными

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

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

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

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

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

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

Приложение Updater должно быть подписано ключом платформы и включено в систему как любое другое системное приложение. Целевой объект определяется в файле packages/apps/TimeZoneUpdater как TimeZoneUpdater. Включение приложения Data зависит от 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 – это любой набор тестов, разработанный производителем и похожий на стандартные наборы тестов 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, которую они хотят обновить. Например, если OEM хочет предоставить обновления для устройств с Android 8.1, 9 и 10, ему нужно пройти процедуру три раза.

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

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

Исправление 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. Обновите код версии приложения "Передача данных"

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

При создании приложения 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 app prebuilt, чтобы в образе системы и тестах xTS были последние версии APK. OEM-производители должны проверить, правильно ли работает новый файл (то есть проходит ли он CTS и любые автоматизированные и ручные тесты, специфичные для OEM).
• Для выпущенных устройств, которые больше не получают обновления системы, подписанный APK-файл может быть выпущен только через магазин приложений.

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

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

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

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

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

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

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

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

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

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

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

• В примерах 1 и 2 показаны две версии APK для одного и того же выпуска IANA 2017a с разными основными версиями формата. 2 больше, чем 1, поэтому новые устройства будут получать более новые версии формата. Благодаря minSdkVersion версия P не будет поставляться на устройства с версией O.
• Пример 3 – это исправленная версия примера 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, созданных с помощью файлов шаблонов в каталоге packages/apps/TimeZoneData/oem_template:

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

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

В приведенном ниже фрагменте манифеста содержится минимальный набор проектов 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

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