Zeitzonenregeln

Android 10 macht den APK-basierten Zeitzonendatenaktualisierungsmechanismus (verfügbar in Android 8.1 und Android 9) veraltet und ersetzt ihn durch einen APEX-basierten Modulaktualisierungsmechanismus . AOSP 8.1 bis 13 enthalten weiterhin den Plattformcode, der für OEMs erforderlich ist, um APK-basierte Updates zu aktivieren, sodass Geräte, die auf Android 10 aktualisieren, weiterhin von Partnern bereitgestellte Zeitzonendaten-Updates über APK erhalten können. Der APK-Update-Mechanismus 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 (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 Zeitzonendatenmodul 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 für die Zeitzonendatenbank veröffentlicht ein Update als Reaktion auf eine oder mehrere Regierungen, die eine Zeitzonenregel in ihren Ländern ändern.
2. Google oder der Android-Partner bereitet 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 wendet dann die Änderungen an, wonach die Zeitzonendaten des Geräts die neuen Zeitzonendaten aus dem Update enthalten.

Einzelheiten zu Modulen finden Sie unter Modulare Systemkomponenten .

Zeitzonenaktualisierungen (Android 8.1–9)

Hinweis: Die APK-basierte Funktion zum Aktualisieren von Zeitzonendaten wurde ab Android U vollständig entfernt und ist nicht mehr 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 Zeitzonenregeldaten auf 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 von 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/Tests, das Timing 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 verwenden, benötigen Zeitzonenregeldaten und müssen mit einem Standardsatz von 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 , localtime-Systemaufrufe) verwendet die tzdata -Datei.
• Der ICU4J/ICU4C-Bibliothekscode in external/icu/ verwendet die icu .dat -Datei.

Diese Bibliotheken verfolgen 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 zuerst die folgenden Speicherorte:

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

Distributionsdateien

Distro- .zip -Dateien enthalten die Datendateien, die zum Auffüllen des Verzeichnisses /data/misc/zoneinfo/current benötigt werden. Die Distributionsdateien enthalten auch Metadaten, mit denen Geräte Versionsprobleme erkennen können.

Das Dateiformat der Distribution ist von der Android-Version abhängig, da sich der Inhalt mit der ICU-Version, den Android-Plattformanforderungen und anderen Versionsänderungen ändert. Android stellt Distributionsdateien für unterstützte Android-Versionen für jedes IANA-Update 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 Skripte und andere Dateien enthält, die zum Generieren von Distributionsdateien erforderlich sind).

Zeitzonenaktualisierungskomponenten

Eine Aktualisierung der Zeitzonenregeln beinhaltet die Übertragung von Distributionsdateien auf ein Gerät und die sichere Installation der darin enthaltenen Dateien. Übertragung und Installation erfordern Folgendes:

• 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 stellt Zeitzonenaktualisierungsvorgänge bereit, indem er in /data/misc/zoneinfo/staged schreibt. 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 aufnehmen, die diese Funktion verwenden.
• OEM TimeZoneData , eine aktualisierbare System-App (auch als Daten-App bezeichnet), 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 aufnehmen, die diese Funktion verwenden.
• 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, die der OEM ohne Modifikation verwenden kann. Testcode wird bereitgestellt, damit OEMs automatisch überprüfen können, ob sie die Funktion korrekt aktiviert haben.

Distributionsinstallation

Der Installationsvorgang der Distribution umfasst die folgenden Schritte:

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

   

2. Der Systemserverprozess löst eine Aktualisierungsprüfung aus, indem er eine gezielte Absicht mit einem eindeutigen, einmalig verwendbaren Token an die Updater-App sendet. Der Systemserver verfolgt das letzte Token, das er erzeugt hat, so dass er bestimmen kann, wann die letzte Prüfung, die er ausgelöst hat, abgeschlossen ist; Alle anderen Token werden ignoriert.
   
   

   

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

     

   • Fragt die Daten-App ab, indem eine wohldefinierte ContentProvider-URL und Spaltenspezifikationen abgefragt werden, um Informationen über die Distribution zu erhalten.
     
     

     

4. Die Updater-App ergreift die entsprechenden Maßnahmen basierend auf den ihr vorliegenden Informationen. Zu den verfügbaren Aktionen gehören:
   • Fordern Sie eine Installation an. Distributionsdaten werden aus der Daten-App gelesen und an 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 ist selten). Zum Beispiel, wenn das aktualisierte APK in /data deaktiviert oder deinstalliert wird und das Gerät zu der in /system vorhandenen 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.
   
   

   

5. Neustart und tzdatacheck. Wenn das Gerät das nächste Mal hochfährt, führt die tzdatacheck-Binärdatei alle inszenierten Operationen aus. Die tzdatacheck-Binärdatei kann die folgenden Aufgaben ausführen:
   • Führen Sie die gestufte Operation aus, indem Sie die Erstellung, Ersetzung und/oder Löschung der /data/misc/zoneinfo/current Dateien behandeln, bevor andere Systemkomponenten geöffnet wurden und mit der Verwendung der Dateien begonnen haben.
   • Überprüfen Sie, ob die Dateien in /data für die aktuelle Plattformversion korrekt sind, was möglicherweise nicht der Fall ist, 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 gleich oder neuer ist als die Version in /system . Dies schützt vor einem Systemupdate, das ein Gerät mit älteren Zeitzonenregeldaten hinterlässt, als im /system Image vorhanden sind.

Verlässlichkeit

Der End-to-End-Installationsprozess ist asynchron und auf drei Betriebssystemprozesse aufgeteilt. Zu jedem Zeitpunkt der Installation kann das Gerät Strom verlieren, keinen Speicherplatz mehr haben oder auf andere Probleme stoßen, die dazu führen, dass die Installationsprüfung unvollständig ist. Im besten Fall ohne Erfolg informiert die Updater-App den Systemserver darüber, dass sie nicht erfolgreich war; im schlimmsten erfolglosen Fall erhält der RulesManagerService überhaupt keinen Aufruf.

Um dies zu handhaben, verfolgt der Systemservercode, ob eine ausgelöste Aktualisierungsprüfung abgeschlossen wurde und was der letzte geprüfte Versionscode der Daten-App ist. Wenn das Gerät im Leerlauf ist und lädt, kann der Systemservercode den aktuellen Status überprüfen. Wenn es eine unvollständige Update-Prüfung oder eine unerwartete Data App-Version entdeckt, löst es spontan eine Update-Prüfung aus.

Sicherheit

Wenn aktiviert, 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 die Updater- oder Daten-App befindet sich nicht in /system/priv-app .
• Probleme, die darauf hindeuten, dass eine fehlerhafte Daten-App installiert wurde, verhindern nicht das Starten eines Geräts, aber verhindern, dass eine Update-Prüfung ausgelöst wird; Beispiele hierfür sind das Fehlen erforderlicher Systemberechtigungen oder die Daten-App macht keinen ContentProvider für den erwarteten URI verfügbar.

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 wird. Es wird erwartet, dass die Daten-App einen dedizierten, OEM-spezifischen Paketnamen und Schlüssel hat.

Integrieren von Zeitzonenaktualisierungen

Um die Zeitzonenaktualisierungsfunktion zu aktivieren, gehen OEMs in der Regel wie folgt vor:

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

Vorbereiten

Bevor Sie beginnen, sollten OEMs die folgenden Richtlinien, Qualitätssicherungs- und Sicherheitsüberlegungen überprüfen:

• Erstellen Sie einen dedizierten App-spezifischen Signaturschlüssel für ihre Daten-App.
• Erstellen Sie eine Release- und Versionierungsstrategie für Zeitzonen-Updates, um zu verstehen, welche Geräte aktualisiert werden und wie sie sicherstellen 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 haben oder sich dafür entscheiden, unterschiedliche Daten-Apps für verschiedene Geräte zu haben. Die Entscheidung wirkt sich auf die Wahl des Paketnamens, möglicherweise der verwendeten Versionscodes und der QA-Strategie aus.
• Verstehen Sie, ob sie Standard-Android-Zeitzonendaten von AOSP verwenden oder eigene 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 TimeZoneData erforderlich sind, mit Anweisungen und Beispielvorlagen für AndroidManifest.xml und andere Dateien, die sich in packages/apps/TimeZoneData/oem_template . 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 ihrem 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 erzeugt, die zum Hinzufügen zum Systemabbild (für die erste Version) 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 mit Tapas .

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

Einschließen der Updater- und Daten-Apps in das Systemabbild

OEMs müssen die Updater- und Daten-App-APKs im Verzeichnis /system/priv-app des Systemabbilds 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 Einbeziehung 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 .

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Konfigurationsüberschreibungen sollten im Systemabbild (nicht vom Hersteller oder anderem) enthalten sein, 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-Tests

xTS bezieht sich auf jede OEM-spezifische Testsuite, die Standard-Android-Testsuiten mit Tradefed ähnelt (z. B. CTS und VTS). OEMs, die über solche Testsuiten verfügen, können die Android-Zeitzonenaktualisierungstests hinzufügen, die an den folgenden Orten bereitgestellt werden:

• packages/apps/TimeZoneData/testing/xts enthält den Code, der für grundlegende automatisierte Funktionstests benötigt wird.
• packages/apps/TimeZoneData/oem_template/xts enthält eine Musterverzeichnisstruktur 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 Einschließen der vorgefertigten Test-APKs, die für den Test erforderlich sind.

Erstellen von Zeitzonenaktualisierungen

Wenn die IANA einen neuen Satz von Zeitzonenregeln veröffentlicht, generiert das Team der Android-Kernbibliotheken Patches, um Versionen in AOSP zu aktualisieren. OEMs, die das Standard-Android-System und die Distributionsdateien verwenden, können diese Commits übernehmen, sie verwenden, um eine neue Version ihrer Daten-App zu 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 abschließen.

Schritt 1: Aktualisieren von System-/Zeitzonen- und externen/icu-Datendateien

In diesem Schritt nehmen OEMs Bestands-Android-Commits für system/timezone timezone und external/icu aus den Zweigen release -dev in AOSP 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 , um Dateien in output_data zu generieren.

Die wichtigste Datei ist system/timezone/output_data/distro/distro.zip , die beim Erstellen der Daten-App-APK automatisch enthalten ist.

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 verwendet wird, um eine vorinstallierte Daten-App oder eine auf einem Gerät installierte Daten-App durch ein vorheriges Update zu ersetzen.

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Ähnliche Einträge finden sich in testing/Android.mk (die Testversionscodes müssen jedoch höher sein als die System-Image-Version). Einzelheiten finden Sie im Beispiel-Versionscode-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 echten 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 dann das APK:

• Senden Sie für unveröffentlichte Geräte (oder beim Vorbereiten eines Systemupdates für ein veröffentlichtes Gerät) die neuen APKs im vorgefertigten Verzeichnis der Daten-App, um sicherzustellen, dass das System-Image und die xTS-Tests die neuesten APKs enthalten. 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 Systemupdates mehr erhalten, wird das 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 Daten-App-Versionscode

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 ein älteres APK enthält als das aus dem App Store heruntergeladene, sollte die App Store-Version beibehalten werden.

Der APK-Versionscode sollte die folgenden Informationen enthalten:

• Version im Distro-Format (Haupt- und Nebenversion)
• Eine inkrementierende (undurchsichtige) 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 über mehrere Android-Plattformversionen hinweg funktionieren kann (und die API-Ebene wird nicht im Daten-App-Versionscodeschema verwendet).

Beispielversionscode-Strategie

Dieses beispielhafte Versionsnummernschema stellt sicher, dass Versionen mit höheren Distributionsformaten Versionen mit niedrigeren Distributionsformaten ersetzen. AndroidManifest.xml verwendet android:minSdkVersion , um sicherzustellen, dass alte Geräte keine Versionen mit einer höheren Distributionsformatversion erhalten, als sie verarbeiten können.

Das Schema könnte besser gepackt werden, wenn binär anstelle von dezimal verwendet würde, aber dieses Schema hat den Vorteil, dass es für Menschen lesbar ist. Wenn der vollständige Nummernbereich erschöpft ist, kann sich der Paketname der Daten-App ä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 gezeigt.

• Die Beispiele 1 und 2 zeigen zwei APK-Versionen für dieselbe 2017a-IANA-Version mit unterschiedlichen Hauptformatversionen. 2 ist numerisch höher als 1, was erforderlich ist, um sicherzustellen, dass neuere Geräte die höheren Formatversionen erhalten. Die minSdkVersion stellt sicher, dass die P-Version nicht an O-Geräte geliefert wird.
• Beispiel 3 ist eine Überarbeitung/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 Veröffentlichungen von 2018a für O-MR1 und P.
• Beispiel 8 demonstriert die Verwendung von Y, um das Y=0-Schema vollständig zu ersetzen.
• Beispiel 9 demonstriert die Verwendung der Lücke zwischen 3 und 4, um die apk erneut zu drehen.

Da jedes Gerät mit einer 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 sie 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 App, die für O- 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 erzeugt, die zum Hinzufügen zum Systemabbild (für die erste Version) 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 aus dem normalen Android-Plattform-Build erkennen.

Erstellen des Manifests

Ein reduzierter Quellbaum wird normalerweise mit einer benutzerdefinierten Manifestdatei erreicht, die sich nur auf die Git-Projekte bezieht, die vom Buildsystem und zum Erstellen der App benötigt werden. Nachdem Sie die Anweisungen in Erstellen einer Daten-App befolgt haben, sollten OEMs mindestens zwei OEM-spezifische Git-Projekte haben, die mithilfe der Vorlagendateien unter packages/apps/TimeZoneData/oem_template :

• 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 zur 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 den minimalen Satz von Git-Projekten, die zur Unterstützung eines O-MR1-Builds der Zeitzonendaten-App erforderlich sind. OEMs müssen ihre OEM-spezifischen Git-Projekte (die in der Regel ein Projekt enthalten, das das Signaturzertifikat enthält) zu diesem Manifest hinzufügen und können verschiedene Branches 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="master"
        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 Verzeichnis out/dist zum Testen. Diese Dateien können zur Aufnahme in das Systemabbild in das vorgefertigte Verzeichnis gestellt und/oder über einen App Store für kompatible Geräte vertrieben werden.