Reguły strefy czasowej

Android 10 wycofuje mechanizm aktualizacji danych strefy czasowej oparty na pliku APK (dostępny w Androidzie 8.1 i 9) i zastępuje go mechanizmem aktualizacji modułu opartego na pliku APEX. Zasady AOSP w wersjach od 8.1 do 13 nadal zawierają kod platformy wymagany dla producentów OEM do włączania aktualizacji opartych na plikach APK. Dzięki temu urządzenia po aktualizacji do Androida 10 mogą nadal otrzymywać przekazywane przez partnera aktualizacje danych o strefie czasowej za pomocą pliku APK. Mechanizmu aktualizacji APK nie należy jednak używać na urządzeniu produkcyjnym, które otrzymuje również aktualizacje modułów, ponieważ aktualizacja oparta na pliku APK zastępuje aktualizację opartą na pliku APEX (czyli urządzenie, które otrzymało aktualizację APK, zignoruje aktualizacje oparte na pliku APEX).

Aktualizacje strefy czasowej (Android 10 i nowsze)

Moduł danych strefy czasowej obsługiwany w Androidzie 10 i wyższych aktualizuje czas letni i strefy czasowe na urządzeniach z Androidem, standaryzując dane, które mogą się często zmieniać z powodów religijnych, politycznych i geopolitycznych.

Aktualizacje są wprowadzane w ramach tego procesu:

1. IANA publikuje aktualizację w Baza danych stref czasowych w odpowiedzi na zmianę reguły strefy czasowej przez co najmniej 1 rząd.
2. Google lub partner Androida przygotowują aktualizację modułu danych strefy czasowej (plik APEX) zawierającą zaktualizowane strefy czasowe.
3. Urządzenie użytkownika pobiera aktualizację, uruchamia się ponownie, a następnie stosuje zmiany. Po tym dane strefy czasowej urządzenia zawierają nowe dane strefy czasowej z aktualizacji.

Szczegółowe informacje o modułach znajdziesz w artykule Modułowy system komponentów.

Aktualizacje strefy czasowej (Android 8.1–9)

Uwaga: mechanizm aktualizacji danych strefy czasowej oparty na pliku APK został całkowicie usunięty z Androida 14 i późniejszych wersji, dlatego nie można go znaleźć w źródle kodu. Partnerzy powinni w pełni przejść na moduł główny TimeZone.

W Androidzie 8.1 i Androidzie 9 producenci OEM mogą korzystać z mechanizmu opartego na pliku APK, aby przesyłać na urządzenia zaktualizowane dane dotyczące stref czasowych bez konieczności aktualizacji systemu. Ten mechanizm umożliwia użytkownikom otrzymywanie aktualnych aktualizacji (a tym samym wydłużanie okresu przydatności urządzenia z Androidem) oraz umożliwia partnerom Androida testowanie aktualizacji strefy czasowej niezależnie od aktualizacji obrazu systemu.

Zespół bibliotek Androida dostarcza niezbędne pliki danych do aktualizowania reguł strefy czasowej na standardowym urządzeniu z Androidem. Producenci OEM mogą używać tych plików danych podczas tworzenia aktualizacji strefy czasowej dla swoich urządzeń lub mogą tworzyć własne pliki danych. W każdym przypadku producenci urządzeń zachowują kontrolę nad zapewnieniem jakości i testowaniem, czasem oraz wdrażaniem aktualizacji reguł stref czasowych na obsługiwanych urządzeniach.

Kod źródłowy i dane strefy czasowej Androida

Wszystkie standardowe urządzenia z Androidem, nawet te, które nie korzystają z tej funkcji, wymagają danych reguł strefy czasowej i muszą być dostarczane z domyślnym zestawem danych reguł strefy czasowej na partycji /system. Te dane są następnie używane przez kod z tych bibliotek w drzewie źródłowym Androida:

• Kod zarządzany z libcore/ (na przykład java.util.TimeZone) używa plików tzdata i tzlookup.xml.
• Kod biblioteki natywnej w języku bionic/ (na przykład w przypadku mktime wywołań systemowych w czasie lokalnym) używa pliku tzdata.
• Kod biblioteki ICU4J/ICU4C w external/icu/ korzysta z pliku icu .dat.

Te biblioteki śledzą pliki nakładek, które mogą znajdować się w katalogu /data/misc/zoneinfo/current. Pliki nakładki powinny zawierać ulepszone dane reguł stref czasowych, co umożliwi aktualizację urządzeń bez zmiany /system.

Komponenty systemu Android, które wymagają danych reguł strefy czasowej, sprawdź najpierw te lokalizacje:

• Kody libcore/ i bionic/ korzystają z /data kopii plików tzdata i tzlookup.xml.
• Kod ICU4J/ICU4C wykorzystuje pliki w /data i przełącza się na pliki /system w przypadku danych, których nie ma (formaty, zlokalizowane ciągi znaków itp.).

Pliki Distro

Pliki dystrybucji .zip zawierają pliki danych potrzebne do wypełnienia katalogu /data/misc/zoneinfo/current. Pliki dystrybucji zawierają też metadane, które umożliwiają urządzeniom wykrywanie problemów z wersjami.

Format pliku distro zależy od wersji Androida, ponieważ jego zawartość zmienia się wraz z wersją ICU, wymaganiami platformy Androida i innymi zmianami wersji. Android udostępnia pliki dystrybucji dla obsługiwanych wersji Androida w przypadku każdej aktualizacji IANA (oprócz aktualizacji plików systemowych platformy). Aby zapewnić aktualność urządzeń, OEM może użyć tych plików dystro lub utworzyć własne za pomocą drzewa źródłowego Androida (zawierającego skrypty i inne pliki potrzebne do generowania plików distro).

Komponenty aktualizacji strefy czasowej

Aktualizacja reguł strefy czasowej polega na przesłaniu plików dystrybucji na urządzenie i bezpiecznym zainstalowaniu ich zawartości. Przeniesienie i instalacja wymagają:

• Funkcje usługi platformy (timezone.RulesManagerService), która jest domyślnie wyłączona. Producenci OEM muszą włączyć tę funkcję w ramach konfiguracji. RulesManagerService działa w procesie serwera systemowego i przechowuje operacje aktualizacji strefy czasowej w pliku /data/misc/zoneinfo/staged. RulesManagerService może też zastępować i usuwać operacje, które zostały już skopiowane.
• TimeZoneUpdater, aplikacja systemowa, której nie można aktualizować (nazywana też aplikacją aktualizującą). Producenci OEM muszą uwzględnić tę aplikację w systemie obrazu urządzeń korzystających z tej funkcji.
• OEM TimeZoneData, aktualizująca się aplikacja systemowa (zwaną aplikacją danych), która przesyła pliki dystrybucyjne na urządzenie i czyni je dostępnymi dla aplikacji Aktualizator. Producenci OEM muszą uwzględnić tę aplikację w pliku obrazu systemu urządzeń korzystających z tej funkcji.
• tzdatacheck, binarny plik binarny wymagany do prawidłowego i bezpiecznego działania aktualizacji strefy czasowej.

Drzewo kodu źródłowego Androida zawiera ogólny kod źródłowy powyższych komponentów, którego OEM może używać bez wprowadzania zmian. Podany jest kod testowy, który umożliwia producentom OEM automatyczne sprawdzanie, czy prawidłowo włączyli tę funkcję.

Instalacja Distro

Proces instalacji dystrybucji obejmuje te kroki:

1. Aplikacja do obsługi danych jest aktualizowana przez pobranie z sklepu z aplikacjami lub przez sideload. Proces serwera systemowego (poprzez klasy timezone.RulesManagerServer/timezone.PackageTracker) sprawdza, czy zmieniła się skonfigurowana nazwa pakietu aplikacji danych, która jest specyficzna dla OEM.
   
   

   Rysunek 1. Aktualizacje aplikacji obsługującej dane.

2. Proces serwera systemowego uruchamia sprawdzanie aktualizacji, wysyłając do aplikacji Updater ukierunkowane działanie z użyciem unikalnego tokena jednorazowego. Serwer systemowy śledzi ostatni wygenerowany token, aby móc określić, kiedy zakończyło się ostatnie uruchomione przez niego sprawdzanie. Pozostałe tokeny są ignorowane.
   
   

   Rysunek 2. Sprawdzanie aktualizacji.

3. Podczas sprawdzania dostępności aktualizacji aplikacja Updater wykonuje te czynności:
   • Wykonuje zapytanie o bieżący stan urządzenia przez wywołanie usługi RulesManagerService.
     
     

     Rysunek 3. Aktualizacje danych aplikacji, wywołanie interfejsu RulesManagerService.

   • Odpytuje aplikację Data, wysyłając zapytanie o dobrze zdefiniowany adres URL i specyfikację kolumny ContentProvider, aby uzyskać informacje o dystrybucji.
     
     

     Rysunek 4. Aktualizacje aplikacji z danymi – otrzymuj informacje o distro.

4. Aplikacja Updater podejmuje odpowiednie działania na podstawie posiadanych informacji. Dostępne działania:
   • Poproś o instalację. Dane dystrybucji są odczytywane z aplikacji Data i przekazywane do usługi RulesManagerService na serwerze systemowym. UsługaRulesManagerService sprawdza ponownie, czy wersja i zawartość formatu distro są odpowiednie dla urządzenia, i etap instalacji.
   • Poproś o odinstalowanie (to rzadkie). Na przykład jeśli zaktualizowany plik APK w folderze /data zostanie wyłączony lub odinstalowany, urządzenie wróci do wersji w folderze /system.
   • Nic nie rób. Występuje, gdy dystrybucja aplikacji danych jest nieprawidłowa.
   We wszystkich przypadkach aplikacja Updater wywołuje usługę RulesManagerService z tokenem sprawdzania, aby serwer systemu wiedział, że sprawdzenie zostało zakończone i było udane.
   
   

   Rysunek 5. Sprawdzanie zakończone.

5. Uruchom ponownie i sprawdź tzdatacheck. Gdy urządzenie zostanie ponownie uruchomione, binarne dane tzdatacheck wykonają wszystkie etapowe operacje. Plik binarny tzdatacheck może wykonywać te zadania:
   • Wykonaj etapową operację, tworząc, zastępując lub usuwając pliki /data/misc/zoneinfo/current, zanim inne komponenty systemu je otworzą i zaczną z nich korzystać.
   • Sprawdź, czy pliki w folderze /data są odpowiednie dla bieżącej wersji platformy. Może się tak nie zdarzyć, jeśli urządzenie zostało właśnie zaktualizowane i zmieniła się wersja formatu dystrybucji.
   • Sprawdź, czy wersja reguł IANA jest taka sama jak wersja w /system lub nowsza. Zapobiega to sytuacji, w której aktualizacja systemu pozostawia na urządzeniu starsze dane dotyczące zasad strefy czasowej niż te, które są obecne na obrazie /system.

Niezawodność

Proces instalacji od początku do końca jest asynchroniczny i dzieli się na 3 procesy operacyjne. W dowolnym momencie instalacji urządzenie może stracić zasilanie, zabraknąć miejsca na dysku lub wystąpić inne problemy, które spowodują niepełną instalację. W najlepszym przypadku aplikacja Updater informuje serwer systemu, że nie udało się; w najgorszym przypadku usługa RulesManagerService nie otrzymuje wcale wywołania.

W tym celu kod serwera systemu śledzi, czy wywołane sprawdzenie aktualizacji zostało zakończone, oraz jaki jest kod ostatniej sprawdzonej wersji aplikacji Data. Gdy urządzenie jest nieaktywne i ładuje się, kod serwera systemu może sprawdzić jego bieżący stan. Jeśli wykryje niepełną weryfikację aktualizacji lub nieoczekiwaną wersję aplikacji, spontanicznie uruchamia sprawdzanie aktualizacji.

Bezpieczeństwo

Gdy ta opcja jest włączona, kod RulesManagerService na serwerze systemu wykonuje kilka testów, aby upewnić się, że system można bezpiecznie używać.

• Problemy wskazujące na źle skonfigurowany obraz systemu uniemożliwiają uruchomienie urządzenia. Przykłady to zła konfiguracja aplikacji Data lub Updater lub brak aplikacji Data lub Updater w /system/priv-app.
• Problemy wskazujące na zainstalowanie wadliwej aplikacji Data nie uniemożliwiają uruchamiania urządzenia, ale uniemożliwiają wywołanie sprawdzania aktualizacji. Przykłady takich problemów to brak wymaganych uprawnień systemowych lub brak w aplikacji Data ContentProvider o oczekiwanym identyfikatorze URI.

Uprawnienia plików w folderach /data/misc/zoneinfo są egzekwowane za pomocą reguł SELinux. Podobnie jak w przypadku innych plików APK, aplikacja danych musi być podpisana tym samym kluczem, który został użyty do podpisania wersji /system/priv-app. Aplikacja Data powinna mieć nazwę i klucz pakietu przeznaczone dla konkretnego OEM.

Integracja aktualizacji strefy czasowej

Aby włączyć funkcję aktualizacji strefy czasowej, producenci OEM zwykle:

• tworzyć własne aplikacje danych.
• Uwzględnij aplikacje Updater i Data w wersji obrazu systemu.
• Skonfiguruj serwer systemowy, aby włączyć usługę RulesManagerService.

Przygotowanie

Zanim producenci OEM powinni zapoznać się z tymi zasadami, zapewnianiem jakości i zabezpieczeniami:

• Utwórz dla aplikacji Data klucz podpisywania przeznaczony dla tej aplikacji.
• Utwórz strategię dotyczącą wersji i obsługi wersji dla aktualizacji strefy czasowej, aby dowiedzieć się, które urządzenia będą aktualizowane i jak zapewnić, że aktualizacje będą instalowane tylko na urządzeniach, które ich potrzebują. Na przykład producenci OEM mogą chcieć mieć jedną aplikację do obsługi danych na wszystkich swoich urządzeniach lub mogą mieć różne aplikacje do zarządzania danymi dla różnych urządzeń. Ta decyzja wpływa na wybór nazwy pakietu, ewentualnie kodów wersji i strategii kontroli jakości.
• Dowiedz się, czy chcą używać domyślnych danych strefy czasowej Androida z AOSP, czy utworzyć własne.

Utwórz aplikację do zarządzania danymi

AOSP zawiera cały kod źródłowy i reguły kompilacji potrzebne do utworzenia aplikacji Data w pliku packages/apps/TimeZoneData, a także instrukcje i przykładowe szablony pliku AndroidManifest.xml i innych plików znajdujących się w pliku packages/apps/TimeZoneData/oem_template. Przykładowe szablony zawierają zarówno cel kompilacji dla rzeczywistego pakietu APK aplikacji z danymi, jak i dodatkowe cele do tworzenia testowych wersji aplikacji Data.

OEM może dostosować aplikację Dane, dodając do niej własną ikonę, nazwę, tłumaczenia i inne szczegóły. Aplikacji Data nie można jednak uruchomić, więc ikona jest widoczna tylko na ekranie Ustawienia > Aplikacje.

Aplikacja Data powinna zostać utworzona w kompilacji tapas, która tworzy pliki APK odpowiednie do dodania do obrazu systemu (w pierwszej wersji) oraz podpisane i rozpowszechnione w sklepie z aplikacjami (w przypadku kolejnych aktualizacji). Szczegółowe informacje o używaniu tapas znajdziesz w artykule Tworzenie aplikacji Data za pomocą tapas.

Producenci OEM muszą zainstalować aplikację Data w systemie w ramach obrazu systemu urządzenia w /system/priv-app. Aby uwzględnić w pliku obrazu systemu gotowe pliki APK (wygenerowane przez proces kompilacji tapas), producenci OEM mogą skopiować przykładowe pliki z folderu packages/apps/TimeZoneData/oem_template/data_app_prebuilt. Przykładowe szablony zawierają też cele kompilacji, które umożliwiają uwzględnienie testowych wersji aplikacji Data w zestawach testów.

Dołącz aplikacje Updater i Data do obrazu systemu

OEM musi umieścić pliki APK aktualizatora i aplikacji Data w katalogu /system/priv-app obrazu systemu. Aby to zrobić, kompilacja obrazu systemu musi wyraźnie zawierać gotowe cele aplikacji aktualizatora i aplikacji Data.

Aplikacja Updater powinna być podpisana kluczem platformy i dołączona jako dowolna inna aplikacja systemowa. Docelowy obiekt jest zdefiniowany w packages/apps/TimeZoneUpdater jako TimeZoneUpdater. Uwzględnianie aplikacji z danymi zależy od OEM i od nazwy docelowej wybranej dla wstępnej kompilacji.

Konfigurowanie serwera systemowego

Aby umożliwić aktualizacje strefy czasowej, producenci OEM mogą skonfigurować serwer systemu, zastępując właściwości konfiguracji zdefiniowane w frameworks/base/core/res/res/values/config.xml.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Zastąpienia konfiguracji powinny znajdować się w obrazie systemu (a nie w urządzeniu lub innym), ponieważ urządzenie z nieprawidłowo skonfigurowaną konfiguracją może się nie uruchomić. Jeśli zastąpienia konfiguracji znajdują się w obrazie dostawcy, aktualizacja do obrazu systemu bez aplikacji danych (lub z innymi nazwami aplikacji z danymi bądź pakietów aplikacji aktualizatora) zostanie uznana za błędną konfigurację.

Testowanie xTS

xTS to dowolny pakiet testów OEM, który jest podobny do standardowych pakietów testów Androida korzystających z Tradefed (takich jak CTS i VTS). Producenci OEM, którzy mają takie pakiety testów, mogą dodać testy aktualizacji strefy czasowej Androida dostępne w tych miejscach:

• packages/apps/TimeZoneData/testing/xts zawiera kod potrzebny do podstawowego automatycznego testowania funkcjonalności.
• packages/apps/TimeZoneData/oem_template/xts zawiera przykładową strukturę katalogów do uwzględnienia testów w pakiecie xTS przypominającym Tradefed. Podobnie jak w przypadku innych katalogów szablonów, producenci OEM powinni skopiować i dostosowywać katalogi do swoich potrzeb.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt zawiera konfigurację na etapie kompilacji, która umożliwia uwzględnienie wymaganych w ramach testu gotowych plików APK.

Tworzenie aktualizacji strefy czasowej

Gdy IANA udostępni nowy zbiór reguł stref czasowych, zespół odpowiedzialny za główne biblioteki Androida generuje poprawki, aby zaktualizować wersje w AOSP. OEM, którzy używają licencjonowanego systemu Android i plików dystro, mogą wykonać te zatwierdzenia, a następnie wykorzystać je do utworzenia nowej wersji aplikacji Data, a potem opublikować nową wersję, aby zaktualizować urządzenia w środowisku produkcyjnym.

Aplikacje Data zawierają pliki dystrybucji ściśle powiązane z wersjami Androida, dlatego producenci OEM muszą utworzyć nową wersję aplikacji Data dla każdej obsługiwanej wersji Androida, którą chcą zaktualizować. Jeśli na przykład producent OEM chce udostępniać aktualizacje dla urządzeń z Androidem 8.1, 9 i 10, musi wykonać ten proces trzykrotnie.

Krok 1. Zaktualizuj pliki danych system/timezone i external/icu

Na tym etapie producenci OEM pobierają zatwierdzenia Androida dla systemu system/timezone i external/icu z gałęzi release-dev w AOSP, a następnie stosują je do swojej kopii kodu źródłowego Androida.

Aktualizacja AOSP systemu/strefy czasowej zawiera zaktualizowane pliki w folderach system/timezone/input_data i system/timezone/output_data. Producenci OEM, którzy muszą wprowadzić dodatkowe poprawki lokalne, mogą zmodyfikować pliki wejściowe, a następnie użyć plików w folderach system/timezone/input_data i external/icu do wygenerowania plików w folderze output_data.

Najważniejszym plikiem jest system/timezone/output_data/distro/distro.zip, który jest automatycznie dołączany podczas kompilowania pliku APK aplikacji danych.

Krok 2. Zaktualizuj kod wersji aplikacji Dane

Na tym etapie producenci OEM aktualizują kod wersji aplikacji Data. Kompilacja automatycznie pobiera distro.zip, ale nowa wersja aplikacji Data musi mieć nowy kod wersji, dzięki czemu jest ona rozpoznawana jako nowa i służy do zastąpienia wstępnie wczytanej aplikacji z danymi lub aplikacji do zarządzania danymi zainstalowanej na urządzeniu poprzedniej aktualizacji.

Gdy tworzysz aplikację Data przy użyciu plików skopiowanych z package/apps/TimeZoneData/oem_template/data_app, kod wersji i nazwę wersji zastosowanej do pliku APK znajdziesz w Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Podobne wpisy można znaleźć w pliku testing/Android.mk (jednak kody najnowszych wersji muszą być wyższe niż wersja obrazu systemu). Więcej informacji znajdziesz w schemacie przykładowej strategii kodu wersji. Jeśli używasz tego schematu lub podobnego, nie musisz aktualizować testowych kodów wersji, ponieważ są one z założenia wyższe niż rzeczywiste kody wersji.

Krok 3. Odbuduj, podpisz, przetestuj i opublikuj aplikację

Na tym etapie OEM ponownie tworzą plik APK za pomocą narzędzia tapas, podpisują wygenerowany plik APK, a następnie testują i publikują plik APK:

• W przypadku nieopublikowanych urządzeń (lub podczas przygotowywania aktualizacji systemu dla już opublikowanego urządzenia) prześlij nowe pliki APK w gotowym katalogu aplikacji Data, aby mieć pewność, że obraz systemu i testy xTS zawierają najnowsze pliki APK. OEM powinien sprawdzić, czy nowy plik działa prawidłowo (to znaczy, że przechodzi test CTS oraz wszystkie automatyczne i ręczne testy dotyczące OEM).
• W przypadku opublikowanych urządzeń, które nie otrzymują już aktualizacji systemu, podpisany plik APK może być udostępniany tylko w sklepie z aplikacjami.

Producenci OEM są odpowiedzialni za zapewnienie jakości i testowanie zaktualizowanej aplikacji Data na swoich urządzeniach przed jej wydaniem.

Strategia dotycząca kodu wersji aplikacji danych

Aplikacja Data musi mieć odpowiednią strategię wersjonowania, aby zapewnić, że na urządzeniach będą instalowane prawidłowe pliki APK. Jeśli na przykład aktualizacja systemu zawiera starszy plik APK niż jeden pobrany ze sklepu z aplikacjami, należy zachować wersję ze sklepu z aplikacjami.

Kod wersji pliku APK powinien zawierać te informacje:

• Wersja w formacie dystrybucji (główna + podrzędna)
• przyrostowy (nieprzejrzysty) numer wersji;

Obecnie poziom interfejsu API platformy jest silnie powiązany z wersją formatu dystrybucji, ponieważ każdy poziom API jest zwykle powiązany z nową wersją ICU (co powoduje, że pliki dystrybucji są ze sobą niezgodne). W przyszłości Android może zmienić ten sposób, aby plik dystrybucji działał na wielu wersjach platformy Android (a poziom interfejsu API nie jest używany w schemacie kodu wersji aplikacji danych).

Przykładowa strategia dotycząca kodu wersji

Ten przykładowy schemat numeracji zapewnia, że nowsze wersje formatu dystrybucji zastępują starsze wersje formatu dystrybucji. AndroidManifest.xml używa android:minSdkVersion, aby zapewnić, że starsze urządzenia nie otrzymują wersji o wyższej wersji formatu dystrybucji, niż mogą obsłużyć.

Rysunek 6. Przykładowa strategia dotycząca kodu wersji.

Schemat można by lepiej skompresować, gdyby zamiast liczby dziesiętnej użyto liczby binarnej, ale ma on tę zaletę, że jest zrozumiały dla człowieka. Jeśli cały zakres liczby zostanie wyczerpany, nazwa pakietu aplikacji danych może się zmienić.

Nazwa wersji to czytelna dla człowieka reprezentacja szczegółów, na przykład major=001,minor=001,iana=2017a, revision=1,respin=2. Przykłady podano w tabeli poniżej.

• Przykłady 1 i 2 pokazują 2 wersje pliku APK dla tej samej wersji IANA 2017a z różnymi głównymi wersjami formatu. 2 jest liczbowo większa od 1, co jest potrzebne, aby nowsze urządzenia otrzymywały nowsze wersje formatu. Wartość minSdkVersion sprawia, że wersja P nie zostanie dostarczona na urządzenia O.
• Przykład 3 to wersja poprawiona przykładu 1, która jest większa od niego pod względem liczbowym.
• Przykłady 4 i 5 pokazują wersje 2017b dla wersji O-MR1 i P. Mają wyższe numery i zastępują poprzednie wersje IANA lub Androida.
• Przykłady 6 i 7 pokazują wersje 2018a dla wersji O-MR1 i P.
• Przykład 8 pokazuje użycie wartości Y do całkowitego zastąpienia schematu Y=0.
• Przykład 9 pokazuje, jak wykorzystać przerwę między krokami 3 i 4, aby ponownie skompilować plik APK.

Każde urządzenie jest dostarczane z domyślnym plikiem APK z odpowiednią wersją w obrazie systemu, więc nie ma ryzyka, że na urządzeniu z Androidem P zostanie zainstalowana wersja O-MR1, ponieważ ma ona niższą numerację niż obraz systemu w wersji P. Urządzenie z zainstalowaną wersją O-MR1 w /data, które następnie otrzyma aktualizację systemu do wersji P, będzie używać wersji /system zamiast wersji O-MR1 w  /data, ponieważ wersja P jest zawsze nowsza niż dowolna aplikacja przeznaczona dla wersji O-MR1.

Tworzenie aplikacji Data za pomocą tapas

Producenci OEM są odpowiedzialni za zarządzanie większością aspektów aplikacji danych strefy czasowej i prawidłowe skonfigurowanie obrazu systemu. Aplikacja Data ma zostać utworzona w kompilacji tapas, która tworzy pliki APK odpowiednie do dodania do obrazu systemu (w pierwszej wersji) oraz podpisane i rozpowszechnione w sklepie z aplikacjami (w przypadku kolejnych aktualizacji).

Tapas to oszczędna wersja systemu kompilacji Androida, która wykorzystuje ograniczone drzewo źródłowe do tworzenia możliwych do rozpowszechniania wersji aplikacji. OEM, którzy znają zwykły system kompilacji Androida, powinni rozpoznawać pliki kompilacji z normalnej kompilacji platformy Androida.

Tworzenie pliku manifestu

Zmniejszenie drzewa źródłowego można zwykle uzyskać za pomocą niestandardowego pliku manifestu, który odnosi się tylko do projektów Git wymaganych przez system kompilacji i do budowania aplikacji. Po wykonaniu instrukcji z artykułu Tworzenie aplikacji z danymi producenci OEM powinni mieć co najmniej 2 projekty Git typowe dla OEM utworzone przy użyciu plików szablonów w packages/apps/TimeZoneData/oem_template:

• Jeden projekt Git zawiera pliki aplikacji, takie jak manifest i pliki kompilacji wymagane do utworzenia pliku APK aplikacji (np. vendor/oem/apps/TimeZoneData). Zawiera on też reguły kompilacji plików APK testowych, których można używać w testach xTS.
• Jeden projekt Git zawiera podpisane pliki APK utworzone przez kompilację aplikacji na potrzeby uwzględnienia w kompilacji obrazu systemu i testów xTS.

Kompilacja aplikacji korzysta z kilku innych projektów Git, które są udostępniane z kompilacją platformy lub zawierają biblioteki kodu niezależne od OEM.

Ten fragment kodu manifestu zawiera minimalny zestaw projektów Git wymaganych do obsługi kompilacji O-MR1 aplikacji Data strefy czasowej. OEM musi dodać do tego pliku manifestu swoje projekty Git specyficzne dla OEM (które zwykle zawierają projekt zawierający certyfikat podpisywania) i mogą odpowiednio konfigurować różne gałęzie.

   <!-- 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" />

Uruchom kompilację tapas

Po utworzeniu drzewa źródłowego wywołaj kompilację tapas, używając tych poleceń:

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

Pomyślnie utworzone kompilacje generują pliki w katalogu out/dist na potrzeby testowania. Pliki te można umieścić w katalogu z preinstalowanymi plikami, aby uwzględnić je w pliku obrazu systemu lub rozpowszechnić w sklepie z aplikacjami na zgodne urządzenia.