Diese Seite wurde von der Cloud Translation API übersetzt.

Zeitzonenregeln

In Android 10 wird der APK-basierte Mechanismus zur Zeitzonendatenaktualisierung (verfügbar unter Android 8.1 und Android 9) eingestellt und durch einen APEX-basierten Mechanismus zur Modulaktualisierung 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 per APK 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.

Aktualisierungen der Zeitzone (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:

Die IANA veröffentlicht ein Update der Zeitzonendatenbank, wenn eine oder mehrere Regierungen eine Zeitzonenregel in ihren Ländern ändern.
Google oder der Android-Partner erstellen ein Update für das Time Zone Data Module (APEX-Datei) mit den aktualisierten Zeitzonen.
Das Endnutzergerät lädt das Update herunter, wird neu gestartet und wendet die Änderungen an. Anschließend enthalten die Zeitzonendaten des Geräts die neuen Zeitzonendaten aus dem Update.

Weitere Informationen zu den 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 Core Library-Team stellt die erforderlichen Datendateien zum Aktualisieren von Zeitzonenregeln auf einem standardmäßigen Android-Gerät bereit. OEMs können diese Datendateien verwenden, wenn sie Zeitzonen-Updates für ihre Geräte erstellen, oder ihre eigenen Datendateien erstellen. In allen Fällen behalten OEMs die Kontrolle über die Qualitätssicherung/die Tests, den Zeitplan 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 mit einem Standardsatz von Zeitzonenregeln geliefert werden. Diese Daten werden dann von Code aus den folgenden Bibliotheken im Android-Quellcodebaum verwendet:

Bei verwaltetem Code von libcore/ (z. B. java.util.TimeZone) werden die Dateien tzdata und tzlookup.xml verwendet.
Beim nativen Bibliothekscode in bionic/ (z. B. für mktime bei Systemaufrufen der 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 Daten zu Zeitzonenregeln benötigen, prüfen zuerst die folgenden Standorte:

Der Code libcore/ und bionic/ verwenden die Kopie /data der Dateien tzdata und tzlookup.xml.
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-Quellbaum erstellen, der die Scripts und anderen Dateien enthält, die zum Generieren von Distributionsdateien erforderlich sind.

Komponenten für die Aktualisierung der Zeitzone

Eine Aktualisierung der Zeitzonenregeln umfasst die Übertragung von Distributionsdateien an 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 die Zeitzonenaktualisierung durch Schreiben in /data/misc/zoneinfo/staged durch. Mit RulesManagerService können auch bereits bereitgestellte Vorgänge ersetzt oder gelöscht werden.
TimeZoneUpdater, eine nicht aktualisierbare System-App (auch als Updater-App bezeichnet). OEMs müssen diese App in das System-Image der Geräte aufnehmen, auf denen sie 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:

Die Datenanwendung wird über einen App-Shop-Download oder Sideload aktualisiert. Der Systemserverprozess (über die Klassen timezone.RulesManagerServer/timezone.PackageTracker) überwacht auf Änderungen am konfigurierten, OEM-spezifischen Daten-App-Paketnamen.

Abbildung 1: Updates der Daten-App.
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
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, RulesManagerService wird aufgerufen.
- Fragt die Data-Anwendung ab, indem eine klar definierte ContentProvider-URL und Spaltenspezifikationen abgefragt werden, um Informationen zur Distribution abzurufen.
  
  Abbildung 4 Daten-App-Updates, Informationen zur Distribution abrufen
Die Updater-App ergreift auf der Grundlage der Informationen geeignete Maßnahmen. 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 ist.

Abbildung 5. Überprüfung abgeschlossen.
Neu starten und tzdatacheck durchfü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 bereitgestellten Vorgang durch Erstellen, Ersetzen und/oder Löschen der /data/misc/zoneinfo/current-Dateien aus, bevor andere Systemkomponenten geöffnet und mit der Verwendung der Dateien begonnen haben.
- Prüfe, 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 werden, der zum Signieren 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 zur Aktualisierung der Zeitzone zu aktivieren, tun OEMs in der Regel Folgendes:

eine 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

Bevor sie beginnen, sollten OEMs die folgenden Richtlinien, Qualitätssicherung und Sicherheitsaspekte lesen:

Erstellen Sie einen speziellen app-spezifischen Signaturschlüssel für die Daten-App.
Erstellen Sie eine Veröffentlichungs- und Versionsverwaltungsstrategie für Zeitzonenupdates, 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 einzige Daten-App für alle ihre Geräte oder verschiedene Daten-Apps für verschiedene 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. Die Beispielvorlagen enthalten sowohl ein Build-Ziel für das echte Daten-App-APK 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 sollte mit einem tapas-Build erstellt werden, der APKs erstellt, die zum System-Image (für den ersten Release) hinzugefügt und für nachfolgende Updates über einen App-Shop signiert und vertrieben werden können. 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 Updater- und Daten-App-APKs im Verzeichnis /system/priv-app des System-Images platzieren. 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.

Attribut	Beschreibung	Überschreiben erforderlich?
config_enableUpdateableTimeZoneRules	Muss auf `true` festgelegt sein, um den RulesManagerService zu aktivieren.	Ja
config_timeZoneRulesUpdateTrackingEnabled	Muss auf `true` gesetzt sein, damit das System auf Änderungen an der Daten-App achtet.	Ja
config_timeZoneRulesDataPackage	Paketname der OEM-spezifischen Daten-App.	Ja
config_timeZoneRulesUpdaterPackage	Konfiguriert für die Standard-Updater-App. Ändern Sie diese Einstellung nur, wenn Sie eine andere Updater-App-Implementierung bereitstellen.	Nein
config_timeZoneRulesCheckTimeMillisAllowed	Zulässige Zeitspanne zwischen einer Aktualisierungsüberprüfung, die vom RulesManagerService ausgelöst wird, und einer Antwort, bei der eine Installation, Deinstallation oder keine Aktion ausgeführt wird. Danach kann ein spontaner Zuverlässigkeitstrigger generiert werden.	Nein
config_timeZoneRulesCheckRetryCount	Die zulässige Anzahl aufeinanderfolgender fehlgeschlagener Aktualisierungsüberprüfungen, bevor der RulesManagerService keine weiteren mehr generiert.	Nein

Konfigurationsüberschreibungen sollten im System-Image (nicht vom Anbieter oder von einem anderen Anbieter) enthalten sein, da ein falsch konfiguriertes Gerät den Start verweigern kann. 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 Einschließen 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.

Hinweis:In den folgenden Schritten wird nicht beschrieben, wie die Basisdatendateien im /system-Image aktualisiert werden. Dies ist für die Vorbereitung des Factory-Images oder von Systemupdates erforderlich. Dabei wird auch die Distributionsdatei für die Aufnahme in die Data App generiert. Eine Anleitung zum Aktualisieren der Plattformdateien findest du unter /system/timezone/README.android.

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 du die Daten-App mit Dateien erstellst, die aus package/apps/TimeZoneData/oem_template/data_app kopiert wurden, findest du den Versionscode bzw. Versionsnamen, der auf das APK angewendet wird, 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.
Bei freigegebenen Geräten, die keine Systemupdates mehr erhalten, kann das signierte APK 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 normalerweise 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 sicherzustellen, dass alte Geräte keine Versionen mit einer höheren Distributionsformatversion empfangen, als sie verarbeiten können.

Abbildung 6 Beispiel für eine Versionscodestrategie

Verwendungsbeispiele	Wert	Zweck
Ja	Reserviert	Ermöglicht zukünftige alternative Schemas/Test-APKs. Anfangs (implizit) 0. Da der zugrunde liegende Typ ein signierter 32-Bit-Int-Typ ist, unterstützt dieses Schema bis zu zwei zukünftige Versionen des Nummerierungsschemas.
01	Hauptformatversion	Erfasst die Version im Hauptformat mit 3 Dezimalstellen. Das Distributionsformat unterstützt drei Dezimalstellen, hier werden jedoch nur zwei verwendet. Aufgrund des erwarteten großen Anstiegs pro API-Level ist es unwahrscheinlich, dass 100 % erreicht werden. Hauptversion 1 entspricht API-Level 27.
1	Nebenversion des Formats	Die Version des Minor-Formats mit drei Dezimalstellen wird erfasst. Das Distributionsformat unterstützt drei Dezimalstellen, hier wird jedoch nur eine verwendet. Es ist unwahrscheinlich, dass 10 erreicht wird.
X	Reserviert	Für Produktionsreleases ist der Wert „0“. Für Test-APKs kann er abweichen.
ZZZZZ	Intransparente Versionsnummer	Auf Anfrage zugewiesene Dezimalzahl. Enthält Lücken, damit bei Bedarf Interstitial-Anzeigen aktualisiert werden können.

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 ausgeschöpft ist, kann sich der Name des Datenanwendungspakets ä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.

#	Versionscode	minSdkVersion	{Major format version},{Minor format version},{IANA rules version},{Revision}
1	11000010	O-MR1	major=001,minor=001,iana=2017a,revision=1
2	21000010	P	major=002,minor=001,iana=2017a,revision=1
3	11000020	O-MR1	major=001,minor=001,iana=2017a,revision=2
4	11000030	O-MR1	major=001,minor=001,iana=2017b,revision=1
5	21000020	P	Major=002,minor=001,iana=2017b,revision=1
6	11000040	O-MR1	major=001,minor=001,iana=2018a,revision=1
7	21000030	P	major=002,minor=001,iana=2018a,revision=1
8	1123456789	-	-
9	11000021	O-MR1	major=001,minor=001,iana=2017a,revision=2,respin=2

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.
Die Beispiele 4 und 5 zeigen die Releases von O-MR1 und P von 2017b. 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 gezeigt, wie die Lücke zwischen 3 und 4 genutzt wird, um die APK-Datei neu 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, auf dem in /data die O-MR1-Version installiert ist und das 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 vereinfachte Version des Android-Build-Systems, die eine reduzierte Quellstruktur verwendet, um verteilbare Versionen von Apps zu erstellen. OEMs, die mit dem normalen Android-Build-System vertraut sind, sollten die Build-Dateien vom normalen Android-Plattform-Build erkennen.

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 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 Aufnahme in den System-Image-Build und die xTS-Tests erstellt wurden.

Der App-Build nutzt mehrere andere Git-Projekte, die mit dem Plattform-Build geteilt werden 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.