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

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

В 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 , системных вызовов локального времени) использует файл tzdata .
• Код библиотеки ICU4J/ICU4C в external/icu/ использует файл icu .dat .

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

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

• libcore/ и bionic/ code используют копию /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. OEM-производители должны включить это приложение в системный образ устройств, использующих эту функцию.
• tzdatacheck , двоичный файл времени загрузки, необходимый для правильной и безопасной работы обновлений часовых поясов.

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

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

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

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

   

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

   

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

     

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

     

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

   

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

Надежность

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

Чтобы справиться с этим, код системного сервера отслеживает, завершена ли инициированная проверка обновлений и каков код последней проверенной версии приложения данных. Когда устройство простаивает и заряжается, код системного сервера может проверять текущее состояние. Если он обнаруживает незавершенную проверку обновлений или неожиданную версию 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-производители могут захотеть иметь одно приложение данных для всех своих устройств или могут выбрать разные приложения данных для разных устройств. Решение влияет на выбор имени пакета, возможно, используемых кодов версий и стратегии контроля качества.
• Поймите, хотят ли они использовать стандартные данные часового пояса Android из AOSP или создать свои собственные.

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

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

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

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

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

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

Имя версии представляет собой удобочитаемое представление деталей, например: 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.

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

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-производители должны добавить свои 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="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

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

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

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

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