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

В 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 — обновляемое системное приложение (также известное как приложение «Данные» ), которое переносит файлы дистрибутива на устройство и делает их доступными для приложения Updater. OEM-производители должны включить это приложение в системный образ устройств, использующих эту функцию.
• tzdatacheck — двоичный файл времени загрузки, необходимый для правильной и безопасной работы обновлений часовых поясов.

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

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

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

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

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

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

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

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

     Рисунок 3. Обновления приложения данных с вызовом 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 вообще не получает вызова.

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

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

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

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

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

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

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

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

Подготовка

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

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

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

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

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

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

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

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

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

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/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. Обновите код версии приложения «Данные»

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

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

OEM-производители несут ответственность за обеспечение качества и тестирование обновленного приложения 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, числовое значение которого превышает 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- МР1.

Создайте приложение «Данные», используя тапас

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

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

    <!-- SDK for system / public API stubs -->
    <project
        path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth="1" />
    <!-- App source -->
    <project
        path="system/timezone"
        name="platform/system/timezone" />
    <project
        path="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZoneData" />
    <!-- Enable repohooks -->
    <project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="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 для тестирования. Эти файлы можно поместить в каталог предварительно созданных файлов для включения в образ системы и/или распространить через магазин приложений для совместимых устройств.