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. Wersje AOSP 8.1–13 nadal zawierają kod platformy, który umożliwia producentom OEM włączanie aktualizacji opartych na pliku APK. Dzięki temu urządzenia przechodzące na Androida 10 nadal mogą otrzymywać aktualizacje danych stref czasowych udostępniane przez partnerów za pomocą pliku APK. Mechanizmu aktualizacji pakietu 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ę pliku 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 przygotowuje aktualizację modułu danych stref czasowych (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, a w źródle kodu nie można go znaleźć. 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 zasad 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ół odpowiedzialny za podstawowe biblioteki Androida udostępnia niezbędne pliki danych do aktualizowania zasad stref czasowych na standardowym urządzeniu z Androidem. Producenci OEM mogą używać tych plików danych podczas tworzenia aktualizacji stref czasowych dla swoich urządzeń lub mogą tworzyć własne pliki danych. W każdym przypadku producenci OEM mają kontrolę nad zapewnieniem jakości, testowaniem, czasem i publikowaniem 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 w 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 bionic/ (na przykład mktime, wywołania systemowe localtime) używa pliku tzdata.
• Kod biblioteki ICU4J/ICU4C w pliku external/icu/ używa 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 potrzebują danych reguł strefy czasowej, sprawdzają najpierw te lokalizacje:

• Kody libcore/ i bionic/ używają kopii /data plików tzdata i tzlookup.xml.
• Kod ICU4J/ICU4C używa plików w folderze /data, a w przypadku danych, których brakuje (np. formatów, lokalnych ciągów znaków), korzysta z plików w folderze /system.

Pliki dystrybucji

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 dystrybucyjnego zależy od wersji Androida, ponieważ jego zawartość zmienia się wraz z wersją ICU, wymaganiami platformy Android i innymi zmianami w 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 aktualizować swoje urządzenia, producenci OEM mogą używać tych plików dystrybucyjnych lub tworzyć własne za pomocą 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 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 obrazów urządzeń, które korzystają z tej funkcji.
• OEM TimeZoneData, aktualizująca aplikacja systemowa (zwaną aplikacją danych), która przenosi 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 rozruchowy wymagany do prawidłowego i bezpiecznego działania aktualizacji strefy czasowej.

Drzewo kodu źródłowego Androida zawiera ogólny kod źródłowy wymienionych powyżej komponentów, którego producent OEM może używać bez wprowadzania zmian. Kod testowy jest udostępniany, aby umożliwić producentom OEM automatyczne sprawdzanie, czy włączyli tę funkcję prawidłowo.

Instalacja Distro

Proces instalacji dystrybucji obejmuje te kroki:

1. Aplikacja do obsługi danych jest aktualizowana przez pobranie z sklepu z aplikacjami lub za pomocą 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 do obsługi danych.

2. Proces serwera systemowego uruchamia sprawdzanie aktualizacji, wysyłając do aplikacji Updater ukierunkowany zamiar z unikalnym tokenem jednorazowego użytku. Serwer systemowy śledzi ostatni wygenerowany token, aby móc określić, kiedy zakończyło się ostatnie sprawdzenie, które zostało przez niego wywołane. Inne tokeny są ignorowane.
   
   

   Rysunek 2. Sprawdzanie aktualizacji.

3. Podczas sprawdzania dostępności aktualizacji aplikacja Updater wykonuje te czynności:
   • Wysyła zapytanie o obecny stan urządzenia, wywołując usługę RulesManagerService.
     
     

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

   • Wysyła zapytanie do aplikacji Data, aby uzyskać informacje o dystrybucji. W tym celu wysyła zapytanie do dobrze zdefiniowanego adresu URL dostawcy treści i specyfikacji kolumny.
     
     

     Rysunek 4. Aktualizacje aplikacji danych, informacje o dystrybucji.

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ługa RulesManagerService ponownie sprawdza, czy wersja i treść formatu dystrybucji są odpowiednie dla urządzenia, a następnie przygotowuje instalację.
   • 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 pomyślne.
   
   

   Rysunek 5. Sprawdzanie zakończone.

5. Uruchom ponownie i sprawdź tzdatacheck. Gdy urządzenie zostanie ponownie uruchomione, binarne dane tzdatacheck wykonają wszystkie operacje etapowe. 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.
   • Upewnij się, że wersja zasad IANA jest taka sama lub nowsza niż wersja w /system. Zapobiega to sytuacji, w której aktualizacja systemu pozostawia na urządzeniu starsze dane dotyczące zasad strefy czasowej niż te, które są widoczne na obrazie /system.

Niezawodność

Proces instalacji od początku do końca jest asynchroniczny i dzieli się na 3 procesy dotyczące systemu operacyjnego. 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 uruchomi weryfikację aktualizacji.

Bezpieczeństwo

Gdy ta opcja jest włączona, kod RulesManagerService na serwerze systemowym wykonuje kilka kontroli, aby zapewnić bezpieczne korzystanie z systemu.

• Problemy wskazujące na źle skonfigurowany obraz systemu uniemożliwiają uruchomienie urządzenia. Przykłady to zła konfiguracja aplikacji Updater lub Data lub brak aplikacji Updater lub Data 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 dla oczekiwanego identyfikatora URI.

Uprawnienia plików w folderach /data/misc/zoneinfo są egzekwowane za pomocą reguł SELinux. Podobnie jak w przypadku innych plików APK, aplikacja Data 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 dedykowane 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

Przed rozpoczęciem OEM-y powinny zapoznać się z tymi zasadami, wskazówkami dotyczącymi zapewnienia jakości i zabezpieczenia:

• Utwórz dla aplikacji Data klucz podpisywania przeznaczony dla tej aplikacji.
• Utwórz strategię dotyczącą wydawania aktualizacji i obsługi wersji aktualizacji strefy czasowej, aby dowiedzieć się, które urządzenia będą aktualizowane i jak można zapewnić, aby aktualizacje były instalowane tylko na urządzeniach, które ich potrzebują. Na przykład producenci OEM mogą chcieć mieć jedną aplikację Data na wszystkie urządzenia lub mogą zdecydować się na różne aplikacje Data na różne urządzenia. 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.

Tworzenie aplikacji danych

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 obejmują zarówno docelową wersję kompilacji prawdziwego pliku APK aplikacji Data, jak i dodatkowe docelowe wersje kompilacji testowych wersji tej aplikacji.

Producenci OEM mogą dostosować aplikację Data, korzystając z własnej ikony, nazwy, tłumaczeń i innych szczegółów. Nie można jednak uruchomić aplikacji Dane, więc ikona pojawia się 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 podpisania i rozpowszechniania 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 na urządzeniu 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

Producenci OEM muszą umieścić pliki APK aplikacji Updater i Data w katalogu /system/priv-app obrazu systemu. W tym celu kompilacja obrazu systemu musi wyraźnie uwzględniać wstępnie skompilowane cele aplikacji Updater 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 byłyby w obrazie dostawcy, aktualizacja do obrazu systemu bez aplikacji Data (lub z innymi nazwami pakietów aplikacji Data/Updater) byłaby uznana za nieprawidłową 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 lokalizacjach:

• 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ędniania testów w pakiecie xTS podobnym do pakietu Tradefed. Podobnie jak w przypadku innych katalogów szablonów, producenci OEM powinni skopiować pliki i dostosować je 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 opublikuje nowy zestaw reguł stref czasowych, zespół odpowiedzialny za podstawowe biblioteki Androida generuje poprawki do aktualizacji w AOSP. Producenci OEM korzystający z domyślnego systemu Androida i plików dystrybucyjnych mogą pobrać te commity, wykorzystać je do utworzenia nowej wersji aplikacji Data, a następnie opublikować nową wersję, aby zaktualizować urządzenia w produkcji.

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 OEM-y biorą commity z domyślnego Androida dotyczące system/timezone i external/icu z gałęzi release-dev w AOSP i zachowują je w 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 Data

Na tym etapie OEM aktualizuje kod wersji aplikacji Data. Kompilacja automatycznie odbiera distro.zip, ale nowa wersja aplikacji Data musi mieć nowy kod wersji, aby była rozpoznawana jako nowa i używana do zastąpienia wstępnie załadowanej aplikacji Data lub aplikacji Data zainstalowanej na urządzeniu w ramach poprzedniej aktualizacji.

Podczas kompilowania aplikacji Data za pomocą plików skopiowanych z package/apps/TimeZoneData/oem_template/data_app możesz znaleźć kod wersji lub nazwę wersji zastosowaną w pliku APK w pliku 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 schematu przykładowego 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 niewydanych urządzeń (lub podczas przygotowywania aktualizacji systemu na urządzenie wydane) prześlij nowe pliki APK do katalogu z gotowkami aplikacji. Dzięki temu obraz systemu i testy xTS będą zawierać najnowsze pliki APK. Producenci OEM powinni przetestować, czy nowy plik działa prawidłowo (czyli czy przechodzi testy CTS oraz wszystkie testy automatyczne i ręczne określone przez producenta).
• W przypadku urządzeń, które nie otrzymują już aktualizacji, 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 danych musi mieć odpowiednią strategię wersjonowania, aby zapewnić, że urządzenia otrzymają prawidłowe pliki APK. Jeśli na przykład otrzymasz aktualizację systemu zawierającą starszy pakiet APK niż ten pobrany ze sklepu z aplikacjami, należy zachować wersję ze sklepu z aplikacjami.

Kod wersji pliku APK powinien zawierać te informacje:

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

Obecnie poziom interfejsu API platformy jest silnie skorelowany 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 znajdziesz 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 poprawiona wersja przykładu 1 i jest liczbowo większa od 1.
• Przykłady 4 i 5 pokazują wersje 2017b dla wersji O-MR1 i P. Mają wyższe numery i zastępują wcześniejsze wersje IANA lub Androida.
• Przykłady 6 i 7 pokazują wersje 2018a dla wersji O-MR1 i P.
• Przykład 8 pokazuje, jak za pomocą wartości Y całkowicie zastąpić schemat 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 odpowiadają za zarządzanie większością aspektów aplikacji danych strefy czasowej i prawidłowe skonfigurowanie obrazu systemu. Aplikacja Data powinna być kompilowana za pomocą wersji tapas, która tworzy pliki APK odpowiednie do dodania do obrazu systemu (w przypadku początkowej wersji) oraz do podpisania i rozpowszechniania w sklepie z aplikacjami (w przypadku kolejnych aktualizacji).

Tapas to uproszczona wersja systemu kompilacji Androida, która korzysta z uproszczonego drzewa źródłowego do tworzenia wersji aplikacji do dystrybucji. Producenci OEM znający standardowy system kompilacji Androida powinni rozpoznać pliki kompilacji z tego standardowego kompilowania na platformie Android.

Tworzenie pliku manifestu

Zredukowane drzewo źródłowe jest zwykle uzyskiwane za pomocą pliku manifestu niestandardowego, który odwołuje się tylko do projektów Git potrzebnych systemowi kompilacji i do kompilowania aplikacji. Po wykonaniu instrukcji podanych w artykule Tworzenie aplikacji danych producenci OEM powinni mieć co najmniej 2 specyficzne dla siebie projekty Git utworzone za pomocą plików szablonów w folderze packages/apps/TimeZoneData/oem_template:

• 1 projekt Git zawiera pliki aplikacji, takie jak plik manifestu i pliki kompilacji wymagane do utworzenia pliku APK aplikacji (np. vendor/oem/apps/TimeZoneData). Ten projekt zawiera 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 kompilacji platformy lub zawierają biblioteki kodu niezależne od OEM.

Podany poniżej fragment pliku manifestu zawiera minimalny zestaw projektów Git potrzebnych do obsługi wersji O-MR1 aplikacji Data w strefie czasowej. Producenci OEM muszą dodać do tego pliku manifestu swoje projekty Git (zawierające zazwyczaj projekt z certyfikatem podpisu) i 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" />

Uruchamianie kompilacji 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 wersjami wstępnie skompilowanymi, aby uwzględnić je w pliku obrazu systemu lub rozpowszechnić w sklepie z aplikacjami na zgodnych urządzeniach.