Zeitzonenregeln

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

Zeitzonenupdates (Android 10 und höher)

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

Bei Updates wird so vorgegangen:

1. Die IANA veröffentlicht eine Aktualisierung der Zeitzonendatenbank, wenn eine oder mehrere Regierungen eine Zeitzonenregel in ihren Ländern ändern.
2. Google oder der Android-Partner bereitet ein Update des Zeitzonendatenmoduls (APEX-Datei) mit den aktualisierten Zeitzonen vor.
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.

Zeitzonen-Updates (Android 8.1–9)

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

In Android 8.1 und Android 9 können OEMs einen APK-basierten Mechanismus verwenden, um aktualisierte Zeitzonenregeln auf Geräte zu übertragen, ohne dass ein Systemupdate erforderlich ist. Dieser Mechanismus ermöglicht es Nutzern, rechtzeitig Updates zu erhalten, wodurch die Nutzungsdauer eines Android-Geräts verlängert wird. Außerdem können Android-Partner Zeitzonenupdates unabhängig von Systemimage-Updates testen.

Das Android-Kernbibliotheken-Team stellt die erforderlichen Datendateien zum Aktualisieren der Zeitzonenregeln auf einem Standard-Android-Gerät bereit. OEMs können diese Datendateien verwenden, wenn sie Zeitzonen-Updates für ihre Geräte erstellen. Sie können aber auch eigene Datendateien erstellen, wenn sie das bevorzugen. In jedem Fall behalten OEMs die Kontrolle über die Qualitätssicherung/Tests, das Timing und die Einführung von Zeitzonenregel-Updates für ihre unterstützten Geräte.

Android-Quellcode und ‑Daten für Zeitzonen

Alle Stock-Android-Geräte, auch solche, die diese Funktion nicht verwenden, benötigen Zeitzonenregeln und müssen mit einem Standardsatz von Zeitzonenregeln in der Partition /system ausgeliefert werden. Diese Daten werden dann von Code aus den folgenden Bibliotheken im Android-Quellbaum verwendet:

• Verwalteter Code aus libcore/ (z. B. java.util.TimeZone) verwendet tzdata- und tzlookup.xml-Dateien.
• Nativer Bibliothekscode in bionic/ (z. B. für mktime, localtime-Systemaufrufe) verwendet die Datei tzdata.
• Der ICU4J/ICU4C-Bibliothekscode in external/icu/ verwendet die Datei „icu .dat“.

In diesen Bibliotheken werden Overlay-Dateien verfolgt, die möglicherweise im Verzeichnis /data/misc/zoneinfo/current vorhanden sind. Overlay-Dateien enthalten voraussichtlich verbesserte Daten zu Zeitzonenregeln, sodass Geräte aktualisiert werden können, ohne dass sich /system ändert.

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

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

Distro-Dateien

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

Das Vertriebsdateiformat ist von der Android-Version abhängig, da sich der Inhalt mit der ICU-Version, den Anforderungen der Android-Plattform und anderen Release-Änderungen ändert. Android stellt für unterstützte Android-Versionen für jedes IANA-Update Distributionsdateien bereit (zusätzlich zur Aktualisierung der Systemdateien der Plattform). Damit die Geräte auf dem neuesten Stand bleiben, können OEMs diese Distro-Dateien verwenden oder eigene Dateien mit dem Android-Quellbaum erstellen, der die Skripts und anderen Dateien enthält, die zum Generieren von Distro-Dateien erforderlich sind.

Komponenten für Zeitzonenupdates

Bei einem Update der Zeitzonenregeln werden Vertriebsdateien an ein Gerät übertragen und die darin enthaltenen Dateien sicher installiert. Für die Übertragung und Installation ist Folgendes erforderlich:

• Funktionen des Plattformdienstes (timezone.RulesManagerService), die standardmäßig deaktiviert sind. OEMs müssen die Funktion über die Konfiguration aktivieren. RulesManagerService wird im Systemserverprozess ausgeführt und führt Zeitzonen-Updatevorgänge durch, indem in /data/misc/zoneinfo/staged geschrieben wird. Mit RulesManagerService können auch bereits bereitgestellte Vorgänge ersetzt oder gelöscht werden.
• TimeZoneUpdater, eine nicht aktualisierbare System-App (auch Updater-App genannt). OEMs müssen diese App in das System-Image von Geräten einfügen, die die Funktion verwenden.
• OEM TimeZoneData: Eine aktualisierbare System-App (auch Data-App genannt), die Vertriebsdateien auf das Gerät überträgt und sie für die Updater-App verfügbar macht. OEMs müssen diese App in das System-Image von Geräten einfügen, die die Funktion verwenden.
• tzdatacheck: Eine Bootzeit-Binärdatei, die für den korrekten und sicheren Betrieb von Zeitzonen-Updates erforderlich ist.

Der Android-Quellcodebaum enthält generischen Quellcode für die oben genannten Komponenten, den der OEM ohne Änderungen verwenden kann. Testcode wird bereitgestellt, damit OEMs automatisch prüfen können, ob sie die Funktion richtig aktiviert haben.

Installation der Distribution

Die Installation der Distribution umfasst die folgenden Schritte:

1. Die Daten-App wird aktualisiert, indem sie über einen App-Shop heruntergeladen oder per Sideloading installiert wird. Der Systemserverprozess (über timezone.RulesManagerServer/timezone.PackageTracker-Klassen) überwacht Änderungen am konfigurierten, OEM-spezifischen Paketnamen der Data-App.
   
   

   Abbildung 1: Updates für Daten-Apps.

2. Der Systemserverprozess löst eine Updateprüfung aus, indem er einen gezielten Intent mit einem eindeutigen Einmal-Token an die Updater-App sendet. Der Systemserver verfolgt das zuletzt generierte Token, damit er feststellen kann, wann die zuletzt ausgelöste Prüfung abgeschlossen ist. Alle anderen Tokens werden ignoriert.
   
   

   Abbildung 2: Update-Prüfung auslösen

3. Während der Updateprüfung führt die Updater-App die folgenden Aufgaben aus:
   • Fragt den aktuellen Gerätestatus ab, indem RulesManagerService aufgerufen wird.
     
     

     Abbildung 3: Daten-App-Updates, die RulesManagerService aufrufen.

   • Fragt die Daten-App ab, indem eine genau definierte ContentProvider-URL und Spaltenspezifikationen abgefragt werden, um Informationen zur Distribution zu erhalten.
     
     

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

4. Die Updater-App führt die entsprechende Aktion aus, basierend auf den Informationen, die sie hat. Folgende Aktionen sind verfügbar:
   • Installation anfordern Distro-Daten werden aus der Daten-App gelesen und an den RulesManagerService auf dem Systemserver übergeben. Der RulesManagerService bestätigt noch einmal, dass die Version und der Inhalt des Vertriebsformats für das Gerät geeignet sind, und bereitet die Installation vor.
   • Deinstallation anfordern (selten). Wenn beispielsweise das aktualisierte APK in /data deaktiviert oder deinstalliert wird und das Gerät zur Version in /system zurückkehrt.
   • Nichts unternehmen: Tritt auf, wenn die Verteilung der Daten-App 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: Prüfung abgeschlossen.

5. Neustart und tzdatacheck: Wenn das Gerät das nächste Mal hochfährt, führt das Binärprogramm „tzdatacheck“ alle bereitgestellten Vorgänge aus. Die Binärdatei „tzdatacheck“ kann die folgenden Aufgaben ausführen:
   • Führen Sie den gestaffelten Vorgang aus, indem Sie das Erstellen, Ersetzen und/oder Löschen der /data/misc/zoneinfo/current-Dateien verarbeiten, 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 Vertriebsformats geändert hat.
   • Die IANA-Regelversion muss mit der Version in /system übereinstimmen oder neuer sein. So wird verhindert, dass ein Gerät nach einem Systemupdate ältere Zeitzonenregeln als die im /system-Image enthält.

Zuverlässigkeit

Der End-to-End-Installationsprozess ist asynchron und wird auf drei Betriebssystemprozesse aufgeteilt. Während der Installation kann es jederzeit zu einem Stromausfall, zu wenig Speicherplatz oder anderen Problemen kommen, die dazu führen, dass die Installationsprüfung unvollständig ist. Im besten Fall informiert die Updater-App den Systemserver darüber, dass das Update fehlgeschlagen ist. Im schlimmsten Fall erhält der RulesManagerService überhaupt keinen Aufruf.

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

Sicherheit

Wenn der Dienst 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, dass ein Gerät startet. Beispiele hierfür sind eine fehlerhafte Updater- oder Data-App-Konfiguration oder wenn sich die Updater- oder Data-App nicht in /system/priv-app befindet.
• Probleme, die darauf hindeuten, dass eine fehlerhafte Data-App installiert wurde, verhindern nicht, dass ein Gerät hochfährt, aber sie verhindern, dass eine Updateprüfung ausgelöst wird. Beispiele hierfür sind das Fehlen erforderlicher Systemberechtigungen oder wenn die Data-App keinen ContentProvider für die erwartete URI bereitstellt.

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

Zeitzonenaktualisierungen einbinden

So aktivieren OEMs die Funktion zur Aktualisierung der Zeitzone:

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

Vorbereitung

Bevor Sie beginnen, sollten OEMs die folgenden Richtlinien, Qualitätssicherungs- und Sicherheitsaspekte lesen:

• Erstellen Sie einen dedizierten anwendungsspezifischen Signaturschlüssel für Ihre Daten-App.
• Erstellen Sie eine Release- und Versionsstrategie für Zeitzonen-Updates, um zu verstehen, welche Geräte aktualisiert werden und wie Sie dafür sorgen können, dass Updates nur auf Geräten installiert werden, die sie benötigen. Beispielsweise möchten OEMs möglicherweise eine einzelne Daten-App für alle ihre Geräte oder verschiedene Daten-Apps für verschiedene Geräte. Die Entscheidung wirkt sich auf die Auswahl des Paketnamens, möglicherweise auf die verwendeten Versionscodes und auf die QA-Strategie aus.
• Klären Sie, ob sie die Standard-Zeitzonendaten von Android aus AOSP verwenden oder eigene erstellen möchten.

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. Anleitungen und Beispielvorlagen für AndroidManifest.xml und andere Dateien finden Sie unter packages/apps/TimeZoneData/oem_template. Beispielvorlagen enthalten sowohl ein Build-Ziel für das echte APK der 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 unter Einstellungen > Apps angezeigt.

Die Daten-App soll mit einem Tapas-Build erstellt werden, der APKs erzeugt, die dem System-Image hinzugefügt werden können (für die erste Version) und über einen App-Store signiert und 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 Data App vorab im System-Image eines Geräts in /system/priv-app installieren. Wenn OEMs vorgefertigte APKs (die durch den Tapas-Build-Prozess generiert werden) in das System-Image einfügen möchten, können sie die Beispieldateien in packages/apps/TimeZoneData/oem_template/data_app_prebuilt kopieren. Die Beispielvorlagen enthalten auch Build-Ziele zum Einbeziehen von Testversionen der Daten-App in Test-Suites.

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

OEMs müssen die Updater- und Data-App-APKs im Verzeichnis /system/priv-app des System-Images platzieren. Dazu muss der System-Image-Build explizit die vorgefertigten Ziele für die Updater-App und die Data-App enthalten.

Die Updater-App muss mit dem Plattformschlüssel signiert und wie jede andere System-App eingebunden werden. 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 den Prebuild ausgewählt wurde.

Systemserver konfigurieren

Um Zeitzonen-Updates zu aktivieren, können OEMs den Systemserver konfigurieren, indem sie Konfigurationseigenschaften überschreiben, die in frameworks/base/core/res/res/values/config.xml definiert sind.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Konfigurationsüberschreibungen sollten sich im Systemimage befinden (nicht im Anbieter- oder einem anderen Image), da ein falsch konfiguriertes Gerät möglicherweise nicht gestartet werden kann. Wenn die Konfigurationsüberschreibungen im Anbieter-Image enthalten waren, würde ein Update auf ein System-Image ohne Daten-App (oder mit anderen Paketnamen für die Daten-App/Updater-App) als Fehlkonfiguration betrachtet.

xTS-Tests

xTS bezieht sich auf alle OEM-spezifischen Test-Suites, die den Standard-Android-Test-Suites mit Tradefed (z. B. CTS und VTS) ähneln. OEMs, die solche Testsuiten haben, können die Android-Zeitzonen-Update-Tests hinzufügen, die an den folgenden Orten bereitgestellt werden:

• 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 eine Beispielverzeichnisstruktur zum Einbinden von Tests in eine Tradefed-ähnliche xTS-Suite. Wie bei anderen Vorlagenverzeichnissen wird von OEMs erwartet, dass sie die Vorlagen kopieren und an ihre Bedürfnisse anpassen.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt enthält die Build-Konfiguration zum Einbinden der vorgefertigten Test-APKs, die für den Test erforderlich sind.

Zeitzonenaktualisierungen erstellen

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

Da Daten-Apps Verteilungsdateien enthalten, die eng mit Android-Versionen verknüpft sind, müssen OEMs für jedes unterstützte Android-Release, das 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 Prozess dreimal durchlaufen.

Schritt 1: System-/Zeitzonen- und externe/ICU-Datendateien aktualisieren

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

Der AOSP-Patch für die System-/Zeitzone enthält aktualisierte Dateien in system/timezone/input_data und system/timezone/output_data. OEMs, die zusätzliche lokale Korrekturen 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 eingebunden, wenn das APK der Data-App erstellt wird.

Schritt 2: Versionscode der Daten-App aktualisieren

In diesem Schritt aktualisieren OEMs den Versionscode der Daten-App. Beim Build wird distro.zip automatisch übernommen. Die neue Version der Daten-App muss jedoch einen neuen Versionscode haben, damit sie als neu erkannt und verwendet wird, um eine vorab geladene 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 auf das APK angewendeten Versionscode bzw. Versionsnamen 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 Testversionscodes müssen jedoch höher als die Systemimage-Version sein. Weitere Informationen finden Sie im Beispiel für das Versionscodeschema. Wenn das Beispielschema oder ein ähnliches Schema verwendet wird, müssen die Testversionscodes nicht aktualisiert werden, da sie garantiert höher als die echten Versionscodes sind.

Schritt 3: App 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:

• Bei noch nicht veröffentlichten Geräten (oder wenn Sie ein Systemupdate für ein veröffentlichtes Gerät vorbereiten) müssen Sie die neuen APKs im Prebuilt-Verzeichnis der Data-App einreichen, 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 veröffentlichte Geräte, die keine Systemupdates mehr erhalten, kann die signierte APK möglicherweise nur über einen App-Store veröffentlicht werden.

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

Strategie für den Code der Daten-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-Store heruntergeladene enthält, sollte die App-Store-Version beibehalten werden.

Der APK-Versionscode sollte die folgenden Informationen enthalten:

• Distro-Formatversion (Haupt- + Nebenversion)
• Eine inkrementierende (intransparente) 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, wodurch die Distributionsdateien inkompatibel werden. In Zukunft kann sich das ändern, sodass eine Vertriebsdatei für mehrere Android-Plattformversionen verwendet werden kann und die API-Ebene nicht im Versionscodeschema der Daten-App verwendet wird.

Beispiel für eine Versionscodestrategie

Dieses Versionsnummerierungsschema sorgt dafür, dass höhere Versionen des Vertriebsformats niedrigere Versionen des Vertriebsformats ersetzen. AndroidManifest.xml verwendet android:minSdkVersion, um dafür zu sorgen, dass auf alten Geräten keine Versionen mit einem höheren Verteilungsformat als dem, das sie unterstützen, installiert werden.

Abbildung 6 Beispiel für eine Versionscode-Strategie.

Das Schema könnte besser gepackt werden, wenn Binärzahlen anstelle von Dezimalzahlen verwendet würden. Es hat jedoch den Vorteil, dass es für Menschen lesbar ist. Wenn der gesamte Nummernkreis ausgeschöpft ist, kann sich der Paketname der Data-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 sind in der folgenden Tabelle aufgeführt.

• In den Beispielen 1 und 2 werden zwei APK-Versionen für dieselbe IANA-Version von 2017a mit unterschiedlichen Hauptformatversionen gezeigt. 2 ist numerisch höher als 1. Das ist erforderlich, damit neuere Geräte die höheren Formatversionen erhalten. Mit minSdkVersion wird dafür gesorgt, dass die P-Version nicht auf O-Geräten bereitgestellt wird.
• Beispiel 3 ist eine Überarbeitung/Korrektur für Beispiel 1 und numerisch höher als Beispiel 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 frühere IANA-Releases/Android-Revisionen 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 das Schema „Y=0“ vollständig durch „Y“ ersetzt wird.
• In Beispiel 9 wird gezeigt, wie die Lücke zwischen 3 und 4 genutzt wird, um das APK neu zu erstellen.

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

Daten-App mit Tapas erstellen

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

Tapas ist eine abgespeckte Version des Android-Buildsystems, die einen reduzierten Quellbaum verwendet, um verteilbare Versionen von Apps zu erstellen. OEMs, die mit dem normalen Android-Buildsystem vertraut sind, sollten die Build-Dateien aus dem normalen Android-Plattform-Build erkennen.

Manifest erstellen

Ein reduzierter Quellbaum wird in der Regel mit einer benutzerdefinierten Manifestdatei erreicht, die sich nur auf die Git-Projekte bezieht, die vom Build-System und zum Erstellen der App benötigt werden. Nach der Anleitung unter Creating a Data app (Erstellen einer Daten-App) sollten OEMs mindestens zwei OEM-spezifische Git-Projekte erstellt haben, indem sie die Vorlagendateien unter packages/apps/TimeZoneData/oem_template verwendet haben:

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

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

Das folgende Manifest-Snippet enthält die Mindestanzahl an Git-Projekten, die für einen O-MR1-Build der Zeitzonen-Daten-App erforderlich sind. OEMs müssen diesem Manifest ihre OEM-spezifischen Git-Projekte hinzufügen (die in der Regel ein Projekt mit dem Signaturzertifikat enthalten) und können entsprechend verschiedene Zweige 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 wurde, rufen Sie den tapas-Build mit den folgenden Befehlen auf:

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 im Verzeichnis out/dist für Tests generiert. Diese Dateien können in das Verzeichnis „prebuilts“ eingefügt werden, um in das System-Image aufgenommen und/oder über einen App-Shop für kompatible Geräte verteilt zu werden.