Zasady dotyczące stref czasowych

Android 10 wycofuje mechanizm aktualizacji danych stref czasowych oparty na APK (dostępny w Androidzie 8.1 i Android 9) i zastępuje go mechanizmem aktualizacji modułu opartym na APEX . AOSP 8.1–13 nadal zawierają kod platformy niezbędny producentom OEM do umożliwienia aktualizacji opartych na plikach APK, więc urządzenia uaktualniające się do Androida 10 mogą nadal otrzymywać dostarczane przez partnerów aktualizacje danych stref czasowych za pośrednictwem pliku APK. Jednak mechanizmu aktualizacji APK nie należy używać na urządzeniu produkcyjnym, które otrzymuje również aktualizacje modułów, ponieważ aktualizacja oparta na APK zastępuje aktualizację opartą na APEX (tzn. urządzenie, które otrzymało aktualizację APK, zignoruje aktualizacje oparte na APEX ).

Aktualizacje stref czasowych (Android 10+)

Moduł danych strefy czasowej obsługiwany w systemie Android 10 i nowszych wersjach aktualizuje czas letni (DST) i strefy czasowe na urządzeniach z systemem Android, standaryzując dane, które mogą często zmieniać się ze względów religijnych, politycznych i geopolitycznych.

Aktualizacje korzystają z następującego procesu:

  1. IANA publikuje aktualizację bazy danych stref czasowych publikuje aktualizację w odpowiedzi na zmianę przez jeden lub więcej rządów zasad dotyczących stref czasowych w swoich krajach.
  2. Google lub partner Androida przygotowuje aktualizację modułu danych stref czasowych (plik APEX) zawierającą zaktualizowane strefy czasowe.
  3. Urządzenie użytkownika końcowego pobiera aktualizację, uruchamia się ponownie, a następnie stosuje zmiany, po czym dane strefy czasowej urządzenia zawierają dane nowej strefy czasowej z aktualizacji.

Aby uzyskać szczegółowe informacje na temat modułów, zobacz Komponenty systemu modułowego .

Aktualizacje stref czasowych (Android 8.1–9)

Uwaga: funkcja mechanizmu aktualizacji danych strefy czasowej w oparciu o plik APK została całkowicie usunięta z Androida 14 i nowszych wersji i nie można jej znaleźć w kodzie źródłowym. Partnerzy powinni przeprowadzić pełną migrację do modułu Time Zone Mainline.

W systemach Android 8.1 i Android 9 producenci OEM mogą korzystać z mechanizmu opartego na pakiecie APK, aby przesyłać zaktualizowane dane dotyczące reguł stref czasowych do urządzeń bez konieczności aktualizacji systemu. Mechanizm ten umożliwia użytkownikom otrzymywanie aktualnych aktualizacji (w ten sposób wydłużając żywotność urządzenia z Androidem) i umożliwia partnerom Androida testowanie aktualizacji stref czasowych niezależnie od aktualizacji obrazu systemu.

Zespół bibliotek podstawowych systemu Android udostępnia pliki danych niezbędne do aktualizacji reguł stref czasowych na standardowym urządzeniu z systemem Android. Producenci OEM mogą zdecydować się na użycie tych plików danych podczas tworzenia aktualizacji stref czasowych dla swoich urządzeń lub, jeśli jest to preferowane, mogą tworzyć własne pliki danych. We wszystkich przypadkach producenci OEM zachowują kontrolę nad zapewnianiem/testowaniem jakości, harmonogramem i uruchamianiem aktualizacji reguł stref czasowych dla obsługiwanych urządzeń.

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 dotyczących reguł stref czasowych i muszą być dostarczane z domyślnym zestawem danych reguł stref czasowych na partycji /system . Dane te są następnie wykorzystywane przez kod z następujących 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 .
  • Natywny kod biblioteki w bionic/ (na przykład dla mktime wywołania systemowe localtime) używa pliku tzdata .
  • Kod biblioteki ICU4J/ICU4C w external/icu/ wykorzystuje plik icu .dat .

Biblioteki te śledzą pliki nakładek, które mogą znajdować się w katalogu /data/misc/zoneinfo/current . Oczekuje się, że pliki nakładek będą zawierać ulepszone dane dotyczące reguł stref czasowych, umożliwiając w ten sposób aktualizację urządzeń bez zmiany /system .

Komponenty systemu Android wymagające danych dotyczących reguł stref czasowych sprawdzają najpierw następujące lokalizacje:

  • libcore/ i bionic/ code używają kopii /data plików tzdata i tzlookup.xml .
  • Kod ICU4J/ICU4C używa plików w /data i wraca do plików /system w przypadku danych, których nie ma (w przypadku formatów, zlokalizowanych ciągów znaków itp.).

Pliki dystrybucji

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

Format pliku dystrybucyjnego zależy od wersji Androida, ponieważ zawartość zmienia się wraz z wersją ICU, wymaganiami platformy Android i innymi zmianami wersji. Android udostępnia pliki dystrybucyjne dla obsługiwanych wersji Androida dla każdej aktualizacji IANA (oprócz aktualizacji plików systemowych platformy). Aby zapewnić aktualność swoich urządzeń, producenci OEM mogą korzystać z tych plików dystrybucji lub tworzyć własne, korzystając z drzewa źródeł systemu Android (zawierającego skrypty i inne pliki potrzebne do generowania plików dystrybucji).

Składniki aktualizacji strefy czasowej

Aktualizacja reguł strefy czasowej obejmuje przesłanie plików dystrybucji na urządzenie i bezpieczną instalację zawartych w nich plików. Transfer i instalacja wymaga następujących elementów:

  • Funkcjonalność usługi platformy ( timezone.RulesManagerService ), która jest domyślnie wyłączona. Producenci OEM muszą włączyć tę funkcjonalność poprzez konfigurację. RulesManagerService działa w procesie serwera systemowego i etapuje operacje aktualizacji strefy czasowej, zapisując do /data/misc/zoneinfo/staged . RulesManagerService może również zastąpić lub usunąć już wykonane operacje.
  • TimeZoneUpdater , aplikacja systemowa, której nie można aktualizować (znana również jako aplikacja Updater ). Producenci OEM muszą uwzględnić tę aplikację w obrazie systemu urządzeń korzystających z tej funkcji.
  • OEM TimeZoneData , aktualizowalna aplikacja systemowa (znana również jako aplikacja Data ), która przenosi pliki dystrybucyjne na urządzenie i udostępnia je aplikacji Updater. Producenci OEM muszą uwzględnić tę aplikację w obrazie systemu urządzeń korzystających z tej funkcji.
  • tzdatacheck , plik binarny czasu rozruchu wymagany do prawidłowego i bezpiecznego działania aktualizacji stref czasowych.

Drzewo źródłowe Androida zawiera ogólny kod źródłowy powyższych komponentów, z którego producent OEM może korzystać bez modyfikacji. Udostępniono kod testowy umożliwiający producentom OEM automatyczne sprawdzenie, czy poprawnie włączyli tę funkcję.

Instalacja dystrybucji

Proces instalacji dystrybucji obejmuje następujące kroki:

  1. Aplikacja danych jest aktualizowana poprzez pobranie ze sklepu z aplikacjami lub ładowanie boczne. Proces serwera systemowego (poprzez klasy timezone.RulesManagerServer/timezone.PackageTracker ) obserwuje zmiany w skonfigurowanej, specyficznej dla OEM nazwie pakietu aplikacji danych.

    Aktualizacje aplikacji danych
    Rysunek 1. Aktualizacje aplikacji danych
  2. Proces serwera systemowego inicjuje sprawdzanie aktualizacji poprzez rozgłaszanie docelowego zamiaru za pomocą unikalnego, jednorazowego tokena do aplikacji aktualizującej. Serwer systemowy śledzi najnowszy wygenerowany token, dzięki czemu może określić, kiedy zakończyła się ostatnia inicjowana przez niego kontrola; wszelkie inne żetony są ignorowane.

    Aktualizacja wyzwalacza
    Rysunek 2. Wyzwalaj sprawdzanie aktualizacji
  3. Podczas sprawdzania aktualizacji aplikacja Updater wykonuje następujące zadania:
    • Wysyła zapytanie o bieżący stan urządzenia, wywołując usługę RulesManagerService.

      Zadzwoń do serwisu RulesManager
      Rysunek 3. Aktualizacje aplikacji danych wywołujące usługę RulesManagerService
    • Wysyła zapytanie do aplikacji Data, wysyłając zapytanie do dobrze zdefiniowanego adresu URL dostawcy treści i specyfikacji kolumn, aby uzyskać informacje o dystrybucji.

      Uzyskaj informacje o dystrybucji
      Rysunek 4. Aktualizacje aplikacji danych, uzyskaj informacje o dystrybucji
  4. Aplikacja Updater podejmuje odpowiednie działania w oparciu o posiadane informacje. Dostępne działania obejmują:
    • Poproś o instalację. Dane Distro są odczytywane z aplikacji Data i przekazywane do usługi RulesManagerService na serwerze systemowym. Usługa RulesManagerService ponownie potwierdza, że ​​wersja w formacie dystrybucji i zawartość są odpowiednie dla urządzenia, po czym przeprowadza instalację.
    • Poproś o odinstalowanie (jest to rzadkie). Na przykład, jeśli zaktualizowany plik APK w /data zostanie wyłączony lub odinstalowany, a urządzenie powraca do wersji obecnej w /system .
    • Nic nie robić. Występuje, gdy okaże się, że dystrybucja aplikacji Data jest nieprawidłowa.
    We wszystkich przypadkach aplikacja Updater wywołuje usługę RulesManagerService z tokenem kontrolnym, aby serwer systemowy wiedział, że sprawdzenie zostało zakończone i pomyślne.

    Sprawdź ukończone
    Rysunek 5. Kontrola zakończona
  5. Uruchom ponownie i sprawdź tzdata. Przy następnym uruchomieniu urządzenia plik binarny tzdatacheck wykonuje dowolną operację etapową. Plik binarny tzdatacheck może wykonywać następujące zadania:
    • Wykonaj operację etapową, obsługując tworzenie, zastępowanie i/lub usuwanie plików /data/misc/zoneinfo/current zanim inne komponenty systemu otworzą się i zaczną z nich korzystać.
    • Sprawdź, czy pliki w /data są poprawne dla bieżącej wersji platformy, co może nie mieć miejsca, jeśli urządzenie właśnie otrzymało aktualizację systemu i zmieniła się wersja formatu dystrybucji.
    • Upewnij się, że wersja reguł IANA jest taka sama lub nowsza niż wersja w /system . Chroni to przed aktualizacją systemu pozostawiającą na urządzeniu starsze dane dotyczące reguł stref czasowych, niż te obecne w obrazie /system .

Niezawodność

Kompleksowy proces instalacji jest asynchroniczny i podzielony na trzy procesy systemu operacyjnego. W dowolnym momencie instalacji urządzenie może stracić zasilanie, zabrakło miejsca na dysku lub napotkać inne problemy, co spowoduje, że sprawdzenie instalacji będzie niekompletne. W najlepszym przypadku niepowodzenia aplikacja Updater informuje serwer systemowy o niepowodzeniu; w najgorszym przypadku nieudanym, usługa RulesManagerService w ogóle nie odbiera połączenia.

Aby sobie z tym poradzić, kod serwera systemowego śledzi, czy zakończyło się wyzwalane sprawdzanie aktualizacji i jaki jest kod ostatniej sprawdzanej wersji aplikacji Data App. Gdy urządzenie jest bezczynne i ładuje się, kod serwera systemowego może sprawdzić aktualny stan. Jeśli wykryje niekompletną kontrolę aktualizacji lub nieoczekiwaną wersję aplikacji Data App, spontanicznie uruchamia kontrolę aktualizacji.

Bezpieczeństwo

Po włączeniu kod RulesManagerService na serwerze systemowym przeprowadza kilka kontroli, aby upewnić się, że korzystanie z systemu jest bezpieczne.

  • Problemy wskazujące na źle skonfigurowany obraz systemu uniemożliwiają uruchomienie urządzenia; przykłady obejmują złą konfigurację Aktualizatora lub aplikacji Dane albo Aktualizator lub aplikację Dane nie znajdującą się w /system/priv-app .
  • Problemy wskazujące, że zainstalowano złą aplikację do obsługi danych, nie uniemożliwiają uruchomienia urządzenia, ale uniemożliwiają uruchomienie sprawdzania aktualizacji; przykłady obejmują brak wymaganych uprawnień systemowych lub aplikacja danych nie udostępnia elementu ContentProvider w oczekiwanym identyfikatorze URI.

Uprawnienia do plików w katalogach /data/misc/zoneinfo są egzekwowane przy użyciu reguł SELinux. Podobnie jak w przypadku każdego pakietu APK, aplikacja Data musi być podpisana tym samym kluczem, którego użyto do podpisania wersji aplikacji /system/priv-app . Oczekuje się, że aplikacja Data będzie miała dedykowaną nazwę pakietu i klucz specyficzną dla OEM.

Integracja aktualizacji stref czasowych

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

  • Utwórz własną aplikację danych.
  • Dołącz aplikacje Updater i Data do kompilacji obrazu systemu.
  • Skonfiguruj serwer systemowy, aby włączyć usługę RulesManagerService.

Przygotowanie

Przed rozpoczęciem producenci OEM powinni zapoznać się z poniższymi zasadami, kwestiami dotyczącymi zapewnienia jakości i bezpieczeństwa:

  • Utwórz dedykowany klucz podpisywania specyficzny dla aplikacji dla swojej aplikacji danych.
  • Utwórz strategię wydań i wersji dla aktualizacji stref czasowych, aby dowiedzieć się, które urządzenia będą aktualizowane i w jaki sposób mogą zapewnić, że aktualizacje zostaną zainstalowane tylko na urządzeniach, które ich potrzebują. Na przykład producenci OEM mogą chcieć mieć jedną aplikację do obsługi danych dla wszystkich swoich urządzeń lub mogą mieć różne aplikacje do obsługi danych dla różnych urządzeń. Decyzja ma wpływ na wybór nazwy pakietu, ewentualnie użytych kodów wersji i strategii kontroli jakości.
  • Dowiedz się, czy chcą używać standardowych danych o strefie czasowej Androida z AOSP, czy też tworzyć własne.

Tworzenie aplikacji danych

AOSP zawiera cały kod źródłowy i reguły kompilacji potrzebne do utworzenia aplikacji Data w packages/apps/TimeZoneData , z instrukcjami i przykładowymi szablonami dla AndroidManifest.xml i innymi plikami znajdującymi się w packages/apps/TimeZoneData/oem_template . Przykładowe szablony obejmują zarówno cel kompilacji prawdziwego pliku APK aplikacji Data, jak i dodatkowe cele do tworzenia wersji testowych aplikacji Data.

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

Aplikacja Data ma zostać zbudowana w oparciu o kompilację tapas , która tworzy pliki APK, które można dodać do obrazu systemu (w przypadku pierwszej wersji) oraz podpisać i rozpowszechniać za pośrednictwem sklepu z aplikacjami (w przypadku kolejnych aktualizacji). Aby uzyskać szczegółowe informacje na temat korzystania z tapas, zobacz Tworzenie aplikacji danych za pomocą tapas .

Producenci OEM muszą zainstalować aplikację Data wbudowaną w obraz systemu urządzenia w /system/priv-app . Aby uwzględnić w obrazie systemu wstępnie skompilowane pliki APK (wygenerowane w procesie kompilacji tapas), producenci OEM mogą skopiować przykładowe pliki do packages/apps/TimeZoneData/oem_template/data_app_prebuilt . Przykładowe szablony zawierają także elementy docelowe kompilacji umożliwiające dołączenie wersji testowych aplikacji Data do zestawów testów.

W tym 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 jawnie zawierać wstępnie utworzone obiekty docelowe aplikacji Updater i aplikacji Data.

Aplikację Updater należy podpisać kluczem platformy i dołączyć jak każdą inną aplikację systemową. Cel jest zdefiniowany w packages/apps/TimeZoneUpdater jako TimeZoneUpdater . Dołączenie aplikacji Data jest specyficzne dla OEM i zależy od nazwy docelowej wybranej dla kompilacji wstępnej.

Konfiguracja serwera systemowego

Aby włączyć aktualizacje stref czasowych, producenci OEM mogą skonfigurować serwer systemowy, zastępując właściwości konfiguracyjne zdefiniowane w frameworks/base/core/res/res/values/config.xml .

Nieruchomość Opis Wymagane zastąpienie?
config_enableUpdateableTimeZoneRules
Aby włączyć usługę RulesManagerService, należy ustawić wartość true . Tak
config_timeZoneRulesUpdateTrackingEnabled
Należy ustawić wartość true , aby system nasłuchiwał zmian w aplikacji Dane. Tak
config_timeZoneRulesDataPackage
Nazwa pakietu aplikacji danych specyficznej dla OEM. Tak
config_timeZoneRulesUpdaterPackage
Skonfigurowano dla domyślnej aplikacji Updater. Zmień tylko w przypadku zapewnienia innej implementacji aplikacji Updater. NIE
config_timeZoneRulesCheckTimeMillisAllowed
Czas między uruchomieniem sprawdzania aktualizacji przez usługę RulesManagerService a odpowiedzią dotyczącą instalacji, dezinstalacji lub braku działania. Po tym momencie może zostać wygenerowany spontaniczny wyzwalacz niezawodności. NIE
config_timeZoneRulesCheckRetryCount
Liczba kolejnych nieudanych kontroli aktualizacji, które mogą zostać wykonane, zanim usługa RulesManagerService przestanie generować kolejne aktualizacje. NIE

Zastąpienia konfiguracji powinny znajdować się w obrazie systemu (nie od dostawcy ani innego), ponieważ źle skonfigurowane urządzenie może odmówić uruchomienia. Jeśli zmiany konfiguracji znajdowały się w obrazie dostawcy, aktualizacja do obrazu systemu bez aplikacji Data (lub z różnymi nazwami pakietów aplikacji Data/Updater) zostałaby uznana za błędną konfigurację.

Testy xTS

xTS odnosi się do dowolnego zestawu testów specyficznego dla OEM, który jest podobny do standardowych zestawów testów Androida korzystających z Tradefed (takich jak CTS i VTS). Producenci OEM posiadający takie zestawy testów mogą dodać testy aktualizacji strefy czasowej Androida dostępne w następujących lokalizacjach:

  • packages/apps/TimeZoneData/testing/xts zawiera kod potrzebny do podstawowych automatycznych testów funkcjonalnych.
  • packages/apps/TimeZoneData/oem_template/xts zawiera przykładową strukturę katalogów umożliwiającą włączenie testów do pakietu xTS podobnego do Tradefed. Podobnie jak w przypadku innych katalogów szablonów, od producentów OEM oczekuje się kopiowania i dostosowywania do swoich potrzeb.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt zawiera konfigurację na czas kompilacji, umożliwiającą uwzględnienie wstępnie skompilowanych testowych plików APK wymaganych przez test.

Tworzenie aktualizacji stref czasowych

Kiedy IANA wypuszcza nowy zestaw reguł dotyczących stref czasowych, zespół bibliotek podstawowych systemu Android generuje poprawki w celu aktualizacji wydań w AOSP. Producenci OEM korzystający ze standardowego systemu Android i plików dystrybucyjnych mogą pobrać te zatwierdzenia, użyć ich do utworzenia nowej wersji aplikacji Data, a następnie wypuścić nową wersję, aby zaktualizować swoje urządzenia w fazie produkcyjnej.

Ponieważ aplikacje danych zawierają pliki dystrybucyjne ściśle powiązane z wersjami Androida, producenci OEM muszą utworzyć nową wersję aplikacji Data dla każdej obsługiwanej wersji Androida, którą producent OEM chce zaktualizować. Na przykład, jeśli producent OEM chce dostarczać aktualizacje dla urządzeń z Androidem 8.1, 9 i 10, musi wykonać ten proces trzykrotnie.

Krok 1: Aktualizacja plików danych systemowych/strefy czasowej i zewnętrznych/icu

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

Łatka AOSP system/timezone zawiera zaktualizowane pliki w 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 system/timezone/input_data i external/icu do wygenerowania plików w output_data .

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

Krok 2: Aktualizacja kodu 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, aby została rozpoznana jako nowa i zastąpiła wcześniej załadowaną aplikację Data lub zainstalowaną na urządzeniu poprzednią aktualizacją.

Tworząc aplikację Data przy użyciu plików skopiowanych z package/apps/TimeZoneData/oem_template/data_app , kod wersji/nazwę wersji zastosowaną do pliku APK można znaleźć w pliku Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Podobne wpisy można znaleźć w testing/Android.mk (jednak kody wersji testowej muszą być wyższe niż wersja obrazu systemu). Aby uzyskać szczegółowe informacje, zobacz przykładowy schemat strategii kodu wersji ; jeśli używany jest schemat przykładowy lub podobny, kody wersji testowej nie muszą być aktualizowane, ponieważ z pewnością są wyższe niż kody wersji rzeczywistej.

Krok 3: Przebudowa, podpisywanie, testowanie i wydawanie

Na tym etapie producenci OEM odbudowują plik APK za pomocą tapas, podpisują wygenerowany plik APK, a następnie testują i wydają plik APK:

  • W przypadku niewydanych jeszcze urządzeń (lub podczas przygotowywania aktualizacji systemu dla wypuszczonego urządzenia) prześlij nowe pliki APK do wstępnie utworzonego katalogu aplikacji Data, aby upewnić się, że obraz systemu i testy xTS zawierają najnowsze pliki APK. Producenci OEM powinni sprawdzić, czy nowy plik działa poprawnie (tzn. przechodzi test CTS oraz wszelkie testy automatyczne i ręczne specyficzne dla OEM).
  • W przypadku wydanych urządzeń, które nie otrzymują już aktualizacji systemu, podpisany plik APK może zostać wydany wyłącznie za pośrednictwem sklepu z aplikacjami.

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

Strategia kodu wersji aplikacji danych

Aplikacja Dane musi mieć odpowiednią strategię wersjonowania , aby mieć pewność, że urządzenia otrzymają prawidłowe pliki APK. Na przykład, jeśli otrzymana zostanie aktualizacja systemu zawierająca plik APK starszy niż ten pobrany ze sklepu z aplikacjami, należy zachować wersję ze sklepu z aplikacjami.

Kod wersji APK powinien zawierać następujące informacje:

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

Obecnie poziom API platformy jest silnie powiązany z wersją w formacie dystrybucji, ponieważ każdy poziom API jest zwykle powiązany z nową wersją ICU (co powoduje, że pliki dystrybucji są niekompatybilne). W przyszłości system Android może to zmienić, aby plik dystrybucyjny mógł działać na wielu wersjach platformy Android (a poziom interfejsu API nie jest używany w schemacie kodu wersji aplikacji Data).

Przykładowa strategia kodu wersji

Ten przykładowy schemat numerowania wersji zapewnia, że ​​wersje w wyższym formacie dystrybucji zastępują wersje w niższym formacie dystrybucji. AndroidManifest.xml używa narzędzia android:minSdkVersion , aby mieć pewność, że stare urządzenia nie otrzymają wersji w wyższym formacie dystrybucji, niż są w stanie obsłużyć.

Kontrola wersji
Rysunek 6. Przykładowa strategia kodu wersji
Przykład Wartość Zamiar
Y Skryty Umożliwia przyszłe alternatywne schematy/testowanie plików APK. Początkowo jest to (domyślnie) 0. Ponieważ typ bazowy jest 32-bitowym typem int ze znakiem, ten schemat obsługuje maksymalnie dwie przyszłe wersje schematu numerowania.
01 Wersja w głównym formacie Śledzi wersję głównego formatu z trzema cyframi dziesiętnymi. Format dystrybucji obsługuje 3 cyfry dziesiętne, ale tutaj używane są tylko 2 cyfry. Jest mało prawdopodobne, że osiągnie 100, biorąc pod uwagę oczekiwany duży przyrost na poziom API. Wersja główna 1 jest odpowiednikiem poziomu API 27.
1 Wersja w mniejszym formacie Śledzi wersję mniejszego formatu 3-cyfrowego dziesiętnego. Format dystrybucji obsługuje 3 cyfry dziesiętne, ale tutaj używana jest tylko 1 cyfra. Mało prawdopodobne, że dotrze do 10.
X Skryty Wynosi 0 w przypadku wersji produkcyjnych (i może być inny w przypadku testowych plików APK).
ZZZZZ Nieprzezroczysty numer wersji Liczba dziesiętna przydzielana na żądanie. Zawiera luki umożliwiające w razie potrzeby wprowadzenie aktualizacji śródmiąższowych.

Schemat mógłby być lepiej spakowany, gdyby zamiast dziesiętnego użyto formatu binarnego, ale ten schemat ma tę zaletę, że jest czytelny dla człowieka. Jeśli pełny zakres numerów zostanie wyczerpany, nazwa pakietu aplikacji danych może ulec zmianie.

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 przedstawiono w poniższej tabeli.

# Kod wersji wersja minSdk {Wersja w głównym formacie},{Wersja w mniejszym formacie},{Wersja zasad IANA},{Rewizja}
1 11000010 O-MR1 major=001, minor=001,iana=2017a, wersja=1
2 21000010 P major=002, minor=001,iana=2017a, wersja=1
3 11000020 O-MR1 major=001, minor=001,iana=2017a, wersja=2
4 11000030 O-MR1 major=001, minor=001,iana=2017b, wersja=1
5 21000020 P major=002, minor=001,iana=2017b, wersja=1
6 11000040 O-MR1 major=001, minor=001,iana=2018a, wersja=1
7 21000030 P major=002, minor=001,iana=2018a, wersja=1
8 1123456789 - -
9 11000021 O-MR1 główny = 001, drugorzędny = 001,iana = 2017a, wersja = 2, respin = 2
  • Przykłady 1 i 2 pokazują dwie wersje APK dla tej samej wersji IANA 2017a z różnymi wersjami głównych formatów. 2 jest liczbowo większe niż 1, co jest potrzebne, aby nowsze urządzenia otrzymały wersje w wyższym formacie. MinSdkVersion zapewnia, że ​​wersja P nie będzie dostarczana do urządzeń O.
  • Przykład 3 to wersja/poprawka dla 1, która jest liczbowo większa niż 1.
  • Przykłady 4 i 5 pokazują wydania 2017b dla O-MR1 i P. Ponieważ są one liczbowo wyższe, zastępują wcześniejsze wydania IANA/wersje Androida ich odpowiednich poprzedników.
  • Przykłady 6 i 7 przedstawiają wydania 2018a dla O-MR1 i P.
  • Przykład 8 demonstruje użycie Y do całkowitego zastąpienia schematu Y=0.
  • Przykład 9 ilustruje wykorzystanie luki pozostawionej pomiędzy cyframi 3 i 4 w celu ponownego uruchomienia aplikacji.

Ponieważ każde urządzenie jest dostarczane z domyślnym pakietem APK o odpowiedniej wersji w obrazie systemu, nie ma ryzyka zainstalowania wersji O-MR1 na urządzeniu P, ponieważ ma ona niższy numer wersji niż wersja obrazu systemu P. Urządzenie z wersją O-MR1 zainstalowaną w /data , które następnie otrzymuje aktualizację systemu do P, używa wersji /system zamiast wersji O-MR1 w /data , ponieważ wersja P jest zawsze wyższa niż jakakolwiek aplikacja przeznaczona dla O- MR1.

Tworzenie aplikacji danych przy użyciu tapas

Producenci OEM są odpowiedzialni za zarządzanie większością aspektów aplikacji Dane strefy czasowej i prawidłową konfigurację obrazu systemu. Aplikacja Data ma zostać zbudowana w oparciu o kompilację tapas , która tworzy pliki APK, które można dodać do obrazu systemu (w przypadku pierwszej wersji) oraz podpisać i rozpowszechniać za pośrednictwem sklepu z aplikacjami (w przypadku kolejnych aktualizacji).

Tapas to odchudzona wersja systemu kompilacji Androida, która wykorzystuje zmniejszone drzewo źródeł do tworzenia dystrybuowalnych wersji aplikacji. Producenci OEM zaznajomieni z normalnym systemem kompilacji Androida powinni rozpoznać pliki kompilacji ze zwykłej kompilacji platformy Android.

Tworzenie manifestu

Zredukowane drzewo źródłowe zwykle osiąga się za pomocą niestandardowego pliku manifestu, który odnosi się tylko do projektów Git potrzebnych systemowi kompilacji i do budowania aplikacji. Po wykonaniu instrukcji w sekcji Tworzenie aplikacji danych producenci OEM powinni mieć co najmniej dwa projekty Git specyficzne 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 (na przykład vendor/ oem /apps/TimeZoneData ). Ten projekt zawiera również reguły kompilacji testowych plików APK, które mogą być używane w testach xTS.
  • Jeden projekt Git zawiera podpisane pliki APK utworzone przez kompilację aplikacji w celu uwzględnienia ich w kompilacji obrazu systemu i testach xTS.

Kompilacja aplikacji wykorzystuje kilka innych projektów Git, które są współdzielone z kompilacją platformy lub zawierają biblioteki kodów niezależne od OEM.

Poniższy fragment manifestu zawiera minimalny zestaw projektów Git potrzebnych do obsługi kompilacji O-MR1 aplikacji Dane strefy czasowej. Producenci OEM muszą dodać swoje projekty Git specyficzne dla OEM (które zazwyczaj obejmują projekt zawierający certyfikat podpisywania) do tego manifestu 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" />

Uruchamianie kompilacji tapas

Po utworzeniu drzewa źródłowego wywołaj kompilację tapas , używając następujących 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 do testowania. Pliki te można umieścić we wstępnie utworzonym katalogu w celu umieszczenia w obrazie systemu i/lub rozpowszechniać za pośrednictwem sklepu z aplikacjami dla kompatybilnych urządzeń.