Reguły stref czasowych

Android 10 wycofuje mechanizm aktualizacji danych strefy czasowej oparty na plikach APK (dostępny w Androidzie 8.1 i 9) i zastępuje go mechanizmem aktualizacji modułów opartym na APEX. Wersje AOSP od 8.1 do 13 nadal zawierają kod platformy niezbędny producentom OEM do włączania aktualizacji opartych na plikach APK, więc urządzenia, które zostaną zaktualizowane do Androida 10, nadal będą mogły otrzymywać aktualizacje danych o strefach czasowych dostarczane przez partnerów za pomocą plików APK. Mechanizmu aktualizacji APK nie należy jednak używać na urządzeniu produkcyjnym, które otrzymuje też aktualizacje modułów, ponieważ aktualizacja oparta na APK zastępuje aktualizację opartą na APEX (czyli urządzenie, które otrzymało aktualizację APK, będzie ignorować aktualizacje oparte na APEX).

Aktualizacje stref czasowych (Android 10 i nowsze)

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

Aktualizacje przebiegają w ten sposób:

1. IANA wydaje aktualizację bazy danych stref czasowych w odpowiedzi na zmianę przez co najmniej 1 rząd reguły strefy czasowej w danym kraju.
2. Google lub partner Androida przygotowuje aktualizację modułu danych stref czasowych (plik APEX) zawierającą zaktualizowane strefy czasowe.
3. Urządzenie użytkownika pobiera aktualizację, ponownie się uruchamia i wprowadza zmiany. Po tym procesie dane strefy czasowej urządzenia zawierają nowe dane strefy czasowej z aktualizacji.

Więcej informacji o modułach znajdziesz w sekcji Komponenty systemu modułowego.

Aktualizacje stref czasowych (Android 8.1–9)

Uwaga: funkcja mechanizmu aktualizacji danych strefy czasowej opartego na pliku APK została całkowicie usunięta z Androida 14 i nie można jej znaleźć w kodzie źródłowym. Partnerzy powinni w pełni przejść na moduł główny Strefa czasowa.

W Androidzie 8.1 i Androidzie 9 producenci OEM mogą używać mechanizmu opartego na plikach APK do przesyłania zaktualizowanych danych reguł stref czasowych na urządzenia bez konieczności aktualizowania systemu. Ten mechanizm umożliwia użytkownikom otrzymywanie aktualnych informacji (co wydłuża okres użytkowania urządzenia z Androidem), a partnerom Androida – testowanie aktualizacji stref czasowych niezależnie od aktualizacji obrazu systemu.

Zespół bibliotek podstawowych Androida udostępnia niezbędne pliki danych do aktualizowania reguł stref czasowych na urządzeniu z czystym Androidem. Producenci OEM mogą używać tych plików danych podczas tworzenia aktualizacji stref czasowych na swoich urządzeniach lub w razie potrzeby tworzyć własne pliki danych. W każdym przypadku producenci OEM zachowują kontrolę nad zapewnieniem jakości/testowaniem, harmonogramem i wprowadzaniem aktualizacji reguł stref czasowych na obsługiwanych urządzeniach.

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

Wszystkie urządzenia z Androidem, nawet te, które nie korzystają z tej funkcji, potrzebują danych reguł stref czasowych i muszą być dostarczane z domyślnym zestawem danych reguł stref czasowych 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/ (np. java.util.TimeZone) korzysta z plików tzdata i tzlookup.xml.
• Kod biblioteki natywnej w bionic/ (np. w przypadku mktime, wywołań systemowych localtime) korzysta z pliku tzdata.
• Kod biblioteki ICU4J/ICU4C w external/icu/ korzysta z pliku icu.dat.

Biblioteki te ś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 potrzebują danych reguł strefy czasowej, najpierw sprawdzają te lokalizacje:

• Kody libcore/ i bionic/ używają kopii plików /data, tzdata i tzlookup.xml.
• Kod ICU4J/ICU4C korzysta z plików w /data i w przypadku danych, których nie ma w tym folderze (np. formatów, zlokalizowanych ciągów znaków), przełącza się na pliki w /system.

Pliki dystrybucji

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

Format pliku dystrybucyjnego zależy od wersji Androida, ponieważ zawartość zmienia się wraz z wersją ICU, wymaganiami platformy Android i innymi zmianami w wersji. Android udostępnia pliki dystrybucyjne dla obsługiwanych wersji Androida przy każdej aktualizacji IANA (oprócz aktualizowania plików systemowych platformy). Aby aktualizować urządzenia, producenci OEM mogą używać tych plików dystrybucyjnych lub tworzyć własne, korzystając z drzewa źródłowego Androida (które zawiera skrypty i inne pliki potrzebne do generowania plików dystrybucyjnych).

Komponenty aktualizacji strefy czasowej

Aktualizacja reguł strefy czasowej obejmuje przesyłanie plików dystrybucyjnych na urządzenie i bezpieczną instalację zawartych w nich plików. Przeniesienie i instalacja wymagają:

• funkcjonalność usługi platformy (timezone.RulesManagerService), która jest domyślnie wyłączona; Producenci OEM muszą włączyć tę funkcję za pomocą konfiguracji. RulesManagerService działa w procesie serwera systemowego i przygotowuje operacje aktualizacji strefy czasowej, zapisując je w /data/misc/zoneinfo/staged. RulesManagerService może też zastępować lub usuwać operacje, które zostały już przygotowane.
• TimeZoneUpdater, nieaktualizowalna aplikacja systemowa (czyli aplikacja do aktualizacji); Producenci OEM muszą uwzględnić tę aplikację w obrazie systemu urządzeń korzystających z tej funkcji.
• OEM TimeZoneData, aktualizowana aplikacja systemowa (czyli aplikacja do przesyłania danych), która przesyła pliki dystrybucyjne na urządzenie i udostępnia je aplikacji do aktualizacji. Producenci OEM muszą uwzględnić tę aplikację w obrazie systemu na urządzeniach korzystających z tej funkcji.
• tzdatacheck, czyli plik binarny uruchamiany podczas rozruchu, który jest wymagany do prawidłowego i bezpiecznego działania aktualizacji strefy czasowej.

Drzewo źródłowe Androida zawiera ogólny kod źródłowy powyższych komponentów, z którego OEM może korzystać bez modyfikacji. Kod testowy jest udostępniany, aby umożliwić producentom OEM automatyczne sprawdzanie, czy funkcja została włączona prawidłowo.

Instalacja dystrybucji

Proces instalacji dystrybucji obejmuje te kroki:

1. Aplikacja do przesyłania danych jest aktualizowana przez pobranie ze sklepu z aplikacjami lub zainstalowanie z pliku. Proces serwera systemowego (za pomocą klas timezone.RulesManagerServer/timezone.PackageTracker) monitoruje zmiany w skonfigurowanej nazwie pakietu aplikacji danych specyficznej dla OEM.
   
   

   Rysunek 1. Aktualizacje aplikacji do obsługi danych.

2. Proces serwera systemowego wywołuje sprawdzenie aktualizacji, przesyłając do aplikacji do aktualizacji ukierunkowany zamiar z unikalnym tokenem jednorazowym. Serwer systemowy śledzi ostatni wygenerowany token, aby określić, kiedy zakończyło się ostatnie wywołane przez niego sprawdzenie. Wszystkie inne tokeny są ignorowane.
   
   

   Rysunek 2. Aktywuj sprawdzanie aktualizacji.

3. Podczas sprawdzania aktualizacji aplikacja Aktualizator wykonuje te czynności:
   • Wysyła zapytanie o bieżący stan urządzenia, wywołując RulesManagerService.
     
     

     Rysunek 3. Aktualizacje aplikacji do przesyłania danych wywołujące usługę RulesManagerService.

   • Wysyła zapytanie do aplikacji Data, wysyłając zapytanie do dobrze zdefiniowanego adresu URL ContentProvider i specyfikacji kolumn, aby uzyskać informacje o dystrybucji.
     
     

     Rysunek 4. Aktualizacje aplikacji do danych, informacje o dystrybucji.

4. Aplikacja Updater podejmuje odpowiednie działania na podstawie informacji, które ma. Dostępne działania:
   • Poproś o instalację. Dane dystrybucji są odczytywane z aplikacji Dane i przekazywane do usługi RulesManagerService na serwerze systemowym. Usługa RulesManagerService ponownie sprawdza, czy wersja i zawartość formatu dystrybucji są odpowiednie dla urządzenia, i przygotowuje instalację.
   • Poproś o odinstalowanie (rzadko). Na przykład jeśli zaktualizowany plik APK w /data jest wyłączany lub odinstalowywany, a urządzenie wraca do wersji obecnej w /system.
   • Nic nie rób. Występuje, gdy dystrybucja aplikacji do danych jest nieprawidłowa.
   W każdym przypadku aplikacja Updater wywołuje usługę RulesManagerService z tokenem weryfikacji, aby serwer systemowy wiedział, że weryfikacja została zakończona i przebiegła pomyślnie.
   
   

   Rysunek 5. Sprawdzanie zakończone.

5. Uruchom ponownie i sprawdź dane strefy czasowej. Przy następnym uruchomieniu urządzenia plik binarny tzdatacheck wykona wszystkie przygotowane operacje. Plik binarny tzdatacheck może wykonywać te zadania:
   • Wykonaj operację etapową, obsługując tworzenie, zastępowanie lub usuwanie plików /data/misc/zoneinfo/current, zanim inne komponenty systemu otworzą pliki i zaczną ich używać.
   • Sprawdź, czy pliki w /data są odpowiednie dla bieżącej wersji platformy. Może się tak nie stać, jeśli urządzenie właśnie otrzymało aktualizację systemu, a wersja formatu dystrybucji uległa zmianie.
   • Upewnij się, że wersja reguł IANA jest taka sama jak wersja w /system lub nowsza. Zapobiega to sytuacji, w której po aktualizacji systemu na urządzeniu pozostaną starsze dane reguł stref czasowych niż te, które znajdują się w /system obrazie.

Niezawodność

Proces instalacji od początku do końca jest asynchroniczny i rozłożony na 3 procesy systemu operacyjnego. W dowolnym momencie instalacji urządzenie może utracić zasilanie, zabraknąć na nim miejsca na dysku lub mogą wystąpić inne problemy, które spowodują, że sprawdzanie instalacji nie zostanie ukończone. W najlepszym przypadku niepowodzenia aplikacja Aktualizator informuje serwer systemowy o niepowodzeniu. W najgorszym przypadku niepowodzenia usługa RulesManagerService nie otrzymuje żadnego wywołania.

Aby to zrobić, kod serwera systemowego śledzi, czy wywołane sprawdzenie aktualizacji zostało zakończone i jaki jest ostatni sprawdzony kod wersji aplikacji do danych. Gdy urządzenie jest nieaktywne i się ładuje, kod serwera systemowego może sprawdzić bieżący stan. Jeśli wykryje niepełne sprawdzenie aktualizacji lub nieoczekiwaną wersję aplikacji Data App, spontanicznie uruchomi sprawdzenie aktualizacji.

Bezpieczeństwo

Gdy ta funkcja jest włączona, kod RulesManagerService na serwerze systemowym przeprowadza kilka kontroli, aby upewnić się, że system jest bezpieczny w użyciu.

• Problemy wskazujące na nieprawidłowo skonfigurowany obraz systemu uniemożliwiają uruchomienie urządzenia. Przykłady to nieprawidłowa konfiguracja aplikacji do aktualizacji lub aplikacji do danych albo brak aplikacji do aktualizacji lub aplikacji do danych w /system/priv-app.
• Problemy wskazujące, że zainstalowano nieprawidłową aplikację Data, nie uniemożliwiają uruchomienia urządzenia, ale uniemożliwiają wywołanie sprawdzania aktualizacji. Przykłady to brak wymaganych uprawnień systemowych lub brak dostawcy treści w aplikacji Data w oczekiwanym identyfikatorze URI.

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

Integrowanie aktualizacji stref czasowych

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

• tworzyć własne aplikacje do danych,
• Uwzględnij aplikacje Aktualizator i Dane w kompilacji obrazu systemu.
• Skonfiguruj serwer systemowy, aby włączyć usługę RulesManagerService.

Przygotowanie

Przed rozpoczęciem producenci OEM powinni zapoznać się z tymi zasadami, kwestiami związanymi z zapewnieniem jakości i bezpieczeństwem:

• utworzyć dedykowany klucz podpisywania aplikacji dla aplikacji do danych;
• Opracuj strategię wydawania i wersjonowania aktualizacji stref czasowych, aby wiedzieć, które urządzenia zostaną zaktualizowane i jak można się upewnić, że aktualizacje będą instalowane tylko na urządzeniach, które ich potrzebują. Na przykład producenci OEM mogą chcieć mieć jedną aplikację Dane na wszystkich swoich urządzeniach lub mogą zdecydować się na różne aplikacje Dane na różnych urządzeniach. Ta decyzja ma wpływ na wybór nazwy pakietu, prawdopodobnie na używane kody wersji i strategię kontroli jakości.
• Określ, czy chcą używać danych o strefie czasowej z Androida w wersji open source (AOSP), czy utworzyć własne.

Tworzenie aplikacji do obsługi danych

AOSP zawiera cały kod źródłowy i reguły kompilacji potrzebne do utworzenia aplikacji do danych w packages/apps/TimeZoneData, a także instrukcje i przykładowe szablony AndroidManifest.xml oraz inne pliki znajdujące się w packages/apps/TimeZoneData/oem_template. Przykładowe szablony obejmują zarówno cel kompilacji rzeczywistej aplikacji Data, jak i dodatkowe cele tworzenia wersji testowych tej aplikacji.

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

Aplikacja Data ma być tworzona za pomocą kompilacji tapas, która generuje pliki APK odpowiednie do dodania do obrazu systemu (w przypadku pierwszej wersji) oraz do podpisywania i dystrybuowania w sklepie z aplikacjami (w przypadku kolejnych aktualizacji). Więcej informacji o używaniu tapas znajdziesz w artykule Tworzenie aplikacji do obsługi danych za pomocą tapas.

Producenci OEM muszą zainstalować gotową aplikację Dane w obrazie systemu urządzenia w /system/priv-app. Aby uwzględnić w obrazie systemu wstępnie skompilowane pakiety APK (wygenerowane w procesie kompilacji tapas), producenci OEM mogą skopiować przykładowe pliki z packages/apps/TimeZoneData/oem_template/data_app_prebuilt. Przykładowe szablony zawierają też cele kompilacji, które umożliwiają uwzględnianie wersji testowych aplikacji Data w zestawach testów.

Uwzględnij aplikacje Updater i Data w obrazie systemu.

Producenci OEM muszą umieścić pliki APK aplikacji Updater i Data w katalogu /system/priv-app obrazu systemu. Aby to zrobić, kompilacja obrazu systemu musi wyraźnie zawierać wstępnie skompilowane elementy docelowe aplikacji Aktualizator i aplikacji Dane.

Aplikacja aktualizująca powinna być podpisana kluczem platformy i dołączona jako każda inna aplikacja systemowa. Cel jest zdefiniowany w zasadzie packages/apps/TimeZoneUpdater jako TimeZoneUpdater. Włączenie aplikacji do obsługi danych zależy od producenta OEM i wybranej nazwy docelowej dla wstępnej kompilacji.

Konfigurowanie serwera systemu

Aby włączyć aktualizacje strefy czasowej, producenci OEM mogą skonfigurować serwer systemowy, zastępując właściwości konfiguracyjne zdefiniowane w pliku 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 (nie w obrazie dostawcy ani w innym), ponieważ źle skonfigurowane urządzenie może odmówić uruchomienia. Jeśli zastąpienia konfiguracji znajdowały się w obrazie dostawcy, aktualizacja do obrazu systemu bez aplikacji do danych (lub z innymi nazwami pakietów aplikacji do danych lub aplikacji do aktualizacji) byłaby uznawana za nieprawidłową konfigurację.

Testowanie xTS

xTS to dowolny pakiet testów specyficzny dla producenta 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 zestawy testów, mogą dodać testy aktualizacji strefy czasowej Androida dostępne w tych lokalizacjach:

• packages/apps/TimeZoneData/testing/xts zawiera kod potrzebny do podstawowych zautomatyzowanych testów funkcjonalnych.
• packages/apps/TimeZoneData/oem_template/xts zawiera przykładową strukturę katalogów do uwzględniania testów w pakiecie xTS podobnym do Tradefed. Podobnie jak w przypadku innych katalogów szablonów, producenci OEM powinni kopiować i dostosowywać szablony do swoich potrzeb.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt zawiera konfigurację czasu kompilacji, która umożliwia uwzględnienie wstępnie skompilowanych plików APK testu wymaganych przez test.

Tworzenie aktualizacji stref czasowych

Gdy IANA opublikuje nowy zestaw reguł stref czasowych, zespół bibliotek podstawowych Androida generuje poprawki, aby zaktualizować wersje w AOSP. Producenci OEM korzystający z czystego systemu Android i plików dystrybucji mogą pobrać te zmiany, użyć ich do utworzenia nowej wersji aplikacji do danych, a następnie udostępnić ją, aby zaktualizować urządzenia w produkcji.

Aplikacje do danych zawierają pliki dystrybucyjne ściśle powiązane z wersjami Androida, dlatego producenci OEM muszą tworzyć nową wersję aplikacji do danych dla każdej obsługiwanej wersji Androida, którą chcą zaktualizować. Jeśli na przykład producent OEM chce udostępniać aktualizacje na urządzenia z Androidem 8.1, 9 i 10, musi przejść ten proces 3 razy.

Krok 1. Zaktualizuj pliki danych systemowych/strefy czasowej i zewnętrznych/ICU

W tym kroku producenci OEM pobierają z gałęzi release-dev w AOSP zmiany w Androidzie w wersji podstawowej dotyczące system/timezone i external/icu i stosują je do swojej kopii kodu źródłowego Androida.

Poprawka AOSP dotycząca 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ć ich w usługach system/timezone/input_data i external/icu, aby wygenerować pliki w usłudze output_data.

Najważniejszy plik to system/timezone/output_data/distro/distro.zip, który jest automatycznie dołączany podczas tworzenia pliku APK aplikacji Data.

Krok 2. Zaktualizuj kod wersji aplikacji do przesyłania danych

Na tym etapie producenci OEM aktualizują kod wersji aplikacji Dane. Kompilacja automatycznie wybiera distro.zip, ale nowa wersja aplikacji Dane musi mieć nowy kod wersji, aby była rozpoznawana jako nowa i używana do zastępowania preinstalowanej aplikacji Dane lub aplikacji Dane zainstalowanej na urządzeniu w ramach poprzedniej aktualizacji.

Podczas tworzenia aplikacji do danych za pomocą plików skopiowanych z package/apps/TimeZoneData/oem_template/data_app kod wersji lub nazwę wersji zastosowaną w pliku APK znajdziesz w Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Podobne wpisy znajdziesz w pliku testing/Android.mk (kody wersji testowej muszą być jednak wyższe niż wersja obrazu systemu). Szczegółowe informacje znajdziesz w przykładzie strategii kodów wersji. Jeśli używasz przykładowego schematu lub podobnego schematu, nie musisz aktualizować kodów wersji testowej, ponieważ na pewno będą one wyższe niż kody wersji rzeczywistej.

Krok 3. Ponownie skompiluj, podpisz, przetestuj i opublikuj

Na tym etapie producenci OEM ponownie kompilują plik APK za pomocą narzędzia Tapas, podpisują wygenerowany plik APK, a następnie testują i publikują go:

• W przypadku urządzeń, które nie zostały jeszcze wprowadzone na rynek (lub podczas przygotowywania aktualizacji systemu dla urządzenia, które zostało już wprowadzone na rynek), prześlij nowe pliki APK w wstępnie skompilowanym katalogu aplikacji Data, aby mieć pewność, że obraz systemu i testy xTS zawierają najnowsze pliki APK. Producenci OEM powinni sprawdzić, czy nowy plik działa prawidłowo (tzn. czy przechodzi testy CTS oraz wszelkie automatyczne i ręczne testy specyficzne dla producenta OEM).
• W przypadku urządzeń, które nie otrzymują już aktualizacji systemu, podpisany plik APK może być udostępniany tylko w sklepie z aplikacjami.

Producenci OEM odpowiadają za zapewnienie jakości i testowanie zaktualizowanej aplikacji Dane na swoich urządzeniach przed jej udostępnieniem.

Strategia kodu wersji aplikacji do przesyłania danych

Aplikacja Data musi mieć odpowiednią strategię określania wersji, aby urządzenia otrzymywały prawidłowe pliki APK. Jeśli na przykład otrzymasz aktualizację systemu, która zawiera starszy pakiet APK niż ten pobrany ze sklepu z aplikacjami, należy zachować wersję ze sklepu.

Kod wersji pliku APK powinien zawierać te informacje:

• Wersja formatu dystrybucji (główna + podrzędna)
• zwiększający się (nieprzezroczysty) numer wersji,

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

Przykładowa strategia kodu wersji

Ten schemat numerowania wersji zapewnia, że wyższe wersje formatu dystrybucji zastępują niższe wersje formatu dystrybucji. AndroidManifest.xml używa android:minSdkVersion, aby starsze urządzenia nie otrzymywały wersji o wyższym formacie dystrybucji, niż są w stanie obsłużyć.

Rysunek 6. Przykładowa strategia kodu wersji.

Schemat można by lepiej upakować, gdyby zamiast systemu dziesiętnego użyto binarnego, ale ten schemat ma tę zaletę, że jest czytelny dla człowieka. Jeśli wyczerpie się pełny zakres numerów, nazwa pakietu aplikacji Dane może ulec zmianie.

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

• Przykłady 1 i 2 pokazują 2 wersje pliku APK dla tej samej wersji IANA z 2017 r. z różnymi głównymi wersjami formatu. 2 jest liczbowo większe od 1, co jest potrzebne, aby zapewnić, że nowsze urządzenia będą otrzymywać nowsze wersje formatu. Wartość minSdkVersion zapewnia, że wersja P nie będzie dostarczana na urządzenia z Androidem O.
• Przykład 3 jest poprawioną wersją przykładu 1 i ma wyższy numer.
• Przykłady 4 i 5 pokazują wersje 2017b dla O-MR1 i P. Są one wyższe numerycznie od poprzednich wersji IANA i Androida, więc zastępują swoich poprzedników.
• Przykłady 6 i 7 pokazują wersje 2018a dla O-MR1 i P.
• Przykład 8 pokazuje, jak użyć parametru Y, aby całkowicie zastąpić schemat Y=0.
• Przykład 9 pokazuje, jak wykorzystać lukę między wersjami 3 i 4 do ponownego przesłania pliku APK.

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

Tworzenie aplikacji Data za pomocą tapas

Producenci OEM odpowiadają za zarządzanie większością aspektów aplikacji Dane strefy czasowej i za prawidłowe skonfigurowanie obrazu systemu. Aplikacja Data ma być tworzona za pomocą kompilacji tapas, która generuje pliki APK odpowiednie do dodania do obrazu systemu (w przypadku pierwszej wersji) oraz do podpisywania i dystrybucji w sklepie z aplikacjami (w przypadku kolejnych aktualizacji).

Tapas to uproszczona wersja systemu kompilacji Androida, która wykorzystuje mniejsze drzewo źródłowe do tworzenia wersji aplikacji przeznaczonych do dystrybucji. Producenci OEM, którzy znają standardowy system kompilacji Androida, powinni rozpoznać pliki kompilacji ze standardowej kompilacji platformy Android.

Tworzenie pliku manifestu

Zredukowane drzewo źródłowe uzyskuje się zwykle za pomocą niestandardowego pliku manifestu, który odwołuje się tylko do projektów Git potrzebnych systemowi kompilacji i do kompilacji aplikacji. Po wykonaniu instrukcji w artykule Tworzenie aplikacji do obsługi danych producenci OEM powinni mieć co najmniej 2 projekty Git specyficzne dla OEM utworzone przy użyciu plików szablonów w folderze 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). Projekt ten zawiera też reguły kompilacji plików APK testów, które mogą być używane przez testy xTS.
• Jeden projekt Git zawiera podpisane pliki APK wygenerowane przez kompilację aplikacji do uwzględnienia w kompilacji obrazu systemu i testach xTS.

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

Poniższy fragment pliku manifestu zawiera minimalny zestaw projektów Git niezbędnych do obsługi kompilacji O-MR1 aplikacji Data dotyczącej stref czasowych. Producenci OEM muszą dodać do tego pliku manifestu projekty Git specyficzne dla OEM (które zwykle obejmują projekt zawierający certyfikat podpisywania) i mogą odpowiednio skonfigurować 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" />

Uruchomienie kompilacji Tapas

Po utworzeniu drzewa źródłowego wywołaj kompilację tapas za pomocą tych poleceń:

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

Pomyślna kompilacja generuje pliki w katalogu out/dist na potrzeby testowania. Te pliki można umieścić w katalogu prebuilts, aby uwzględnić je w obrazie systemu lub rozpowszechniać w sklepie z aplikacjami na zgodnych urządzeniach.