Zeitzonenregeln

Unter Android 10 wird der APK-basierte Mechanismus zum Aktualisieren von Zeitzonendaten (verfügbar in Android 8.1 und Android 9) eingestellt und durch einen APEX-basierten Modulaktualisierungsmechanismus ersetzt. AOSP 8.1 bis 13 enthält weiterhin den Plattformcode, der für OEMs erforderlich ist, um APK-basierte Updates zu aktivieren. Daher können Geräte, die auf Android 10 umgestellt werden, weiterhin von Partnern bereitgestellte Zeitzonendaten über APKs erhalten. Der APK-Updatemechanismus sollte jedoch nicht auf einem Produktionsgerät verwendet werden, das auch Modulupdates erhält, da ein APK-basiertes Update ein APEX-basiertes Update ersetzt. Das bedeutet, dass auf einem Gerät, das ein APK-Update erhalten hat, APEX-basierte Updates ignoriert werden.

Zeitzonenaktualisierungen (Android 10 und höher)

Das Modul „Zeitzonendaten“, das in Android 10 und höher unterstützt wird, aktualisiert die Sommerzeit und die Zeitzonen auf Android-Geräten und standardisiert Daten, die sich aus religiösen, politischen und geopolitischen Gründen häufig ändern können.

Für Updates wird der folgende Prozess verwendet:

1. Die IANA veröffentlicht ein Update der Zeitzonendatenbank, wenn eine oder mehrere Regierungen eine Zeitzonenregel in ihren Ländern ändern.
2. Google oder der Android-Partner erstellt ein Update des Zeitzonendatenmoduls (APEX-Datei) mit den aktualisierten Zeitzonen.
3. Das Endnutzergerät lädt das Update herunter, startet neu und wendet dann die Änderungen an. Danach enthalten die Zeitzonendaten des Geräts die neuen Zeitzonendaten aus dem Update.

Weitere Informationen zu Modulen finden Sie unter Modulare Systemkomponenten.

Aktualisierungen der Zeitzone (Android 8.1–9)

Hinweis:Der APK-basierte Mechanismus zum Aktualisieren von Zeitzonendaten wurde ab Android 14 vollständig entfernt und ist nicht mehr im Quellcode zu finden. Partner sollten vollständig zum Mainline-Modul „Zeitzone“ migrieren.

Unter Android 8.1 und Android 9 können OEMs mit einem APK-basierten Mechanismus aktualisierte Daten zu Zeitzonenregeln auf Geräte pushen, ohne dass ein Systemupdate erforderlich ist. Mit diesem Mechanismus erhalten Nutzer zeitnah Updates, wodurch sich die Nutzungsdauer eines Android-Geräts verlängert. Außerdem können Android-Partner Zeitzonenupdates unabhängig von System-Image-Updates testen.

Das Android-Team für die Hauptbibliotheken stellt die erforderlichen Datendateien zum Aktualisieren der Zeitzonenregeln auf einem Standard-Android-Gerät bereit. OEMs können diese Datendateien verwenden, wenn sie Zeitzonenupdates für ihre Geräte erstellen, oder sie können ihre eigenen Datendateien erstellen. In allen Fällen behalten die OEMs die Kontrolle über die Qualitätssicherung/-tests, das Timing und die Einführung von Zeitzonenregelaktualisierungen für ihre unterstützten Geräte.

Quellcode und Daten der Android-Zeitzone

Alle Android-Geräte mit vorinstalliertem Betriebssystem, auch solche, auf denen diese Funktion nicht verwendet wird, benötigen Zeitzonenregeln. Sie müssen in der Partition /system standardmäßig mit Zeitzonenregeln geliefert werden. Diese Daten werden dann von Code aus den folgenden Bibliotheken im Android-Quellcode verwendet:

• Für verwalteten Code aus libcore/ (z. B. java.util.TimeZone) werden tzdata- und tzlookup.xml-Dateien verwendet.
• Für den Code nativer Bibliotheken in bionic/ (z. B. für mktime, Systemaufrufe für die Ortszeit) wird die Datei tzdata verwendet.
• Der ICU4J-/ICU4C-Bibliothekcode in external/icu/ verwendet die Datei icu.dat.

In diesen Bibliotheken werden Overlay-Dateien im Verzeichnis /data/misc/zoneinfo/current verwaltet. Overlay-Dateien enthalten voraussichtlich verbesserte Daten zu Zeitzonenregeln, sodass Geräte aktualisiert werden können, ohne /system zu ändern.

Android-Systemkomponenten, die Zeitzonenregeldaten benötigen, prüfen zuerst die folgenden Speicherorte:

• Für den libcore/- und bionic/-Code wird die /data-Kopie der tzdata- und tzlookup.xml-Dateien verwendet.
• ICU4J-/ICU4C-Code verwendet die Dateien in /data und greift bei nicht vorhandenen Daten (z. B. Formate, lokalisierte Strings) auf /system-Dateien zurück.

Distro-Dateien

Distro-.zip-Dateien enthalten die Datendateien, die zum Ausfüllen des Verzeichnisses /data/misc/zoneinfo/current erforderlich sind. Die Distributionsdateien enthalten außerdem Metadaten, mit denen Geräte Versionsprobleme erkennen können.

Das Distributionsdateiformat ist vom Android-Release abhängig, da sich der Inhalt mit der ICU-Version, den Anforderungen der Android-Plattform und anderen Release-Änderungen ändert. Android stellt für jedes IANA-Update Distributionsdateien für unterstützte Android-Releases bereit (zusätzlich zur Aktualisierung der Plattformsystemdateien). Um ihre Geräte auf dem neuesten Stand zu halten, können OEMs diese Distributionsdateien verwenden oder eigene mit dem Android-Quellcodebaum erstellen, der die Scripts und anderen Dateien enthält, die zum Generieren von Distributionsdateien erforderlich sind.

Komponenten für die Zeitzonenaktualisierung

Ein Update der Zeitzonenregeln umfasst die Übertragung von Distributionsdateien auf ein Gerät und die sichere Installation der darin enthaltenen Dateien. Für die Übertragung und Installation ist Folgendes erforderlich:

• Plattformdienstfunktion (timezone.RulesManagerService), die standardmäßig deaktiviert ist. OEMs müssen die Funktion über die Konfiguration aktivieren. RulesManagerService wird im Systemserverprozess ausgeführt und führt Zeitzonenaktualisierungsvorgänge aus, indem es in /data/misc/zoneinfo/staged schreibt. Mit RulesManagerService können Sie auch bereits bereitgestellte Vorgänge ersetzen oder löschen.
• TimeZoneUpdater, eine nicht aktualisierbare System-App (Updater App). OEMs müssen diese App in das System-Image von Geräten aufnehmen, auf denen die Funktion verwendet wird.
• OEMTimeZoneData: eine aktualisierbare System-App (auch Daten-App genannt), die Distributionsdateien auf das Gerät überträgt und für die Update-App verfügbar macht. OEMs müssen diese App in das System-Image von Geräten aufnehmen, auf denen die Funktion verwendet wird.
• tzdatacheck, ein Binärprogramm zur Bootzeit, das für den korrekten und sicheren Betrieb von Zeitzonenaktualisierungen erforderlich ist.

Der Android-Quellbaum enthält generischen Quellcode für die oben genannten Komponenten, den der OEM unverändert verwenden kann. Der Testcode ermöglicht es OEMs, automatisch zu prüfen, ob sie die Funktion richtig aktiviert haben.

Installation der Distribution

Die Installation der Distribution umfasst die folgenden Schritte:

1. Die Daten-App wird über einen App-Shop-Download oder Sideload aktualisiert. Der Systemserverprozess prüft über timezone.RulesManagerServer/timezone.PackageTracker-Klassen, ob sich der konfigurierte, OEM-spezifische Name des Daten-App-Pakets geändert hat.
   
   

   Abbildung 1: Updates der Daten-App.

2. Der Systemserverprozess löst eine Updateprüfung aus, indem er eine zielgerichtete Absicht mit einem eindeutigen Einmaltoken an die Updater App sendet. Der Systemserver überwacht das zuletzt generierte Token, um zu ermitteln, wann die letzte von ihm ausgelöste Prüfung abgeschlossen wurde. Alle anderen Tokens werden ignoriert.
   
   

   Abbildung 2: Update-Prüfung auslösen

3. Während der Updateprüfung führt die Update-App die folgenden Aufgaben aus:
   • Ruft den aktuellen Gerätestatus durch Aufrufen des RulesManagerService ab.
     
     

     Abbildung 3: Daten-App-Updates, Aufruf von RulesManagerService

   • Die Data App wird durch Abfragen einer klar definierten ContentProvider-URL und Spaltenspezifikationen abgefragt, um Informationen zur Distribution zu erhalten.
     
     

     Abbildung 4: Daten-App-Updates, Informationen zur Distribution abrufen

4. Die Updater App ergreift die entsprechenden Maßnahmen, basierend auf den verfügbaren Informationen. Zu den verfügbaren Aktionen gehören:
   • Installation anfordern Distributionsdaten werden aus der Data App gelesen und an den RulesManagerService auf dem Systemserver übergeben. Der RulesManagerService bestätigt noch einmal, dass die Version und der Inhalt des Distributionsformats für das Gerät geeignet sind, und startet die Installation.
   • Deinstallation beantragen (dies kommt selten vor). Beispiel: Die aktualisierte APK in /data wird deaktiviert oder deinstalliert und das Gerät kehrt zur Version in /system zurück.
   • Nichts unternehmen: Tritt auf, wenn die Data App-Distribution ungültig ist.
   In allen Fällen ruft die Updater-App den RulesManagerService mit dem Prüftoken auf, damit der Systemserver weiß, dass die Prüfung abgeschlossen und erfolgreich war.
   
   

   Abbildung 5: Überprüfung abgeschlossen.

5. Neu starten und tzdatacheck ausführen. Beim nächsten Starten des Geräts führt die tzdatacheck-Binärdatei alle geplanten Vorgänge aus. Die Binärdatei „tzdatacheck“ kann die folgenden Aufgaben ausführen:
   • Führen Sie den geplanten Vorgang aus, indem Sie die /data/misc/zoneinfo/current-Dateien erstellen, ersetzen und/oder löschen, bevor andere Systemkomponenten die Dateien geöffnet und verwendet haben.
   • Prüfen Sie, ob die Dateien in /data für die aktuelle Plattformversion korrekt sind. Das ist möglicherweise nicht der Fall, wenn das Gerät gerade ein Systemupdate erhalten hat und sich die Version des Distributionsformats geändert hat.
   • Die IANA-Regeln müssen dieselbe oder eine neuere Version als die in /system haben. So wird verhindert, dass ein Systemupdate auf einem Gerät ältere Zeitzonenregeln hinterlässt als im /system-Image vorhanden sind.

Zuverlässigkeit

Der End-to-End-Installationsprozess ist asynchron und auf drei Betriebssystemprozesse aufgeteilt. Während der Installation kann der Strom ausfallen, der Speicherplatz auf dem Gerät kann aufgebraucht sein oder es können andere Probleme auftreten, die dazu führen, dass die Installationsüberprüfung unvollständig ist. Im besten Fall informiert die Updater-App den Systemserver über den Fehler. Im schlimmsten Fall erhält der RulesManagerService gar keinen Aufruf.

Dazu wird im Systemservercode erfasst, ob eine ausgelöste Updateprüfung abgeschlossen ist und welcher Versionscode der Daten-App zuletzt geprüft wurde. Wenn das Gerät inaktiv ist und geladen wird, kann der Systemservercode den aktuellen Status prüfen. Wenn eine unvollständige Updateprüfung oder eine unerwartete Version der Daten-App erkannt wird, wird eine Updateprüfung spontan ausgelöst.

Sicherheit

Wenn diese Funktion aktiviert ist, führt der RulesManagerService-Code auf dem Systemserver mehrere Prüfungen durch, um sicherzustellen, dass das System sicher verwendet werden kann.

• Probleme, die auf ein schlecht konfiguriertes Systemimage hinweisen, verhindern das Starten eines Geräts. Beispiele hierfür sind eine fehlerhafte Konfiguration der Update- oder Daten-App oder das Fehlen der Update- oder Daten-App in /system/priv-app.
• Probleme, die darauf hinweisen, dass eine fehlerhafte Daten-App installiert wurde, verhindern nicht das Starten des Geräts, aber die Auslösung einer Updateprüfung. Beispiele hierfür sind fehlende erforderliche Systemberechtigungen oder das Fehlen eines Content-Providers der Daten-App unter dem erwarteten URI.

Die Dateiberechtigungen für die /data/misc/zoneinfo-Verzeichnisse werden mit SELinux-Regeln erzwungen. Wie bei jedem APK muss die Daten-App mit demselben Schlüssel signiert sein, der auch für die Signatur der /system/priv-app-Version verwendet wurde. Die Daten-App sollte einen speziellen, OEM-spezifischen Paketnamen und -schlüssel haben.

Zeitzonenaktualisierungen einbinden

Um die Funktion zum Aktualisieren der Zeitzone zu aktivieren, gehen OEMs in der Regel so vor:

• Eigene Daten-App erstellen
• Fügen Sie die Updater- und Data-Apps in den Build des System-Images ein.
• Konfigurieren Sie den Systemserver, um den RulesManagerService zu aktivieren.

Vorbereitung

Vor Beginn sollten OEMs die folgenden Richtlinien, Qualitätssicherungs- und Sicherheitsaspekte prüfen:

• Erstellen Sie einen speziellen app-spezifischen Signaturschlüssel für die Daten-App.
• Erstellen Sie eine Release- und Versionierungsstrategie für Zeitzonenupdates, um zu erfahren, welche Geräte aktualisiert werden und wie Sie dafür sorgen können, dass Updates nur auf Geräten installiert werden, auf denen sie benötigt werden. OEMs können beispielsweise eine einzige Daten-App für alle ihre Geräte oder unterschiedliche Daten-Apps für unterschiedliche Geräte verwenden. Die Entscheidung wirkt sich auf die Auswahl des Paketnamens, gegebenenfalls auf die verwendeten Versionscodes und die QA-Strategie aus.
• Ermitteln Sie, ob die Standardzeitzonendaten von Android aus AOSP verwendet oder eigene erstellt werden sollen.

Daten-App erstellen

AOSP enthält den gesamten Quellcode und alle Build-Regeln, die zum Erstellen einer Daten-App in packages/apps/TimeZoneData erforderlich sind, sowie Anleitungen und Beispielvorlagen für AndroidManifest.xml und andere Dateien in packages/apps/TimeZoneData/oem_template. Beispielvorlagen enthalten sowohl ein Build-Ziel für das APK der echten Daten-App als auch zusätzliche Ziele zum Erstellen von Testversionen der Daten-App.

OEMs können die Daten-App mit einem eigenen Symbol, Namen, Übersetzungen und anderen Details anpassen. Da die Daten-App jedoch nicht gestartet werden kann, wird das Symbol nur auf dem Bildschirm Einstellungen > Apps angezeigt.

Die Daten-App soll mit einem tapas-Build erstellt werden, der APKs generiert, die dem System-Image (für die erste Version) hinzugefügt und signiert und über einen App-Shop verteilt werden können (für nachfolgende Updates). Weitere Informationen zur Verwendung von tapas finden Sie unter Data App mit tapas erstellen.

OEMs müssen die Daten-App, die im System-Image eines Geräts vorinstalliert ist, in /system/priv-app installieren. Wenn OEMs vorgefertigte APKs (die durch den Build-Prozess von tapas generiert wurden) in das System-Image aufnehmen möchten, können sie die Beispieldateien in packages/apps/TimeZoneData/oem_template/data_app_prebuilt kopieren. Die Beispielvorlagen enthalten auch Build-Ziele, um Testversionen der Data App in Test-Suites aufzunehmen.

Updater- und Daten-Apps in das System-Image aufnehmen

OEMs müssen die APKs der Update- und Daten-App im Verzeichnis /system/priv-app des System-Images ablegen. Dazu müssen die vorkonfigurierten Ziele der Updater App und der Data App explizit in den Build des System-Images aufgenommen werden.

Die Update-App muss mit dem Plattformschlüssel signiert und wie jede andere System-App eingebunden sein. Das Ziel wird in packages/apps/TimeZoneUpdater als TimeZoneUpdater definiert. Die Einbeziehung der Daten-App ist OEM-spezifisch und hängt vom Zielnamen ab, der für die Vorabversion ausgewählt wurde.

Systemserver konfigurieren

Um Zeitzonenupdates zu aktivieren, können OEMs den Systemserver konfigurieren, indem sie die in frameworks/base/core/res/res/values/config.xml definierten Konfigurationseigenschaften überschreiben.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Konfigurationsüberschreibungen sollten sich im System-Image befinden (nicht im Anbieter-Image oder einem anderen), da ein falsch konfiguriertes Gerät möglicherweise nicht startet. Wenn sich die Konfigurationsüberschreibungen im Anbieter-Image befinden, wird ein Update auf ein System-Image ohne Daten-App (oder mit anderen Namen für das Daten-App-/Updater-App-Paket) als Fehlkonfiguration betrachtet.

xTS-Tests

„xTS“ bezieht sich auf jede OEM-spezifische Testsuite, die Standard-Android-Testsuites mit Tradefed ähnelt (z. B. CTS und VTS). OEMs mit solchen Testsuites können die Tests zum Aktualisieren der Zeitzone in Android an den folgenden Stellen hinzufügen:

• packages/apps/TimeZoneData/testing/xts enthält den Code, der für grundlegende automatisierte Funktionstests erforderlich ist.
• packages/apps/TimeZoneData/oem_template/xts enthält ein Beispielverzeichnis für die Einbindung von Tests in eine Tradefed-ähnliche xTS-Suite. Wie bei anderen Vorlagenverzeichnissen müssen OEMs die Vorlagen kopieren und an ihre Anforderungen anpassen.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt enthält die Buildzeitkonfiguration zum Einbeziehen der für den Test erforderlichen vorgefertigten Test-APKs.

Zeitzonenaktualisierungen erstellen

Wenn die IANA neue Zeitzonenregeln veröffentlicht, generiert das Team für die Android-Kernbibliotheken Patches, um die Releases in AOSP zu aktualisieren. OEMs, die das Standard-Android-System und die Distributionsdateien verwenden, können diese Commits übernehmen, eine neue Version ihrer Daten-App damit erstellen und dann die neue Version veröffentlichen, um ihre Geräte in der Produktion zu aktualisieren.

Da Daten-Apps Distributionsdateien enthalten, die eng mit Android-Versionen verknüpft sind, müssen OEMs für jede unterstützte Android-Version, die ein OEM aktualisieren möchte, eine neue Version der Daten-App erstellen. Wenn ein OEM beispielsweise Updates für Geräte mit Android 8.1, 9 und 10 bereitstellen möchte, muss er den Vorgang dreimal ausführen.

Schritt 1: System-/Zeitzonen- und externe/icu-Dateien aktualisieren

In diesem Schritt übernehmen OEMs Android-Commits für system/timezone und external/icu aus den release-Dev-Branches in AOSP und wenden diese Commits auf ihre Kopie des Android-Quellcodes an.

Der AOSP-Patch für „system/timezone“ enthält aktualisierte Dateien in system/timezone/input_data und system/timezone/output_data. OEMs, die zusätzliche lokale Fehlerkorrekturen vornehmen müssen, können die Eingabedateien ändern und dann die Dateien in system/timezone/input_data und external/icu verwenden, um Dateien in output_data zu generieren.

Die wichtigste Datei ist system/timezone/output_data/distro/distro.zip. Sie wird automatisch beim Erstellen des APK der Daten-App eingefügt.

Schritt 2: Versionscode der Daten-App aktualisieren

In diesem Schritt aktualisieren OEMs den Versionscode der Daten-App. distro.zip wird automatisch vom Build übernommen, aber die neue Version der Daten-App muss einen neuen Versionscode haben, damit sie als neu erkannt und verwendet wird, um eine vorinstallierte Daten-App oder eine Daten-App zu ersetzen, die durch ein vorheriges Update auf einem Gerät installiert wurde.

Wenn Sie die Daten-App mit Dateien erstellen, die aus package/apps/TimeZoneData/oem_template/data_app kopiert wurden, finden Sie den Versionscode/-namen, der auf das APK angewendet wurde, in Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Ähnliche Einträge finden Sie in testing/Android.mk. Die Versionscodes der Testversionen müssen jedoch höher sein als die Version des System-Images. Weitere Informationen finden Sie im Beispiel für ein Schema für die Versionscodestrategie. Wenn das Beispielschema oder ein ähnliches Schema verwendet wird, müssen die Testversionscodes nicht aktualisiert werden, da sie garantiert höher sind als die tatsächlichen Versionscodes.

Schritt 3: Neu erstellen, signieren, testen und veröffentlichen

In diesem Schritt erstellen OEMs das APK mit tapas neu, signieren das generierte APK und testen und veröffentlichen es dann:

• Reichen Sie für noch nicht veröffentlichte Geräte (oder bei der Vorbereitung eines Systemupdates für ein veröffentlichtes Gerät) die neuen APKs im Verzeichnis „Prebuilt“ der Data App ein, damit das System-Image und die xTS-Tests die neuesten APKs enthalten. OEMs sollten testen, ob die neue Datei richtig funktioniert, d. h., ob sie den CTS und alle OEM-spezifischen automatisierten und manuellen Tests besteht.
• Für auf den Markt gebrachte Geräte, die keine Systemupdates mehr erhalten, kann die signierte APK möglicherweise nur über einen App-Shop veröffentlicht werden.

OEMs sind für die Qualitätssicherung und das Testen der aktualisierten Daten-App auf ihren Geräten vor der Veröffentlichung verantwortlich.

Strategie für den Code der App-Version

Die Daten-App muss eine geeignete Versionierungsstrategie haben, damit Geräte die richtigen APKs erhalten. Wenn beispielsweise ein Systemupdate empfangen wird, das ein älteres APK als das aus dem App-Shop heruntergeladene enthält, sollte die App-Shop-Version beibehalten werden.

Der APK-Versionscode sollte die folgenden Informationen enthalten:

• Version im Distributionsformat (Hauptversion + Nebenversion)
• Eine inkrementelle (nicht transparente) Versionsnummer

Derzeit ist die Plattform-API-Ebene stark mit der Version des Distributionsformats korreliert, da jede API-Ebene in der Regel mit einer neuen Version von ICU verknüpft ist, was die Distributionsdateien inkompatibel macht. In Zukunft kann Android dies ändern, sodass eine Distributionsdatei für mehrere Android-Plattformversionen verwendet werden kann (und die API-Ebene nicht im Codeschema der Daten-App-Version verwendet wird).

Beispiel für eine Strategie für Versionscodes

Dieses Beispiel für ein Nummerierungsschema für Versionen sorgt dafür, dass höhere Versionen des Distributionsformats niedrigere Versionen des Distributionsformats ersetzen. AndroidManifest.xml verwendet android:minSdkVersion, um dafür zu sorgen, dass alte Geräte keine Versionen mit einer höheren Distributionsformatversion erhalten, als sie verarbeiten können.

Abbildung 6 Beispiel für eine Versionscodestrategie

Das Schema könnte besser komprimiert werden, wenn anstelle des Dezimalsystems das Binärsystem verwendet würde. Dieses Schema hat jedoch den Vorteil, dass es für Menschen lesbar ist. Wenn der gesamte Zahlenbereich aufgebraucht ist, kann sich der Paketname der Daten-App ändern.

Der Versionsname ist eine für Menschen lesbare Darstellung der Details, z. B. major=001,minor=001,iana=2017a, revision=1,respin=2. Beispiele finden Sie in der folgenden Tabelle.

• In den Beispielen 1 und 2 sind zwei APK-Versionen für dieselbe IANA-Version 2017a mit unterschiedlichen Hauptformatversionen zu sehen. 2 ist numerisch größer als 1. Dies ist erforderlich, damit neuere Geräte die höheren Formatversionen erhalten. Mit der „minSdkVersion“ wird sichergestellt, dass die P-Version nicht für O-Geräte bereitgestellt wird.
• Beispiel 3 ist eine Überarbeitung/Korrektur von 1 und ist numerisch höher als 1.
• In den Beispielen 4 und 5 sind die 2017b-Releases für O-MR1 und P zu sehen. Da sie numerisch höher sind, ersetzen sie die vorherigen IANA-Releases/Android-Versionen ihrer jeweiligen Vorgänger.
• In den Beispielen 6 und 7 sind die 2018a-Releases für O-MR1 und P zu sehen.
• In Beispiel 8 wird gezeigt, wie Y das Y=0-Schema vollständig ersetzt.
• In Beispiel 9 wird die Lücke zwischen 3 und 4 verwendet, um die APK noch einmal zu drehen.

Da jedes Gerät mit einem standardmäßigen, korrekt versionierten APK im System-Image ausgeliefert wird, besteht keine Gefahr, dass eine O-MR1-Version auf einem P-Gerät installiert wird, da sie eine niedrigere Versionsnummer als eine P-System-Image-Version hat. Auf einem Gerät mit einer O-MR1-Version, die in /data installiert ist und dann ein Systemupdate auf P erhält, wird die /system-Version anstelle der O-MR1-Version in /data verwendet, da die P-Version immer höher ist als jede App, die für O-MR1 vorgesehen ist.

Die Daten-App mit tapas erstellen

OEMs sind für die Verwaltung der meisten Aspekte der Zeitzonendaten-App und die korrekte Konfiguration des System-Images verantwortlich. Die Daten-App soll mit einem tapas-Build erstellt werden, der APKs generiert, die dem System-Image (für die Erstveröffentlichung) hinzugefügt und signiert und über einen App-Shop verteilt werden können (für nachfolgende Updates).

Tapas ist eine schlanke Version des Android-Build-Systems, bei der mit einem reduzierten Quellbaum verteilbare Versionen von Apps erstellt werden. OEMs, die mit dem normalen Android-Buildsystem vertraut sind, sollten die Builddateien aus dem normalen Android-Plattform-Build wiedererkennen.

Manifest erstellen

Eine reduzierte Quellstruktur wird in der Regel mit einer benutzerdefinierten Manifestdatei erreicht, die sich nur auf die Git-Projekte bezieht, die vom Build-System und für das Erstellen der App benötigt werden. Nachdem Sie der Anleitung unter Daten-App erstellen gefolgt sind, sollten OEMs mindestens zwei OEM-spezifische Git-Projekte mithilfe der Vorlagendateien unter packages/apps/TimeZoneData/oem_template erstellt haben:

• Ein Git-Projekt enthält App-Dateien wie das Manifest und die Build-Dateien, die zum Erstellen der App-APK-Datei (z. B. vendor/oem/apps/TimeZoneData) erforderlich sind. Dieses Projekt enthält auch Build-Regeln für Test-APKs, die für xTS-Tests verwendet werden können.
• Ein Git-Projekt enthält die signierten APKs, die vom App-Build für die Aufnahme in das System-Image-Build und die xTS-Tests erstellt wurden.

Der App-Build nutzt mehrere andere Git-Projekte, die für den Plattform-Build freigegeben sind oder OEM-unabhängige Codebibliotheken enthalten.

Das folgende Manifest-Snippet enthält die minimale Anzahl von Git-Projekten, die für die Unterstützung eines O-MR1-Builds der Zeitzonendaten-App erforderlich sind. OEMs müssen diesem Manifest ihre OEM-spezifischen Git-Projekte hinzufügen (in der Regel ein Projekt mit dem Signaturzertifikat) und können entsprechend verschiedene Branches konfigurieren.

   <!-- 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" />

Tapas-Build ausführen

Nachdem der Quellbaum eingerichtet ist, führen Sie mit den folgenden Befehlen den Build tapas aus:

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

Bei einem erfolgreichen Build werden Dateien zum Testen im Verzeichnis out/dist generiert. Diese Dateien können in das Verzeichnis „prebuilts“ zur Aufnahme in das System-Image abgelegt und/oder über einen App-Shop für kompatible Geräte verteilt werden.