Reguły strefy czasowej

Android 10 wycofuje dane strefy czasowej oparte na plikach APK (dostępny w Androidzie 8.1 i 9) i zastępuje go mechanizmu aktualizacji modułów opartego na APEX. Zasady AOSP w wersjach od 8.1 do 13 nadal zawierają kod platformy, który jest niezbędny dla OEM, by umożliwić aktualizacje oparte na plikach APK, czyli aktualizacje urządzeń z Androidem 10 do wersji 10; nadal mogą otrzymywać przekazywane przez partnera aktualizacje danych o strefie czasowej za pomocą pliku APK. Mechanizmu aktualizacji plików APK nie należy jednak używać na urządzeniu produkcyjnym. który otrzymuje również aktualizacje modułów w postaci aktualizacji opartej na plikach APK, zastępuje aktualizację opartą na APEX (czyli urządzenie, które otrzymało aktualizację pliku APK, zignoruje aktualizację, aktualizacje oparte na APEX).

Aktualizacje strefy czasowej (Android 10 i nowsze wersje)

Moduł Dane strefy czasowej obsługiwany w Androidzie 10 stosowanie większych aktualizacji czasu letniego i strefy czasowej na urządzeniach z Androidem, standaryzacji danych, które mogą się często zmieniać w kontekście religijnym, politycznym, z powodów geopolitycznych.

Proces aktualizacji wygląda tak:

1. IANA opublikuje aktualizację Time Zone Database w odpowiedzi na co najmniej jeden rząd zmienia regułę dotyczącą strefy czasowej w swoim kraju.
2. Google lub partner Androida przygotowują aktualizację modułu danych o strefie czasowej (plik APEX) zawierający zaktualizowane strefy czasowe.
3. Urządzenie użytkownika pobiera aktualizację, uruchamia się ponownie, a następnie stosuje zmian, po czym dane strefy czasowej urządzenia będą zawierać nową strefę czasową z powodu aktualizacji.

Szczegółowe informacje o modułach: Elementy systemu modułowego.

Aktualizacje strefy czasowej (Android 8.1–9)

Uwaga: funkcja mechanizmu aktualizacji danych strefy czasowej na podstawie pliku APK nie została całkowicie usunięta z Androida 14 i nowszych i nie można go znaleźć do kodu źródłowego. Partnerzy powinni w pełni przejść na Strefa czasowa z modułu Mainline.

W Androidzie 8.1 i 9 producenci OEM mogą przekazywać aktualizować dane reguł strefy czasowej na urządzeniach bez konieczności aktualizacji systemu. Mechanizm ten pozwala użytkownikom na bieżąco otrzymywać aktualizacje (w ten sposób przydatnego okresu użytkowania urządzenia z Androidem) i umożliwia partnerom Androida testowanie strefa czasowa jest aktualizowana niezależnie od aktualizacji obrazu systemu.

Zespół bibliotek Androida dostarcza niezbędne pliki danych dla: aktualizacji reguł dotyczących strefy czasowej na standardowym urządzeniu z Androidem, OEM może używać tych podczas tworzenia aktualizacji stref czasowych dla urządzeń lub tworzenia własnych własne pliki danych. We wszystkich przypadkach OEM kontroluje jakość. zapewnianie/testowanie, harmonogram i wdrażanie aktualizacji reguł dotyczących strefy czasowej w obsługiwanych urządzeniach.

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

Wszystkie urządzenia z Androidem w pakiecie, nawet jeśli nie korzystają z tej funkcji, muszą mieć ustawioną strefę czasową reguł i musi być wysyłany z domyślnym zestawem danych reguł strefy czasowej w /system partycja. Dane te są następnie używane przez kod z pakietu te biblioteki w drzewie źródłowym Androida:

• Kod zarządzany z libcore/ (np. java.util.TimeZone) używa tzdata i tzlookup.xml plików.
• Kod biblioteki natywnej w języku bionic/ (na przykład mktime, wywołania systemowe czasu lokalnego) używa pliku tzdata.
• Kod biblioteki ICU4J/ICU4C w external/icu/ korzysta z kodu icu .dat.

Te biblioteki śledzą pliki nakładek, które mogą znajdować się w Katalog /data/misc/zoneinfo/current. Pliki nakładek są wymagane zawiera ulepszone dane reguł dotyczących strefy czasowej, co pozwala na aktualizację urządzeń bez zmiany elementu /system.

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

• Kody libcore/ i bionic/ używają /data kopia dokumentów tzdata i tzlookup.xml .
• Kod ICU4J/ICU4C używa plików w folderze /data i zastępuje /system plików danych, których nie ma (w przypadku formatów, ciągi tekstowe itp.).

Pliki Distro

Pliki Distro .zip zawierają pliki danych potrzebne do wypełnienia /data/misc/zoneinfo/current. Pliki distro zawierają metadane, które umożliwiają urządzeniom wykrywanie problemów z obsługą wersji.

Format pliku distro zależy od wersji Androida, ponieważ zawartość zmiana wraz z wersją OIOM-em, wymaganiami platformy Androida i innymi wersjami. zmian. Android dostarcza pliki distro dla obsługiwanych wersji Androida dla każdego Aktualizacja IANA (oprócz aktualizacji plików systemu platformy). Aby zachować urządzeń, producenci OEM mogą używać tych plików Distro lub tworzyć własne drzewo źródłowe Androida (zawierające skrypty i inne pliki potrzebne do i generowanie plików distro).

Komponenty aktualizacji strefy czasowej

Aktualizacja reguł dotyczących strefy czasowej obejmuje przesłanie plików dystro do i bezpiecznej instalacji znajdujących się w nich plików. Przenieś Wymagane są następujące elementy:

• Funkcje usługi platformy (timezone.RulesManagerService), który jest domyślnie wyłączony. OEM musi włączyć tę funkcję przez konfigurację. RulesManagerService działa w procesie i na poszczególnych etapach serwera systemowego operacje aktualizacji strefy czasowej przez zapis do /data/misc/zoneinfo/staged RulesManagerService puszka możesz również zastąpić lub usunąć operacje etapowe.
• TimeZoneUpdater, aplikacja systemowa, której nie można zaktualizować (lub aplikacji Aktualizator). OEM musi umieścić tę aplikację w obrazie systemu urządzeń korzystających z tej funkcji.
• OEM TimeZoneData, aplikacja systemowa z możliwością aktualizacji (np. aplikację Dane), która przenosi pliki Distro na urządzenie i je tworzy dostępne w aplikacji Aktualizator. OEM musi umieścić tę aplikację w obrazie systemu urządzeń korzystających z tej funkcji.
• tzdatacheck, plik binarny używany podczas rozruchu wymagany do prawidłowego i bezpiecznego działania aktualizacji strefy czasowej.

Drzewo źródłowe Androida zawiera ogólny kod źródłowy tych elementów których producent OEM może używać bez modyfikacji. Przetestuj kod pozwala producentom OEM automatycznie sprawdzać czy poprawnie włączyli tę funkcję.

Instalacja Distro

Proces instalacji Distro obejmuje te kroki:

1. Aplikacja, która zawiera dane, jest aktualizowana przez pobranie w sklepie z aplikacjami lub instalowanie z nieoficjalnych źródeł. Proces serwera systemu (przez timezone.RulesManagerServer/timezone.PackageTracker zajęcia) monitoruje zmiany w skonfigurowanym pakiecie aplikacji z danymi specyficznymi dla OEM imię i nazwisko.
   
   

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

2. Proces serwera systemu uruchamia sprawdzanie dostępności aktualizacji przez przesyłanie kierowanych intencji za pomocą unikalnego, jednorazowego tokena do aktualizatora; Zgłosz. Serwer systemu śledzi ostatni wygenerowany token, może określić, kiedy zakończyła się ostatnia aktywowana kontrola; wszystkie inne są ignorowane.
   
   

   Rysunek 2. Uruchom sprawdzanie dostępności aktualizacji.

3. Podczas sprawdzania dostępności aktualizacji aplikacja aktualizatora wykonuje następujące zadania:
   • Wykonuje zapytanie o bieżący stan urządzenia przez wywołanie usługi RulesManagerService.
     
     

     Rysunek 3. Aktualizacje aplikacji danych, wywołując RulesManagerService.

   • Odpytuje aplikację Data przez wysłanie zapytania do dobrze zdefiniowanego adresu URL komponentu ContentProvider specyfikacji kolumn, aby uzyskać informacje o dystrybucji.
     
     

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

4. Aplikacja aktualizator podejmuje odpowiednie działania na podstawie dostępnych informacji. Dostępne działania:
   • Poproś o instalację. Dane Distro są odczytywane z aplikacji Dane i przekazywana do usługi RulesManagerService na serwerze systemu. RulesManagerService sprawdza ponownie, czy wersja i zawartość formatu distro są odpowiednie dla danego urządzenia i etap instalacji.
   • Poproś o odinstalowanie (rzadko). Jeśli na przykład zaktualizowany plik Plik APK w aplikacji /data jest wyłączony lub odinstalowany, a urządzenie jest do wersji dostępnej w /system.
   • Nic nie rób. Występuje, gdy okaże się, że dystrybucja aplikacji Data jest nieprawidłowa.
   . We wszystkich przypadkach aplikacja Updater wywołuje usługę RulesManagerService za pomocą tokena kontrolnego. tak by serwer systemu wiedział, że sprawdzanie zostało zakończone i zakończone.
   
   

   Rysunek 5. Sprawdzanie zakończone.

5. Uruchom ponownie i wykonaj tzdatacheck. Przy następnym uruchomieniu urządzenia plik binarny tzdatacheck wykonuje dowolną operację etapową. Plik binarny tzdatacheck może wykonaj te czynności:
   • Wykonuj operację etapową, obsługując tworzenie, zastępowanie lub usunięcie /data/misc/zoneinfo/current plików przed inne komponenty systemu zostały otwarte i zaczęły z nich korzystać.
   • Sprawdź, czy pliki w folderze /data są poprawne wersji platformy, co może nie mieć miejsca, jeśli urządzenie właśnie otrzymało Aktualizacja systemu oraz wersja formatu distro uległa zmianie.
   • Sprawdź, czy wersja reguł IANA jest taka sama jak wersja w /system Chroni to przed aktualizacją systemu na urządzeniu ze starszymi danymi reguł strefy czasowej niż /system .

Niezawodność

Pełny proces instalacji jest asynchroniczny i podzielony na 3 systemy operacyjne W dowolnym momencie instalacji urządzenie może utracić zasilanie, działać z powodu braku miejsca na dysku lub wystąpienia innych problemów, które mogą spowodować jest niekompletna. W przypadku najbardziej niepowodzenia aplikacja Aktualizator informuje system serwer informujący o niepowodzeniu; w najgorszym razie RulesManagerService w ogóle nie otrzymuje wywołania.

Aby to zrobić, kod serwera systemu śledzi, czy Ukończono sprawdzanie dostępności aktualizacji i jaki był ostatnio sprawdzany kod wersji danych. Aplikacja jest. Gdy urządzenie jest nieaktywne i się ładuje, kod serwera systemu może sprawdzić do bieżącego stanu. W przypadku wykrycia niepełnego sprawdzania dostępności aktualizacji lub nieoczekiwanych danych wersji aplikacji, uruchamia spontanicznie sprawdzenie dostępności aktualizacji.

Bezpieczeństwo

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

• Problemy, które oznaczają nieprawidłowo skonfigurowany obraz systemu, uniemożliwiają korzystanie z urządzenia uruchamianie; może to być np. nieprawidłowa konfiguracja Aktualizatora lub aplikacji z danymi; Aktualizator lub aplikacja danych nie jest w trybie /system/priv-app.
• Problemy, które wskazują, że zainstalowana jest nieprawidłowa aplikacja Data, nie uniemożliwiają uruchamia się urządzenie, ale nie pozwala na uruchomienie sprawdzania dostępności aktualizacji; Przykłady brak wymaganych uprawnień systemowych lub aplikacja Data nie ujawnia ContentProvider o oczekiwanym identyfikatorze URI.

Uprawnienia do plików w katalogu /data/misc/zoneinfo są następujące egzekwowane przy użyciu reguł SELinux. Tak jak w przypadku każdego pliku APK, aplikację Dane muszą być podpisane przez tym samym kluczem użytym do podpisania wersji /system/priv-app. Aplikacja Dane to powinien mieć dedykowaną nazwę i klucz pakietu OEM.

Integracja aktualizacji strefy czasowej

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

• tworzyć własną aplikację do zarządzania danymi,
• Dodaj aplikacje aktualizatora i danych do kompilacji obrazu systemu.
• Skonfiguruj serwer systemu tak, aby włączyć usługę RulesManagerService.

Przygotowanie

Zanim zaczniemy, OEM powinni zapoznać się z tymi polisami, zapewnianiem jakości i kwestie związane z bezpieczeństwem:

• Utworzyć specjalny klucz podpisywania w przypadku aplikacji obsługującej dane.
• Tworzenie strategii dotyczącej wersji i obsługi wersji na potrzeby aktualizacji strefy czasowej i dowiedzieć się, które urządzenia zostaną zaktualizowane i jak można zapewnić aktualizacje są instalowane tylko na urządzeniach, które ich potrzebują. Na przykład OEM może chcieć, korzystać z jednej aplikacji do zarządzania danymi na wszystkich swoich urządzeniach lub wybrać różne Aplikacje do zarządzania danymi dla różnych urządzeń. Ta decyzja wpływa na wybór pakietu nazwa, prawdopodobnie użyte kody wersji i strategia kontroli jakości.
• Zastanów się, czy klient chce korzystać z bankowych danych o strefie czasowej Androida z AOSP lub utworzyć własne.

Utwórz aplikację do zarządzania danymi

AOSP obejmuje cały kod źródłowy i reguły kompilacji potrzebne do utworzenia aplikacji do zarządzania danymi packages/apps/TimeZoneData z instrukcjami i przykładowymi szablonami dla AndroidManifest.xml i innych plików w packages/apps/TimeZoneData/oem_template Przykładowe szablony obejmują zarówno cel kompilacji dla prawdziwego pakietu APK aplikacji z danymi, jak i dodatkowe cele dla w wersji testowej aplikacji Data.

OEM może dostosować aplikację Dane, dodając własną ikonę, nazwę, tłumaczenia inne szczegóły. Nie można jednak uruchomić aplikacji Dane, dlatego pojawia się ikona tylko w sekcji Ustawienia > Aplikacje.

Aplikacja Data powinna być oparta na kompilacji tapas. który tworzy pliki APK odpowiednie do dodania do obrazu systemu (na początkowy oraz podpisana i rozpowszechniana w sklepie z aplikacjami (na potrzeby aktualizacje). Szczegółowe informacje o korzystaniu z tapas znajdziesz w sekcji Tworzenie Aplikacja do zbierania danych korzystająca z tapas.

OEM musi zainstalować aplikację Data wbudowaną w obraz systemu urządzenia /system/priv-app Aby dołączyć gotowe pliki APK (wygenerowane przez tapas w procesie kompilacji) w obrazie systemu, OEM może skopiować przykładowe pliki packages/apps/TimeZoneData/oem_template/data_app_prebuilt przykładowe szablony zawierają też cele kompilacji, które pozwalają uwzględnić wersje testowe Aplikacja z danymi w pakietach testowych.

Uwzględnij aplikacje Aktualizator i Dane w obrazie systemu

OEM musi umieścić pliki APK aktualizatora i aplikacji Data w Katalog obrazu systemu: /system/priv-app. W tym celu kompilacja obrazu systemu musi wyraźnie zawierać aplikację Aktualizator i gotową aplikację Data celów.

Aplikacja aktualizatora powinna być podpisana za pomocą klucza platformy i uwzględniona jako dowolny innej aplikacji systemowej. Miejsce docelowe jest zdefiniowane w packages/apps/TimeZoneUpdater jako TimeZoneUpdater. Uwzględnienie aplikacji z danymi jest związane z OEM i zależy od nazwy docelowej wybranej dla wstępną kompilację.

Konfigurowanie serwera systemowego

Aby włączyć aktualizacje strefy czasowej, producenci OEM mogą skonfigurować serwer systemu przez zastępujące 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 obrazie dostawcy ani w innym miejscu) ponieważ błędnie skonfigurowane urządzenie może odmówić uruchomienia. Jeśli konfiguracja zastępuje były w obrazie dostawcy, po aktualizacji do obrazu systemu bez aplikacji Data z różnymi nazwami pakietów aplikacji z danymi/aktualizacji) jest uważany za błędną konfigurację.

Testowanie xTS

xTS odnosi się do dowolnego pakietu testowego specyficznego dla OEM, który jest podobny do standardowego systemu Android. zestawów testowych korzystających z platformy Tradefed (np. CTS i VTS). OEM, którzy przeprowadzają takie testy pakiety mogą dodać testy aktualizacji strefy czasowej Androida w następujący sposób lokalizacje:

• packages/apps/TimeZoneData/testing/xts zawiera kod potrzebne do podstawowych automatycznych testów funkcjonalnych.
• packages/apps/TimeZoneData/oem_template/xts zawiera próbkę do umieszczania testów w pakiecie xTS przypominającym Tradefed. Tak jak lub inne katalogi szablonów, oczekuje się, że producent OEM skopiuje i dostosuje do Twoich potrzeb.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt zawiera konfigurację w czasie kompilacji, która pozwala dołączyć gotowe testowe pliki APK. proces testowania.

Tworzenie aktualizacji strefy czasowej

Po opublikowaniu przez IANA nowego zestawu reguł dotyczących strefy czasowej podstawowe biblioteki Androida zespół generuje poprawki, aby aktualizować wersje w AOSP. OEM korzystający z fabrycznego Androida pliki systemowe i distro mogą wykrywać te zatwierdzenia, użyć ich do utworzenia nowego aplikacji Data, a następnie opublikować nową wersję, aby zaktualizować urządzenia w produkcji.

Aplikacje z danymi zawierają pliki distro ściśle powiązane z wersjami Androida, OEM musi utworzyć nową wersję aplikacji Dane dla każdego obsługiwanego urządzenia Wersja Androida, którą producent OEM chce zaktualizować. Jeśli na przykład producent OEM chce dostarczanie aktualizacji na Androida 8.1, 9 i 10 urządzeń muszą wykonać tę procedurę 3 razy.

Krok 1. Zaktualizuj pliki danych systemu/strefy czasowej i plików danych zewnętrznych/plików icu

Na tym etapie producenci OEM przyjmują standardowe zobowiązania Androida dotyczące system/timezone i external/icu z gałęzi release-dev w AOSP i stosują te zatwierdzenia do swojej kopii w kodzie źródłowym Androida.

Poprawka systemu/strefy czasowej AOSP zawiera zaktualizowane pliki w system/timezone/input_data i system/timezone/output_data OEM, którzy muszą wprowadzić dodatkowe mogą modyfikować pliki wejściowe, a następnie używać plików system/timezone/input_data i external/icu do aby wygenerować pliki w folderze output_data.

Najważniejszym plikiem jest system/timezone/output_data/distro/distro.zip, czyli są automatycznie uwzględniane podczas tworzenia pakietu APK aplikacji Dane.

Krok 2. Zaktualizuj kod wersji aplikacji Dane

Na tym etapie producenci OEM aktualizują kod wersji aplikacji Data. Kompilacja automatycznie pobierze distro.zip, ale nowa wersja Aplikacja danych musi mieć nowy kod wersji, aby był rozpoznawany jako nowy i służył do: zastąpić wstępnie załadowaną aplikację do zarządzania danymi lub aplikację do zarządzania danymi zainstalowaną na urządzeniu dotychczasowym .

Podczas tworzenia aplikacji Dane przy użyciu plików skopiowanych z package/apps/TimeZoneData/oem_template/data_app, tutaj znajdziesz kod lub nazwa wersji zastosowanej do pliku APK w Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Podobne wpisy można znaleźć w testing/Android.mk (ale kody wersji testowej muszą być wyższe niż wersja obrazu systemu). Więcej informacji: zobacz przykładową strategię dotyczącą kodu wersji jeśli zastosowany jest schemat przykładowy lub podobny, test kodów wersji nie trzeba aktualizować, bo są gwarantowane niż rzeczywiste kody wersji.

Krok 3. Przebuduj, podpisz, przetestuj i opublikuj

Na tym etapie OEM odbudowuje pakiet APK, używając tapas, podpisuje wygenerowany plik APK. APK, a następnie go przetestuj i opublikuj:

• Dotyczy urządzeń, które nie zostały jeszcze wydane (lub podczas przygotowań do aktualizacji systemu urządzenia), prześlij nowe pliki APK w gotowym katalogu aplikacji Data. , by upewnić się, że obrazy systemu i testy xTS zawierają najnowsze pliki APK. OEM powinien że nowy plik działa prawidłowo (tj. przechodzi test CTS oraz testów automatycznych i ręcznych specyficznych dla OEM).
• W przypadku wydanych urządzeń, które nie otrzymują już aktualizacji systemu, podpisany plik APK mogą być publikowane tylko w sklepie z aplikacjami.

Producenci OEM odpowiadają za kontrolę jakości i testowanie zaktualizowanych aplikację zawierającą dane na ich urządzeniach przed jej wydaniem.

Strategia dotycząca kodu wersji aplikacji danych

Aplikacja Data musi mieć odpowiednie strategii obsługi wersji, aby zapewnić, że urządzenia otrzymają prawidłowe pliki APK. Dla: np. gdy zostanie pobrana aktualizacja systemu, która zawiera starszy plik APK niż 1. ze sklepu z aplikacjami, należy zachować wersję ze sklepu z aplikacjami.

Kod wersji pliku APK powinien zawierać te informacje:

• Wersja w formacie Distro (główna + podrzędna)
• Rosnący (nieprzezroczysty) numer wersji

Obecnie poziom interfejsu API platformy jest silnie powiązany z wersją formatu distro ponieważ każdy poziom interfejsu API jest zwykle powiązany z nową wersją OIOM-u (która sprawia, że pliki distro są niezgodne). Android może to zmienić w przyszłości. że plik distro może działać na różnych wersjach platformy Androida (oraz nie jest używany w schemacie kodu wersji aplikacji danych).

Przykładowa strategia dotycząca kodu wersji

Ten przykładowy schemat obsługi wersji zapewnia wyższy format dystrybucji AndroidManifest.xml używa android:minSdkVersion do: Żeby stare urządzenia nie otrzymywały wersji o wyższym formacie dystrybucji niż jest to możliwe.

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

Schemat mógłby być lepiej skompresowany, gdyby można było użyć liczb binarnych zamiast dziesiętnych, ale ten schemat ma tę zaletę, że jest czytelny dla człowieka. Jeśli pełny zakres liczbowy jest wyczerpany, nazwa pakietu aplikacji z danymi może się zmienić.

Nazwa wersji to czytelna dla człowieka reprezentacja szczegółów, 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 plików APK tej samej wersji IANA z 2017 r. w dużych wersjach formatów. 2 jest liczbowo większą od 1, która jest Pomaga to zapewnić, że nowsze urządzenia będą otrzymywać wyższe wersje formatu. Parametr minSdkVersion zapewnia, że wersja P nie zostanie udostępniona urządzeniom O.
• Przykład 3 to wersja/poprawka dla wartości 1, która ma wartość liczbową większą niż 1.
• Przykłady 4 i 5 pokazują wersje O-MR1 i P z 2017 r. Liczbowe zastępują wcześniejsze wersje IANA/Androida swoich nad konkurencją.
• Przykłady 6 i 7 pokazują wersje O-MR1 i P z 2018 r.
• Przykład 8 pokazuje wykorzystanie Y do całkowitego zastąpienia schematu Y=0.
• W przykładzie 9 przedstawiono wykorzystanie przerwy między 3 a 4 do ponownego obrotu. pakiet apk.

Każde urządzenie jest wysyłane z domyślnym plikiem APK, który ma w odpowiedniej wersji nie istnieje ryzyko zainstalowania wersji O-MR1 na urządzeniu P bo ma niższy numer wersji niż wersja obrazu systemu P. O urządzenie z zainstalowaną wersją O-MR1 w systemie /data, które następnie otrzymuje aktualizacja systemu do P korzysta z wersji /system jako preferowanej wersję O-MR1 w /data, ponieważ wersja P jest zawsze wyższa. niż jakakolwiek aplikacja przeznaczona do obsługi O-MR1.

Tworzenie aplikacji Data za pomocą tapas

OEM jest odpowiedzialny za zarządzanie większością aspektów aplikacji Dane strefy czasowej oraz poprawnie skonfigurować obraz systemu. Aplikacja Data jest z założenia w wersji tapas, która tworzy pliki APK odpowiednie do dodania. obrazu systemu (pierwszej wersji) oraz podpisany i rozpowszechniony App Store (w przyszłości).

Tapas to odchudzona wersja kompilacji Androida. system, który wykorzystuje mniej drzewo źródłowe do tworzenia możliwych do dystrybucji wersji aplikacji. OEM, którzy znają zwykły system kompilacji Androida, powinni rozpoznawać niż w przypadku zwykłej kompilacji platformy Androida.

Tworzenie pliku manifestu

Zredukowane drzewo źródłowe jest zwykle osiągane za pomocą niestandardowego pliku manifestu, który odnosi się tylko do projektów Git wymaganych przez system kompilacji i do . Po wykonaniu instrukcji podanych w Tworzenie aplikacji Data, OEM powinien 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). Ten projekt również zawiera reguły kompilacji testowych plików APK, których można używać w testach xTS.
• Jeden projekt Git zawiera podpisane pliki APK utworzone przez kompilację aplikacji dla do włączenia do kompilacji obrazu systemu i testów xTS.

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

Ten fragment kodu manifestu zawiera minimalny zestaw projektów Git potrzebne do obsługi kompilacji O-MR1 aplikacji Dane strefy czasowej. OEM muszą dodać swoje projekty Git właściwe dla OEM (które zwykle obejmują projekt zawiera certyfikat podpisywania) do tego pliku manifestu i może skonfigurować inne odpowiednio rozgałęzia się 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 ustanowieniu 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

Udana kompilacja spowoduje wygenerowanie plików w katalogu out/dist dla i testowania. Pliki te można umieścić w katalogu gotowych plików, aby umieścić je w obrazu systemu lub rozpowszechnianego w sklepie z aplikacjami na potrzeby zgodności urządzenia.