Zeitzonenregeln

Android 10 veraltet den APK-basierten Aktualisierungsmechanismus für Zeitzonendaten (verfügbar in Android 8.1 und Android 9) und ersetzt ihn durch einen APEX-basierten Modulaktualisierungsmechanismus . AOSP 8.1 bis 13 enthalten immer noch den Plattformcode, den OEMs benötigen, um APK-basierte Updates zu ermöglichen, sodass Geräte, die auf Android 10 aktualisieren, weiterhin von Partnern bereitgestellte Zeitzonendaten-Updates über APK erhalten können. Der APK-Aktualisierungsmechanismus sollte jedoch nicht auf einem Produktionsgerät verwendet werden, das auch Modulaktualisierungen erhält, da ein APK-basiertes Update ein APEX-basiertes Update ersetzt (d. h. ein Gerät, das ein APK-Update erhalten hat, würde APEX-basierte Updates ignorieren). ).

Zeitzonenaktualisierungen (Android 10+)

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

Updates verwenden den folgenden Prozess:

  1. IANA veröffentlicht ein Update der Zeitzonendatenbank als Reaktion darauf, dass eine oder mehrere Regierungen eine Zeitzonenregel in ihren Ländern ändern.
  2. Google oder der Android-Partner bereiten ein Update des Zeitzonendatenmoduls (APEX-Datei) vor, das die aktualisierten Zeitzonen enthält.
  3. Das Endbenutzergerät lädt das Update herunter, startet neu und übernimmt dann die Änderungen. Anschließend enthalten die Zeitzonendaten des Geräts die neuen Zeitzonendaten aus dem Update.

Einzelheiten zu Modulen finden Sie unter Modulare Systemkomponenten .

Zeitzonenaktualisierungen (Android 8.1–9)

Hinweis: Die APK-basierte Funktion zur Aktualisierung von Zeitzonendaten wurde ab Android 14 vollständig entfernt und ist nicht im Quellcode zu finden. Partner sollten vollständig auf das Time Zone Mainline-Modul migrieren.

In Android 8.1 und Android 9 können OEMs einen APK-basierten Mechanismus verwenden, um aktualisierte Zeitzonenregeldaten an Geräte zu übertragen, ohne dass ein Systemupdate erforderlich ist. Dieser Mechanismus ermöglicht es Benutzern, zeitnahe Updates zu erhalten (wodurch die Nutzungsdauer eines Android-Geräts verlängert wird) und ermöglicht es Android-Partnern, Zeitzonen-Updates unabhängig von System-Image-Updates zu testen.

Das Team der Android-Kernbibliotheken stellt die erforderlichen Datendateien zum Aktualisieren der Zeitzonenregeln auf einem Standard-Android-Gerät bereit. OEMs können diese Datendateien beim Erstellen von Zeitzonenaktualisierungen für ihre Geräte verwenden oder bei Bedarf ihre eigenen Datendateien erstellen. In allen Fällen behalten OEMs die Kontrolle über die Qualitätssicherung/-prüfung, den Zeitpunkt und den Start von Aktualisierungen der Zeitzonenregeln für ihre unterstützten Geräte.

Quellcode und Daten der Android-Zeitzone

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

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

Diese Bibliotheken verfolgen die Overlay-Dateien, die möglicherweise im Verzeichnis /data/misc/zoneinfo/current vorhanden sind. Es wird erwartet, dass Overlay-Dateien verbesserte Daten zu Zeitzonenregeln enthalten, sodass Geräte aktualisiert werden können, ohne /system zu ändern.

Android-Systemkomponenten, die Zeitzonenregeldaten benötigen, überprüfen zunächst die folgenden Standorte:

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

Distributionsdateien

Distributions .zip Dateien enthalten die Datendateien, die zum Auffüllen des Verzeichnisses /data/misc/zoneinfo/current erforderlich sind. Die Distributionsdateien enthalten auch Metadaten, die es Geräten ermöglichen, Versionsprobleme zu erkennen.

Das Distributionsdateiformat ist abhängig von der Android-Version, da sich der Inhalt mit der ICU-Version, den Android-Plattformanforderungen und anderen Versionsänderungen ändert. Android stellt für jedes IANA-Update Distributionsdateien für unterstützte Android-Versionen bereit (zusätzlich zur Aktualisierung der Plattformsystemdateien). Um ihre Geräte auf dem neuesten Stand zu halten, können OEMs diese Distributionsdateien verwenden oder ihre eigenen mithilfe des Android-Quellbaums erstellen (der die Skripts und andere Dateien enthält, die zum Generieren von Distributionsdateien erforderlich sind).

Komponenten zur 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:

  • Plattformdienstfunktionalität ( timezone.RulesManagerService ), die standardmäßig deaktiviert ist. OEMs müssen die Funktionalität durch Konfiguration aktivieren. RulesManagerService wird im Systemserverprozess ausgeführt und führt Zeitzonenaktualisierungsvorgänge durch Schreiben in /data/misc/zoneinfo/staged durch. RulesManagerService kann auch bereits bereitgestellte Vorgänge ersetzen oder löschen.
  • TimeZoneUpdater , eine nicht aktualisierbare System-App (auch bekannt als Updater-App ). OEMs müssen diese App in das Systemabbild von Geräten integrieren, die diese Funktion nutzen.
  • OEM TimeZoneData , eine aktualisierbare System-App (auch bekannt als Daten-App ), die Distributionsdateien auf das Gerät überträgt und sie der Updater-App zur Verfügung stellt. OEMs müssen diese App in das Systemabbild von Geräten integrieren, die diese Funktion nutzen.
  • tzdatacheck , eine Bootzeit-Binärdatei, die 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 ohne Änderung verwenden kann. Es wird Testcode bereitgestellt, damit OEMs automatisch überprüfen können, ob sie die Funktion korrekt aktiviert haben.

Distributionsinstallation

Der Installationsprozess der Distribution umfasst die folgenden Schritte:

  1. Die Daten-App wird durch einen App-Store-Download oder Sideload aktualisiert . Der Systemserverprozess (über die Klassen timezone.RulesManagerServer/timezone.PackageTracker ) sucht nach Änderungen am konfigurierten, OEM-spezifischen Daten-App-Paketnamen.

    Aktualisierungen der Daten-App
    Abbildung 1. Daten-App-Updates
  2. Der Systemserverprozess löst eine Update-Prüfung aus , indem er eine gezielte Absicht mit einem eindeutigen, einmal verwendbaren Token an die Updater-App sendet. Der Systemserver verfolgt das zuletzt von ihm generierte Token, sodass er feststellen kann, wann die letzte von ihm ausgelöste Prüfung abgeschlossen wurde. Alle anderen Token werden ignoriert.

    Update auslösen
    Abbildung 2. Update-Prüfung auslösen
  3. Während der Update-Prüfung führt die Updater-App folgende Aufgaben aus:
    • Fragt den aktuellen Gerätestatus durch Aufrufen des RulesManagerService ab.

      Rufen Sie RulesManagerService auf
      Abbildung 3. Daten-App-Updates, Aufruf von RulesManagerService
    • Fragt die Daten-App ab, indem eine genau definierte ContentProvider-URL und Spaltenspezifikationen abgefragt werden, um Informationen über die Distribution zu erhalten.

      Holen Sie sich Informationen zur Distribution
      Abbildung 4. Daten-App-Updates, Informationen zur Distribution erhalten
  4. Die Updater-App ergreift basierend auf den ihr vorliegenden Informationen die entsprechende Aktion . Zu den verfügbaren Aktionen gehören:
    • Fordern Sie eine Installation an. Distributionsdaten werden aus der Daten-App gelesen und an den RulesManagerService auf dem Systemserver übergeben. Der RulesManagerService bestätigt erneut, dass die Version und der Inhalt des Distributionsformats für das Gerät geeignet sind, und führt die Installation durch.
    • Fordern Sie eine Deinstallation an (dies kommt selten vor). Zum Beispiel, wenn das aktualisierte APK in /data deaktiviert oder deinstalliert wird und das Gerät auf die in /system vorhandene Version zurückkehrt.
    • Nichts tun. Tritt auf, wenn festgestellt wird, dass die Daten-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.

    Überprüfen Sie vollständig
    Abbildung 5. Überprüfung abgeschlossen
  5. Neustart und tzdatacheck. Wenn das Gerät das nächste Mal startet, führt die tzdatacheck-Binärdatei alle gestaffelten Vorgänge aus. Die tzdatacheck-Binärdatei kann die folgenden Aufgaben ausführen:
    • Führen Sie den gestaffelten Vorgang aus, indem Sie die Erstellung, Ersetzung und/oder Löschung der /data/misc/zoneinfo/current Dateien durchführen, bevor andere Systemkomponenten geöffnet und mit der Verwendung der Dateien begonnen haben.
    • Überprüfen Sie, ob die Dateien in /data für die aktuelle Plattformversion korrekt sind. Dies ist möglicherweise nicht der Fall, wenn das Gerät gerade ein Systemupdate erhalten hat und sich die Version des Distributionsformats geändert hat.
    • Stellen Sie sicher, dass die Version der IANA-Regeln mit der Version in /system übereinstimmt oder neuer ist. Dies schützt davor, dass ein Systemupdate ein Gerät mit älteren Zeitzonenregeldaten hinterlässt, als im /system -Image vorhanden sind.

Zuverlässigkeit

Der End-to-End-Installationsprozess ist asynchron und auf drei Betriebssystemprozesse aufgeteilt. Zu jedem Zeitpunkt der Installation kann es vorkommen, dass das Gerät nicht mehr mit Strom versorgt wird, der Speicherplatz knapp wird oder andere Probleme auftreten, was dazu führt, dass die Installationsprüfung unvollständig ist. Im besten Fall ohne Erfolg teilt die Updater-App dem Systemserver mit, dass der Vorgang nicht erfolgreich war; Im schlimmsten Fall ohne Erfolg erhält der RulesManagerService überhaupt keinen Anruf.

Um dies zu bewältigen, verfolgt der Systemservercode, ob eine ausgelöste Update-Prüfung abgeschlossen wurde und wie der zuletzt überprüfte Versionscode der Daten-App lautet. Wenn das Gerät im Leerlauf ist und aufgeladen wird, kann der Systemservercode den aktuellen Status überprüfen. Wenn eine unvollständige Update-Prüfung oder eine unerwartete Daten-App-Version festgestellt wird, löst es spontan eine Update-Prüfung aus.

Sicherheit

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

  • Probleme, die auf ein schlecht konfiguriertes Systemabbild hinweisen, verhindern das Booten eines Geräts; Beispiele hierfür sind eine fehlerhafte Updater- oder Daten-App-Konfiguration oder der Updater oder die Daten-App, die sich nicht in /system/priv-app befindet.
  • Probleme, die darauf hinweisen, dass eine fehlerhafte Daten-App installiert wurde, verhindern nicht das Starten eines Geräts, verhindern aber, dass eine Update-Prüfung ausgelöst wird. Beispiele hierfür sind das Fehlen erforderlicher Systemberechtigungen oder die Daten-App, die keinen ContentProvider für den erwarteten URI verfügbar macht.

Dateiberechtigungen für die Verzeichnisse /data/misc/zoneinfo werden mithilfe von 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. Von der Daten-App wird erwartet, dass sie über einen dedizierten, OEM-spezifischen Paketnamen und Schlüssel verfügt.

Zeitzonenaktualisierungen integrieren

Um die Zeitzonenaktualisierungsfunktion zu aktivieren, gehen OEMs normalerweise wie folgt vor:

  • Erstellen Sie ihre eigene Daten-App.
  • Beziehen Sie die Updater- und Daten-Apps in den System-Image-Build ein.
  • Konfigurieren Sie den Systemserver, um den RulesManagerService zu aktivieren.

Vorbereiten

Bevor sie beginnen, sollten OEMs die folgenden Richtlinien, Qualitätssicherungs- und Sicherheitsaspekte prüfen:

  • Erstellen Sie einen dedizierten App-spezifischen Signaturschlüssel für ihre Daten-App.
  • Erstellen Sie eine Veröffentlichungs- und Versionierungsstrategie für Zeitzonenaktualisierungen, um zu verstehen, welche Geräte aktualisiert werden und wie sichergestellt werden kann, dass Aktualisierungen 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 haben oder entscheiden sich möglicherweise für unterschiedliche Daten-Apps für verschiedene Geräte. Die Entscheidung wirkt sich auf die Wahl des Paketnamens, möglicherweise der verwendeten Versionscodes und die QA-Strategie aus.
  • Finden Sie heraus, ob sie Standard-Android-Zeitzonendaten von AOSP verwenden oder ihre eigenen erstellen möchten.

Erstellen einer Daten-App

AOSP enthält den gesamten Quellcode und die Build-Regeln, die zum Erstellen einer Daten-App in packages/apps/TimeZoneData erforderlich sind, sowie Anweisungen und Beispielvorlagen für AndroidManifest.xml und andere Dateien in packages/apps/TimeZoneData/oem_template . Beispielvorlagen umfassen 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 ihrem eigenen Symbol, Namen, Übersetzungen und anderen Details anpassen. Da die Daten-App jedoch nicht gestartet werden kann, wird das Symbol nur im Bildschirm „Einstellungen“ > „Apps“ angezeigt.

Die Daten-App soll mit einem Tapas- Build erstellt werden, der APKs erstellt, die zum Hinzufügen zum System-Image (für die Erstveröffentlichung) und zum Signieren und Verteilen über einen App Store (für spätere Updates) geeignet sind. Einzelheiten zur Verwendung von Tapas finden Sie unter Erstellen der Daten-App mithilfe von Tapas .

OEMs müssen die vorgefertigte Daten-App im Systemabbild eines Geräts in /system/priv-app installieren. Um vorgefertigte APKs (die durch den Tapas-Build-Prozess generiert wurden) in das System-Image einzuschließen, können OEMs die Beispieldateien in packages/apps/TimeZoneData/oem_template/data_app_prebuilt kopieren. Die Beispielvorlagen enthalten auch Build-Ziele zum Einbinden von Testversionen der Daten-App in Testsuiten.

Einbinden der Updater- und Daten-Apps in das Systemabbild

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

Die Updater-App sollte mit dem Plattformschlüssel signiert und wie jede andere System-App eingebunden werden. Das Ziel ist in packages/apps/TimeZoneUpdater als TimeZoneUpdater definiert. Die Einbindung der Daten-App ist OEM-spezifisch und hängt vom Zielnamen ab, der für den Prebuild ausgewählt wurde.

Konfigurieren des Systemservers

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

Eigentum Beschreibung Überschreibung erforderlich?
config_enableUpdateableTimeZoneRules
Muss auf true gesetzt sein, um den RulesManagerService zu aktivieren. Ja
config_timeZoneRulesUpdateTrackingEnabled
Muss auf true gesetzt werden, damit das System auf Änderungen an der Daten-App wartet. Ja
config_timeZoneRulesDataPackage
Paketname der OEM-spezifischen Daten-App. Ja
config_timeZoneRulesUpdaterPackage
Konfiguriert für die Standard-Updater-App. Ändern Sie dies nur, wenn Sie eine andere Updater-App-Implementierung bereitstellen. NEIN
config_timeZoneRulesCheckTimeMillisAllowed
Zulässige Zeit zwischen der Auslösung einer Update-Überprüfung durch den RulesManagerService und einer Installations-, Deinstallations- oder Nichtstun-Antwort. Ab diesem Zeitpunkt kann ein spontaner Zuverlässigkeitstrigger generiert werden. NEIN
config_timeZoneRulesCheckRetryCount
Die Anzahl aufeinanderfolgender erfolgloser Aktualisierungsprüfungen, die zulässig sind, bevor der RulesManagerService keine weiteren mehr generiert. NEIN

Konfigurationsüberschreibungen sollten im Systemabbild (nicht vom Hersteller oder einem anderen) erfolgen, da ein falsch konfiguriertes Gerät den Start verweigern kann. Wenn sich die Konfigurationsüberschreibungen im Anbieter-Image befänden, würde die Aktualisierung auf ein System-Image ohne eine Daten-App (oder mit anderen Daten-App-/Updater-App-Paketnamen) als Fehlkonfiguration betrachtet.

xTS-Test

xTS bezieht sich auf jede OEM-spezifische Testsuite, die den Standard-Android-Testsuiten mit Tradefed ähnelt (z. B. CTS und VTS). OEMs, die über solche Testsuiten verfügen, können die an den folgenden Orten bereitgestellten Android-Zeitzonenaktualisierungstests 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 eine Beispielverzeichnisstruktur zum Einbinden von Tests in eine Tradefed-ähnliche xTS-Suite. Wie bei anderen Vorlagenverzeichnissen wird von OEMs erwartet, dass sie diese kopieren und an ihre Bedürfnisse anpassen.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt enthält eine Build-Time-Konfiguration zum Einbinden der vorgefertigten Test-APKs, die für den Test erforderlich sind.

Zeitzonenaktualisierungen erstellen

Wenn IANA einen neuen Satz Zeitzonenregeln veröffentlicht, generiert das Android-Kernbibliotheksteam Patches, um Versionen 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 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 Android 8.1-, 9- und 10-Geräte bereitstellen möchte, muss er den Vorgang dreimal durchführen.

Schritt 1: System-/Zeitzone- und externe/icu-Datendateien aktualisieren

In diesem Schritt nehmen OEMs eine Bestandsaufnahme der Android-Commits für system/timezone und external/icu aus den release -dev-Zweigen in AOSP vor und wenden diese Commits auf ihre Kopie des Android-Quellcodes an.

Der system/timezone AOSP-Patch 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 , die beim Erstellen des Daten-App-APK automatisch eingebunden wird.

Schritt 2: Aktualisieren des Versionscodes der Daten-App

In diesem Schritt aktualisieren OEMs den Versionscode der Daten-App. Der Build übernimmt automatisch distro.zip , aber die neue Version der Daten-App muss einen neuen Versionscode haben, damit sie als neu erkannt wird und zum Ersetzen einer vorinstallierten Daten-App oder einer auf einem Gerät installierten Daten-App durch ein früheres Update verwendet wird.

Wenn Sie die Daten-App mit Dateien erstellen, die aus package/apps/TimeZoneData/oem_template/data_app kopiert wurden, finden Sie den Versionscode/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 sich in testing/Android.mk (allerdings müssen die Testversionscodes höher sein als die System-Image-Version). Einzelheiten finden Sie im Beispielversionscode-Strategieschema . 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 freigeben

In diesem Schritt erstellen OEMs das APK mithilfe von Tapas neu, signieren das generierte APK und testen und veröffentlichen das APK anschließend:

  • Senden Sie bei unveröffentlichten Geräten (oder bei der Vorbereitung eines Systemupdates für ein freigegebenes Gerät) die neuen APKs im vorgefertigten Verzeichnis der Daten-App, um sicherzustellen, dass das System-Image und die xTS-Tests über die neuesten APKs verfügen. OEMs sollten testen, ob die neue Datei ordnungsgemäß funktioniert (d. h., sie besteht CTS und alle OEM-spezifischen automatisierten und manuellen Tests).
  • Für freigegebene Geräte, die keine Systemaktualisierungen mehr erhalten, wird die signierte APK möglicherweise nur über einen App Store veröffentlicht.

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 Versionscode der Daten-App

Die Daten-App muss über eine geeignete Versionierungsstrategie verfügen, um sicherzustellen, dass Geräte die richtigen APKs erhalten. Wenn beispielsweise ein Systemupdate empfangen wird, das eine ältere APK als die 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 + Neben)
  • Eine inkrementelle (undurchsichtige) Versionsnummer

Derzeit korreliert die API-Ebene der Plattform stark mit der Version des Distributionsformats, da jede API-Ebene normalerweise mit einer neuen Version von ICU verknüpft ist (was die Distributionsdateien inkompatibel macht). In Zukunft wird Android dies möglicherweise ändern, sodass eine Distributionsdatei auf mehreren Android-Plattformversionen funktionieren kann (und die API-Ebene im Versionscodeschema der Daten-App nicht verwendet wird).

Beispiel einer Versionscode-Strategie

Dieses Beispiel für ein Versionsnummernschema stellt sicher, dass Versionen im höheren Distributionsformat Vorrang vor Versionen im niedrigeren Distributionsformat haben. AndroidManifest.xml verwendet android:minSdkVersion um sicherzustellen, dass alte Geräte keine Versionen mit einem höheren Distributionsformat erhalten, als sie verarbeiten können.

Versionsprüfung
Abbildung 6. Beispiel einer Versionscode-Strategie
Beispiel Wert Zweck
Y Reserviert Ermöglicht zukünftige alternative Schemata/Test-APKs. Es ist zunächst (implizit) 0. Da der zugrunde liegende Typ ein vorzeichenbehafteter 32-Bit-Int-Typ ist, unterstützt dieses Schema bis zu zwei zukünftige Revisionen des Nummerierungsschemas.
01 Hauptformatversion Verfolgt die Hauptformatversion mit drei Dezimalstellen. Das Distributionsformat unterstützt 3 Dezimalstellen, hier werden jedoch nur 2 Stellen verwendet. Angesichts des erwarteten großen Anstiegs pro API-Ebene ist es unwahrscheinlich, dass 100 erreicht werden. Hauptversion 1 entspricht API-Level 27.
1 Nebenformatversion Verfolgt die Version im Nebenformat mit drei Dezimalstellen. Das Distributionsformat unterstützt 3 Dezimalstellen, hier wird jedoch nur 1 Stelle verwendet. Es ist unwahrscheinlich, dass 10 erreicht werden.
X Reserviert Ist 0 für Produktionsversionen (und kann für Test-APKs unterschiedlich sein).
ZZZZZ Undurchsichtige Versionsnummer Dezimalzahl, die bei Bedarf zugewiesen wird. Enthält Lücken, um bei Bedarf Interstitial-Updates durchführen zu können.

Das Schema könnte besser gepackt werden, wenn Binär statt Dezimal verwendet würde, aber dieses Schema hat den Vorteil, dass es für Menschen lesbar ist. Wenn der gesamte Nummernbereich ausgeschöpft ist, kann sich der Name des Daten-App-Pakets ändern.

Der Versionsname ist eine für Menschen lesbare Darstellung der Details, zum Beispiel: major=001,minor=001,iana=2017a, revision=1,respin=2 . Beispiele sind in der folgenden Tabelle aufgeführt.

# Versionscode minSdkVersion {Hauptformatversion},{Nebenformatversion},{IANA-Regelversion},{Revision}
1 11000010 O-MR1 Dur=001,Moll=001,iana=2017a,Revision=1
2 21000010 P Dur=002,Moll=001,iana=2017a,Revision=1
3 11000020 O-MR1 Dur=001,Moll=001,iana=2017a,Revision=2
4 11000030 O-MR1 Dur=001,Moll=001,iana=2017b,Revision=1
5 21000020 P Dur=002,Moll=001,iana=2017b,Revision=1
6 11000040 O-MR1 Dur=001,Moll=001,iana=2018a,Revision=1
7 21000030 P Dur=002,Moll=001,iana=2018a,Revision=1
8 1123456789 - -
9 11000021 O-MR1 Major=001,Moll=001,iana=2017a,revision=2,respin=2
  • Die Beispiele 1 und 2 zeigen zwei APK-Versionen für dieselbe IANA-Version 2017a mit unterschiedlichen Hauptformatversionen. 2 ist numerisch höher als 1, was erforderlich ist, um sicherzustellen, dass neuere Geräte die höherformatigen Versionen erhalten. Die minSdkVersion stellt sicher, dass die P-Version nicht an O-Geräte bereitgestellt wird.
  • Beispiel 3 ist eine Revision/Korrektur für 1 und ist numerisch höher als 1.
  • Die Beispiele 4 und 5 zeigen die 2017b-Releases für O-MR1 und P. Da sie zahlenmäßig höher sind, ersetzen sie frühere IANA-Releases/Android-Revisionen ihrer jeweiligen Vorgänger.
  • Die Beispiele 6 und 7 zeigen die 2018a-Releases für O-MR1 und P.
  • Beispiel 8 demonstriert die Verwendung von Y, um das Y=0-Schema vollständig zu ersetzen.
  • Beispiel 9 zeigt die Nutzung der Lücke zwischen 3 und 4, um die APK erneut zu drehen.

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

Erstellen der Daten-App mit Tapas

OEMs sind für die Verwaltung der meisten Aspekte der Zeitzonendaten-App und die korrekte Konfiguration des Systemabbilds verantwortlich. Die Daten-App soll mit einem Tapas- Build erstellt werden, der APKs erstellt, die zum Hinzufügen zum System-Image (für die Erstveröffentlichung) und zum Signieren und Verteilen über einen App Store (für spätere Updates) geeignet sind.

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

Erstellen des Manifests

Ein reduzierter Quellbaum wird normalerweise 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. Nachdem OEMs die Anweisungen unter „Erstellen einer Daten-App“ befolgt haben, sollten sie 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 vom App-Build erstellten signierten APKs zur Aufnahme in den System-Image-Build und die xTS-Tests.

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 den minimalen Satz an Git-Projekten, die zur Unterstützung eines O-MR1-Builds der Zeitzonendaten-App erforderlich sind. OEMs müssen ihre OEM-spezifischen Git-Projekte (zu denen normalerweise ein Projekt gehört, das das Signaturzertifikat enthält) zu diesem Manifest hinzufügen und können verschiedene Zweige entsprechend 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" />

Ausführen des Tapas-Builds

Nachdem der Quellbaum erstellt 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

Ein erfolgreicher Build generiert Dateien im out/dist Verzeichnis zum Testen. Diese Dateien können zur Aufnahme in das Systemabbild im Verzeichnis „prebuilts“ abgelegt und/oder über einen App Store für kompatible Geräte verteilt werden.