Zasady dotyczące stref czasowych

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Android 10 wycofuje mechanizm aktualizacji danych strefy czasowej oparty na pakiecie APK (dostępny w systemach Android 8.1 i Android 9) i zastępuje go mechanizmem aktualizacji modułu opartym na APEX . AOSP od 8.1 do 13 nadal zawierają kod platformy niezbędny producentom OEM do włączania aktualizacji opartych na pakiecie APK, dzięki czemu urządzenia aktualizowane do systemu Android 10 mogą nadal otrzymywać aktualizacje danych strefy czasowej dostarczane przez partnera za pośrednictwem pakietu APK. Jednak mechanizm aktualizacji APK nie powinien być używany na urządzeniu produkcyjnym, które również otrzymuje aktualizacje modułów, ponieważ aktualizacja oparta na APK zastępuje aktualizację opartą na APEX (to znaczy, że 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 lub nowszym aktualizuje czas letni (DST) i strefy czasowe na urządzeniach z systemem Android, standaryzując dane, które mogą się często zmieniać ze względów religijnych, politycznych i geopolitycznych.

Aktualizacje wykorzystują następujący proces:

  1. IANA publikuje aktualizację bazy danych stref czasowych publikuje aktualizację w odpowiedzi na jeden lub więcej rządów zmieniających zasadę strefy czasowej w swoich krajach.
  2. Google lub partner Android 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ą nowe dane strefy czasowej z aktualizacji.

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

Aktualizacje stref czasowych (Android 8.1–9)

Uwaga: funkcja mechanizmu aktualizacji danych stref czasowych oparta na pakiecie APK została całkowicie usunięta z systemu Android U i nowszych wersji i nie można jej znaleźć w kodzie źródłowym. Partnerzy powinni w pełni przeprowadzić migrację do modułu Time Zone Mainline.

W systemach Android 8.1 i Android 9 producenci OEM mogą używać mechanizmu opartego na pakiecie APK do przesyłania zaktualizowanych danych reguł stref czasowych na urządzenia bez konieczności aktualizacji systemu. Ten mechanizm umożliwia użytkownikom otrzymywanie aktualizacji na czas (co wydłuża użyteczny okres eksploatacji urządzenia z systemem Android) i umożliwia partnerom Androida testowanie aktualizacji stref czasowych niezależnie od aktualizacji obrazu systemu.

Zespół podstawowych bibliotek systemu Android udostępnia pliki danych niezbędne do aktualizowania 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 mogą tworzyć własne pliki danych, jeśli jest to preferowane. We wszystkich przypadkach producenci OEM zachowują kontrolę nad zapewnieniem jakości/testowaniem, harmonogramem i uruchamianiem aktualizacji reguł stref czasowych dla obsługiwanych urządzeń.

Kod źródłowy i dane strefy czasowej systemu Android

Wszystkie urządzenia z systemem Android, nawet te, które nie korzystają z tej funkcji, wymagają danych reguł stref czasowych i muszą być dostarczane z domyślnym zestawem danych reguł stref czasowych na partycji /system . Te dane 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 .
  • Kod biblioteki natywnej w bionic/ (na przykład dla mktime , wywołania systemowe localtime) używa pliku tzdata .
  • Kod biblioteki ICU4J/ICU4C w external/icu/ używa pliku icu .dat .

Te biblioteki ś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 reguł stref czasowych, dzięki czemu urządzenia będą mogły być aktualizowane bez zmiany /system .

Składniki systemu Android, które wymagają danych reguł strefy czasowej, najpierw sprawdzają następujące lokalizacje:

  • libcore/ i bionic/ 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 dla danych, których nie ma (w przypadku formatów, zlokalizowanych ciągów itp.).

Pliki dystrybucyjne

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

Format pliku dystrybucyjnego zależy od wersji systemu Android, ponieważ zawartość zmienia się wraz z wersją ICU, wymaganiami platformy Android i innymi zmianami w wydaniu. Android zapewnia 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ą używać tych plików dystrybucyjnych lub tworzyć własne, korzystając z drzewa źródłowego Androida (zawierającego skrypty i inne pliki potrzebne do generowania plików dystrybucyjnych).

Komponenty aktualizacji strefy czasowej

Aktualizacja reguł stref czasowych obejmuje przesłanie plików dystrybucyjnych na urządzenie i bezpieczną instalację zawartych w nim plików. Przeniesienie i instalacja wymaga:

  • 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 przeprowadza operacje aktualizacji strefy czasowej, pisząc do /data/misc/zoneinfo/staged . RulesManagerService może również zastępować lub usuwać już przemieszczone operacje.
  • TimeZoneUpdater , nieaktualna aplikacja systemowa (znana również jako Updater ). Producenci OEM muszą uwzględnić tę aplikację w obrazie systemu urządzeń korzystających z tej funkcji.
  • OEM TimeZoneData , aplikacja systemowa z możliwością aktualizacji (znana również jako aplikacja Data ), która przenosi pliki dystrybucyjne na urządzenie i udostępnia je w 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 poprawnego i bezpiecznego działania aktualizacji stref czasowych.

Drzewo źródłowe systemu Android zawiera ogólny kod źródłowy dla powyższych składników, z których producent OEM może korzystać bez modyfikacji. Kod testowy jest dostarczany, aby umożliwić producentom OEM automatyczne sprawdzanie, czy poprawnie włączyli tę funkcję.

Instalacja dystrybucyjna

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 (za pośrednictwem klas timezone.RulesManagerServer/timezone.PackageTracker ) obserwuje zmiany w skonfigurowanej nazwie pakietu aplikacji danych specyficznej dla producenta OEM.

    Aktualizacje aplikacji danych
    Rysunek 1. Aktualizacje aplikacji danych
  2. Proces serwera systemowego inicjuje sprawdzenie aktualizacji poprzez rozesłanie docelowej intencji z unikalnym, jednorazowym tokenem do aplikacji Updater. Serwer systemowy śledzi najnowszy wygenerowany token, dzięki czemu może określić, kiedy zakończyło się ostatnie wywołane przez niego sprawdzenie; wszelkie inne żetony są ignorowane.

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

      Zadzwoń do usługi Menedżera reguł
      Rysunek 3. Aktualizacje aplikacji danych, wywoływanie 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.

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

    Sprawdź zakończone
    Rysunek 5. Sprawdzenie zakończone
  5. Uruchom ponownie i tzdatacheck. Podczas następnego rozruchu 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 przed otwarciem innych składników systemu i rozpoczęciem korzystania z nich.
    • 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, a wersja formatu dystrybucji uległa zmianie.
    • Upewnij się, że wersja reguł IANA jest taka sama lub nowsza niż wersja w /system . Chroni to przed aktualizacją systemu, która pozostawia urządzenie ze starszymi danymi reguł strefy czasowej niż te, które znajdują się w obrazie /system .

Niezawodność

Kompleksowy proces instalacji jest asynchroniczny i podzielony na trzy procesy systemu operacyjnego. W dowolnym momencie instalacji urządzenie może utracić zasilanie, zabraknie miejsca na dysku lub napotkać inne problemy, powodując niekompletność sprawdzania instalacji. W najlepszym przypadku niepowodzenia aplikacja Updater informuje serwer systemu, że nie powiodło się; w najgorszym nieudanym przypadku usługa RulesManagerService w ogóle nie otrzymuje żadnego połączenia.

Aby to obsłużyć, kod serwera systemowego śledzi, czy wyzwolona kontrola aktualizacji została zakończona i jaki jest kod ostatniej sprawdzonej wersji aplikacji danych. Gdy urządzenie jest bezczynne i ładuje się, kod serwera systemowego może sprawdzić aktualny stan. Jeśli wykryje niekompletne sprawdzenie aktualizacji lub nieoczekiwaną wersję aplikacji danych, spontanicznie uruchomi sprawdzenie aktualizacji.

Bezpieczeństwo

Po włączeniu kod RulesManagerService na serwerze systemowym wykonuje kilka kontroli, aby upewnić się, że system jest bezpieczny w użyciu.

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

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

Integracja aktualizacji stref czasowych

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

  • Stwó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 następującymi zasadami, zapewnieniem jakości i względami bezpieczeństwa:

  • Utwórz dedykowany klucz podpisywania specyficzny dla aplikacji dla swojej aplikacji Data.
  • Utwórz strategię wydania i przechowywania wersji dla aktualizacji stref czasowych, aby zrozumieć, które urządzenia będą aktualizowane i jak mogą zapewnić, że aktualizacje są instalowane tylko na urządzeniach, które ich potrzebują. Na przykład producenci OEM mogą chcieć mieć jedną aplikację danych dla wszystkich swoich urządzeń lub mogą wybrać różne aplikacje danych dla różnych urządzeń. Decyzja ma wpływ na wybór nazwy pakietu, być może użytych kodów wersji i strategii kontroli jakości.
  • Dowiedz się, czy chcą używać danych strefy czasowej Androida z AOSP, czy tworzyć własne.

Tworzenie aplikacji danych

AOSP zawiera cały kod źródłowy i reguły kompilacji potrzebne do utworzenia aplikacji danych 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 dla rzeczywistego pakietu APK aplikacji Data, jak i dodatkowe cele do tworzenia testowych wersji aplikacji Data.

Producenci OEM mogą dostosować aplikację Data za pomocą własnej ikony, nazwy, tłumaczeń i innych szczegółów. Ponieważ jednak nie można uruchomić aplikacji Dane, ikona pojawia się tylko na ekranie Ustawienia > Aplikacje .

Aplikacja Data jest przeznaczona do zbudowania przy użyciu kompilacji tapas , która tworzy pakiety APK odpowiednie do dodania do obrazu systemu (w przypadku pierwszego wydania) oraz podpisania i dystrybucji za pośrednictwem sklepu z aplikacjami (w przypadku kolejnych aktualizacji). Aby uzyskać szczegółowe informacje na temat korzystania z tapas, zobacz Tworzenie aplikacji Dane za pomocą tapas .

Producenci OEM muszą zainstalować wstępnie skompilowaną aplikację danych w obrazie systemu urządzenia w /system/priv-app . Aby uwzględnić wstępnie skompilowane pakiety APK (generowane przez proces kompilacji tapas) w obrazie systemu, producenci OEM mogą skopiować przykładowe pliki do packages/apps/TimeZoneData/oem_template/data_app_prebuilt . Przykładowe szablony zawierają również cele kompilacji umożliwiające uwzględnienie testowych wersji aplikacji Data w zestawach testowych.

Dołączanie aplikacji Updater i Data do obrazu systemu

Producenci OEM muszą umieścić pakiety APK aplikacji Updater i Data w katalogu /system/priv-app obrazu systemu. Aby to zrobić, kompilacja obrazu systemu musi jawnie zawierać wstępnie skompilowane obiekty docelowe aplikacji Updater i aplikacji danych.

Aplikacja Updater powinna być podpisana za pomocą klucza platformy i dołączona jak każda inna aplikacja systemowa. Cel jest zdefiniowany w packages/apps/TimeZoneUpdater jako TimeZoneUpdater . Włączenie aplikacji danych jest specyficzne dla producenta OEM i zależy od nazwy docelowej wybranej dla prekompilacji.

Konfiguracja serwera systemowego

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

Nieruchomość Opis Wymagane zastąpienie?
config_enableUpdateableTimeZoneRules
Musi być ustawiona na true aby włączyć RulesManagerService. TAk
config_timeZoneRulesUpdateTrackingEnabled
Musi być ustawiona na true , aby system nasłuchiwał zmian w aplikacji Data. TAk
config_timeZoneRulesDataPackage
Nazwa pakietu aplikacji Dane specyficznej dla OEM. TAk
config_timeZoneRulesUpdaterPackage
Skonfigurowany dla domyślnej aplikacji Updater. Zmień tylko wtedy, gdy zapewniasz inną implementację aplikacji Updater. Nie
config_timeZoneRulesCheckTimeMillisAllowed
Czas dozwolony między sprawdzeniem aktualizacji wyzwolonym przez usługę RulesManagerService a odpowiedzią na instalację, dezinstalację lub nic nie robienie. Po tym punkcie może zostać wygenerowany spontaniczny wyzwalacz niezawodności. Nie
config_timeZoneRulesCheckRetryCount
Liczba kolejnych nieudanych sprawdzeń aktualizacji dozwolonych, zanim usługa RulesManagerService przestanie generować więcej. Nie

Nadpisania konfiguracji powinny znajdować się w obrazie systemu (nie dostawcy lub 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 danych (lub z różnymi nazwami aplikacji danych/pakietów aplikacji Updater) zostałaby uznana za błędną konfigurację.

Testowanie xTS

xTS odnosi się do dowolnego zestawu testów OEM, który jest podobny do standardowych zestawó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 stref czasowych systemu Android dostępne w następujących lokalizacjach:

  • packages/apps/TimeZoneData/testing/xts zawiera kod potrzebny do podstawowego automatycznego testowania funkcjonalnego.
  • packages/apps/TimeZoneData/oem_template/xts zawiera przykładową strukturę katalogów do włączania testów w pakiecie xTS podobnym do Tradefed. Podobnie jak w przypadku innych katalogów szablonów, producenci OEM powinni kopiować i dostosowywać je do swoich potrzeb.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt zawiera konfigurację czasu kompilacji umożliwiającą uwzględnienie wstępnie skompilowanych testowych pakietów APK wymaganych przez test.

Tworzenie aktualizacji stref czasowych

Gdy IANA wydaje nowy zestaw reguł stref czasowych, zespół podstawowych bibliotek systemu Android generuje poprawki aktualizujące wersje 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 wydać nową wersję, aby zaktualizować swoje urządzenia w środowisku produkcyjnym.

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

Krok 1: Aktualizuję system/strefę czasową i pliki danych zewnętrznych/icu

W tym kroku producenci OEM zbierają 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 systemu Android.

Poprawka system/timezone AOSP zawiera zaktualizowane pliki w system/timezone/input_data i system/timezone/output_data . Producenci OEM, którzy muszą wprowadzić dodatkowe lokalne poprawki, 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 kompilowania pakietu APK aplikacji Data.

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 Dane musi mieć nowy kod wersji, aby była rozpoznawana jako nowa i służyła do zastępowania wstępnie załadowanej aplikacji Dane lub aplikacji Dane zainstalowanej na urządzeniu poprzednią aktualizacją.

Podczas tworzenia aplikacji Data przy użyciu plików skopiowanych z package/apps/TimeZoneData/oem_template/data_app , możesz znaleźć kod wersji/nazwę wersji zastosowane do 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 (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 przykładowy schemat lub podobny schemat, kody wersji testowej nie muszą być aktualizowane, ponieważ gwarantuje się, że są wyższe niż rzeczywiste kody wersji.

Krok 3: Przebudowywanie, podpisywanie, testowanie i wydawanie

W tym kroku producenci OEM odbudowują pakiet APK za pomocą tapas, podpisują wygenerowany pakiet APK, a następnie testują i zwalniają pakiet APK:

  • W przypadku urządzeń, które nie zostały wydane (lub podczas przygotowywania aktualizacji systemu dla wydanego urządzenia), prześlij nowe pliki APK do katalogu gotowych 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 (to znaczy, że przechodzi CTS i 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 tylko za pośrednictwem sklepu z aplikacjami.

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

Strategia kodu wersji aplikacji danych

Aplikacja Dane musi mieć odpowiednią strategię zarządzania wersjami, aby zapewnić, że urządzenia otrzymają prawidłowe pakiety APK. Na przykład, jeśli zostanie odebrana aktualizacja systemu, która zawiera pakiet APK starszy niż ten pobrany ze sklepu z aplikacjami, wersja sklepu z aplikacjami powinna zostać zachowana.

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

  • Wersja formatu dystrybucji (główna + pomocnicza)
  • Przyrostowy (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 sprawia, że ​​pliki dystrybucyjne są niekompatybilne). W przyszłości system Android może to zmienić, aby plik dystrybucji mógł działać w wielu wersjach platformy Android (a poziom interfejsu API nie jest używany w schemacie kodu wersji aplikacji danych).

Przykładowa strategia kodu wersji

Ten przykładowy schemat numerów wersji zapewnia, że ​​wersje o wyższym formacie dystrybucji zastępują wersje o niższym formacie dystrybucji. AndroidManifest.xml używa android:minSdkVersion , aby upewnić się, że stare urządzenia nie otrzymują wersji z wyższą wersją formatu dystrybucji niż są w stanie obsłużyć.

Sprawdzenie wersji
Rysunek 6. Przykładowa strategia kodu wersji
Przykład Wartość Zamiar
Tak Skryty Pozwala na przyszłe alternatywne schematy/testowe pakiety APK. Jest to początkowo (niejawnie) 0. Ponieważ podstawowy typ jest podpisanym 32-bitowym typem int, ten schemat obsługuje maksymalnie dwie przyszłe wersje schematu numerowania.
01 Wersja głównego formatu Śledzi wersję głównego formatu z 3 cyframi dziesiętnymi. Format dystrybucji obsługuje 3 cyfry dziesiętne, ale tutaj używane są tylko 2 cyfry. Jest mało prawdopodobne, aby osiągnąć 100, biorąc pod uwagę oczekiwany duży przyrost na poziom interfejsu API. Wersja główna 1 odpowiada poziomowi API 27.
1 Wersja podrzędnego formatu Śledzi wersję drugorzędną z 3 cyframi dziesiętnymi. Format dystrybucji obsługuje 3 cyfry dziesiętne, ale tutaj używana jest tylko 1 cyfra. Jest mało prawdopodobne, że osiągnie 10.
X Skryty Wartość 0 w przypadku wersji produkcyjnych (i może być różna w przypadku testowych pakietów APK).
ZZZZZ Nieprzezroczysty numer wersji Numer dziesiętny przydzielany na żądanie. Zawiera luki umożliwiające w razie potrzeby aktualizacje reklam pełnoekranowych.

Schemat mógłby być lepiej spakowany, gdyby zamiast dziesiętnego stosowano binarny, 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 jest czytelną dla człowieka reprezentacją szczegółów, na przykład: major=001,minor=001,iana=2017a, revision=1,respin=2 . Przykłady przedstawiono w poniższej tabeli.

# Kod wersji minSdkVersion {Wersja głównego formatu},{Wersja drugorzędnego formatu},{Wersja reguł IANA},{Wersja}
1 11000010 O-MR1 główna=001,podrzędna=001,iana=2017a,weryfikacja=1
2 21000010 P główna=002,podrzędna=001,iana=2017a,weryfikacja=1
3 11000020 O-MR1 główna=001,podrzędna=001,iana=2017a,poprawka=2
4 11000030 O-MR1 główna=001,podrzędna=001,iana=2017b,weryfikacja=1
5 21000020 P główna=002,podrzędna=001,iana=2017b,weryfikacja=1
6 11000040 O-MR1 główna=001,podrzędna=001,iana=2018a,weryfikacja=1
7 21000030 P główna=002,podrzędna=001,iana=2018a,weryfikacja=1
8 1123456789 - -
9 11000021 O-MR1 główna=001,podrzędna=001,iana=2017a,poprawka=2,respin=2
  • Przykłady 1 i 2 pokazują dwie wersje APK dla tego samego wydania IANA 2017a z różnymi głównymi wersjami formatu. 2 jest liczbowo większe niż 1, co jest potrzebne do zapewnienia, że ​​nowsze urządzenia otrzymają wyższe wersje formatu. minSdkVersion zapewnia, że ​​wersja P nie będzie dostarczana do urządzeń O.
  • Przykład 3 to wersja/poprawka dla 1 i jest liczbowo wyższa niż 1.
  • Przykłady 4 i 5 pokazują wydania 2017b dla O-MR1 i P. Będąc liczbowo wyższymi, zastępują one wcześniejsze wydania IANA/wersje Androida swoich poprzedników.
  • Przykłady 6 i 7 pokazują 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 pokazuje wykorzystanie luki pozostawionej między 3 a 4 do ponownego zakręcenia apk.

Ponieważ każde urządzenie jest dostarczane z domyślnym, odpowiednio wersjonowanym pakietem APK 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.

Budowanie aplikacji Data za pomocą tapas

Producenci OEM są odpowiedzialni za zarządzanie większością aspektów aplikacji danych strefy czasowej i prawidłowe konfigurowanie obrazu systemu. Aplikacja Data jest przeznaczona do zbudowania przy użyciu kompilacji tapas , która tworzy pakiety APK odpowiednie do dodania do obrazu systemu (w przypadku pierwszego wydania) oraz podpisania i dystrybucji za pośrednictwem sklepu z aplikacjami (w przypadku kolejnych aktualizacji).

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

Tworzenie manifestu

Zredukowane drzewo źródłowe jest zwykle osiągane za pomocą niestandardowego pliku manifestu, który odwołuje się tylko do projektów Git wymaganych przez system kompilacji i do kompilowania 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 obszarze 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 dla testowych pakietów APK, które mogą być używane w testach xTS.
  • Jeden projekt Git zawiera podpisane pakiety APK utworzone przez kompilację aplikacji w celu włączenia do kompilacji obrazu systemu i testów xTS.

Kompilacja aplikacji korzysta z kilku innych projektów Git, które są współużytkowane z kompilacją platformy lub zawierają biblioteki kodu niezależne od OEM.

Poniższy fragment kodu manifestu zawiera minimalny zestaw projektów Git wymaganych do obsługi kompilacji O-MR1 aplikacji danych strefy czasowej. Producenci OEM muszą dodać swoje projekty Git specyficzne dla OEM (które zazwyczaj zawierają 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="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Uruchamianie kompilacji tapas

Po ustanowieniu drzewa źródłowego wywołaj kompilację tapas za pomocą 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ć w prekompilowanym katalogu w celu włączenia do obrazu systemu i/lub dystrybuować za pośrednictwem sklepu z aplikacjami dla zgodnych urządzeń.