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

В 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 для данных, которые отсутствуют (для форматов, локализованных строк и т. д.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Приложение Updater выполняет необходимые действия на основе имеющейся у него информации. Доступны следующие действия:
   • Запросить установку. Данные дистрибутива считываются из приложения «Данные» и передаются в службу 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 для разных устройств. Это решение повлияет на выбор имени пакета, возможно, на используемые коды версий и стратегию контроля качества.
• Поймите, хотят ли они использовать стандартные данные часовых поясов Android от AOSP или создать свои собственные.

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

AOSP содержит весь исходный код и правила сборки, необходимые для создания приложения Data, в packages/apps/TimeZoneData , а также инструкции и примеры шаблонов для AndroidManifest.xml и других файлов, расположенных в packages/apps/TimeZoneData/oem_template . Примеры шаблонов включают как целевой объект сборки для реального APK-файла приложения 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 в каталоге /system/priv-app образа системы. Для этого сборка образа системы должна явно включать готовые целевые объекты приложений Updater и Data.

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

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

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