Zeitzonenregeln

APK-basierte Zeitzonendaten werden in Android 10 eingestellt (verfügbar unter Android 8.1 und Android 9) und ersetzt diesen durch einen APEX-basierten Modulaktualisierungsmechanismus. AOSP 8.1 bis 13 enthalten weiterhin den Plattformcode, den OEMs zur Aktivierung APK-basierte Updates, also Geräte, die auf Android 10 upgraden können weiterhin vom Partner bereitgestellte Aktualisierungen der Zeitzonendaten über das APK erhalten. Der APK-Updatemechanismus sollte jedoch nicht auf Geräten in der Produktionsphase verwendet werden. das Modulupdates auch erhält, da ein APK-basiertes Update anstelle eines APEX-basiertes Update (d. h. ein Gerät, das ein APK-Update erhalten hat, würde die APEX-basierte Updates).

Aktualisierungen der Zeitzone (Android 10 und höher)

Das Modul für Zeitzonendaten, das in Android 10 und wird die Sommerzeit und die Zeitzonen auf Android-Geräten aktualisiert. Standardisierung von Daten, die sich für religiöse, politische und aus geopolitischen Gründen.

Aktualisierungen erfolgen so:

1. IANA veröffentlicht ein Update der Zeitzonendatenbank veröffentlicht ein Update als Reaktion auf eine oder mehrere Regierungen, die eine Zeitzonenregel in ihrem Land ändern
2. Google oder der Android-Partner bereitet ein Update für das Zeitzonendatenmodul vor (APEX-Datei) mit den aktualisierten Zeitzonen.
3. Das Endnutzergerät lädt das Update herunter, startet neu und wendet dann ändert sich, wonach die Zeitzonendaten des Geräts die neue Zeitzone enthalten. Daten von der Aktualisierung.

Weitere Informationen zu den Modulen finden Sie unter Modulare Systemkomponenten.

Aktualisierungen der Zeitzone (Android 8.1 bis 9)

Hinweis:Bei der APK-basierten Funktion zum Aktualisieren der Zeitzonendaten gibt es ab Android 14 vollständig entfernt wurden und nicht mehr in aus dem Quellcode. Partner sollten vollständig auf die Zeitzone Mainline-Modul.

Unter Android 8.1 und Android 9 können OEMs einen APK-basierten Mechanismus verwenden, um Daten der Zeitzonenregeln auf Geräten aktualisiert, ohne dass ein Systemupdate erforderlich ist. Dieser Mechanismus ermöglicht Nutzern, zeitnah Updates zu erhalten. Lebensdauer eines Android-Geräts) und ermöglicht Android-Partnern, Zeitzonenaktualisierungen unabhängig von System-Image-Updates.

Das Android Core Library-Team stellt die notwendigen Datendateien für Zeitzonenregeln auf einem standardmäßigen Android-Gerät aktualisieren OEMs können diese beim Erstellen von Zeitzonen-Updates für ihre Geräte wenn es bevorzugt wird. In allen Fällen behalten die OEMs die Kontrolle über die Qualität Zusicherung/Tests, Zeitplan und Einführung von Aktualisierungen von Zeitzonenregeln für ihre unterstützten Geräten.

Quellcode und Daten der Android-Zeitzone

Die Zeitzone ist für alle Android-Geräte, auch für solche, die diese Funktion nicht verwenden, erforderlich. und muss mit einem Standardsatz von Zeitzonenregeldaten im Partition /system. Diese Daten werden dann von Code aus dem folgenden Bibliotheken in der Android-Quellstruktur:

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

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

Android-Systemkomponenten, die Daten zu Zeitzonenregeln benötigen, prüfen Folgendes: Orte zuerst:

• libcore/- und bionic/-Code verwenden den /data-Kopie von tzdata und tzlookup.xml Dateien.
• Der ICU4J-/ICU4C-Code verwendet die Dateien in /data und Fallback auf /system-Dateien für nicht vorhandene Daten (für Formate, lokalisierte Zeichenfolgen usw.).

Distro-Dateien

Distro-.zip-Dateien enthalten die Datendateien, die zum Füllen der /data/misc/zoneinfo/current-Verzeichnis. Die Distributionsdateien enthalten Metadaten, die es Geräten ermöglichen, Probleme mit der Versionsverwaltung zu erkennen.

Das Distributionsdateiformat hängt vom Android-Release ab, Änderung mit der ICU-Version, den Anforderungen der Android-Plattform und einem anderen Release Änderungen. Android bietet Distributionsdateien für unterstützte Android-Releases für alle IANA-Update (zusätzlich zur Aktualisierung der Plattformsystemdateien) Damit ihre Geräte auf dem neuesten Stand sind, können OEMs diese Distributionsdateien verwenden oder mithilfe von die Android-Quellstruktur, die die Skripte und anderen Dateien enthält, die für Distributionsdateien generieren).

Komponenten für die Aktualisierung der Zeitzone

Bei einer Aktualisierung der Zeitzonenregeln werden Distributionsdateien an eine Gerät und die sichere Installation der darin enthaltenen Dateien. Übertragen und Für die Installation ist Folgendes erforderlich:

• Funktionen des Plattformdienstes (timezone.RulesManagerService), die standardmäßig deaktiviert ist. OEMs müssen die Funktion über die Konfiguration aktivieren. RulesManagerService wird in den Prozessen und Phasen des Systemservers ausgeführt Zeitzonen-Updates durch Schreiben in /data/misc/zoneinfo/staged. RulesManagerService kann auch bereits bereitgestellte Vorgänge ersetzen oder löschen.
• TimeZoneUpdater, eine nicht aktualisierbare System-App (auch Updater-App genannt). OEMs müssen diese App in das System-Image aufnehmen der Geräte, die diese Funktion nutzen.
• OEM TimeZoneData, eine aktualisierbare System-App die Daten-App), die Distributionsdateien auf das Gerät überträgt und sie für die Updater App verfügbar. OEMs müssen diese App in das System-Image der Geräte, auf denen die Funktion verwendet wird.
• tzdatacheck, ein Bootzeit-Binärprogramm, das für den korrekten und sicheren Betrieb von Zeitzonenaktualisierungen erforderlich ist.

Die Android-Quellstruktur enthält generischen Quellcode für Komponenten, die der OEM ohne Änderungen verwenden kann. Code testen wird bereitgestellt, damit OEMs automatisch prüfen können, ob sie die Funktion korrekt aktiviert haben.

Installation der Distribution

Die Installation der Distribution umfasst die folgenden Schritte:

1. Die Daten-App wird aktualisiert, indem ein App-Shop-Download oder Sideload. Der Systemserverprozess (durch timezone.RulesManagerServer/timezone.PackageTracker Kurs) achtet auf Änderungen am konfigurierten, OEM-spezifischen Daten-App-Paket Namen.
   
   

   Abbildung 1: Daten-App-Updates.

2. Der Systemserverprozess löst eine Updateprüfung aus, indem Die Übertragung eines zielgerichteten Intents mit einem eindeutigen, Einmal-Token an den Updater Anw. Der Systemserver speichert das zuletzt generierte Token, kann feststellen, wann die letzte ausgelöste Prüfung abgeschlossen ist. alle anderen werden ignoriert.
   
   

   Abbildung 2: Update-Prüfung auslösen

3. Während der Updateprüfung führt die Updater-App folgende Aufgaben ausführen: <ph type="x-smartling-placeholder">
   </ph>
   • Fragt den aktuellen Gerätestatus durch Aufrufen von RulesManagerService ab.
     
     

     Abbildung 3: Daten-App-Updates, RulesManagerService wird aufgerufen.

   • Fragt die Data-App ab, indem eine klar definierte ContentProvider-URL und um Informationen zur Distribution zu erhalten.
     
     

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

4. Die Updater App ergreift je nach Informationen enthalten. Folgende Aktionen sind verfügbar: <ph type="x-smartling-placeholder">
   </ph>
   • Installation anfordern Verteilungsdaten werden aus der Daten-App gelesen und an den RulesManagerService im Systemserver übergeben. Die RulesManagerService bestätigt erneut, dass Version und Inhalt des Distributionsformats und führt die Installation durch.
   • Eine Deinstallation anfordern (kommt selten vor). Wenn zum Beispiel die aktualisierte Das APK in /data wird deaktiviert oder deinstalliert und das Gerät ist Sie kehren zu der in /system vorhandenen Version zurück.
   • Nichts unternehmen: Tritt auf, wenn die Daten-App-Distribution als ungültig eingestuft wird.
   In allen Fällen ruft die Updater-App den RulesManagerService mit dem Prüftoken auf. damit der Systemserver weiß, dass die Prüfung abgeschlossen ist.
   
   

   Abbildung 5: Prüfung abgeschlossen.

5. Neu starten und tzdatacheck durchführen Beim nächsten Start des Geräts das tzdatacheck-Binärprogramm einen abgestuften Vorgang ausführt. Die tzdatacheck-Binärdatei kann die folgenden Aufgaben ausführen: <ph type="x-smartling-placeholder">
   </ph>
   • Gestaffelten Vorgang mit Erstellung, Ersetzung, und/oder Löschen der /data/misc/zoneinfo/current-Dateien vor dem andere Systemkomponenten geöffnet und gestartet wurden, die Dateien zu verwenden.
   • Prüfen Sie, ob die Dateien in /data für den aktuellen Dies ist möglicherweise nicht der Fall, wenn das Gerät gerade eine Systemupdate und die Version des Distributionsformats hat sich geändert.
   • Die Version der IANA-Regeln muss mit der Version in /system Dies schützt vor Systemupdates, die das Gerät verlassen. mit älteren Daten zu Zeitzonenregeln als in /system vorhanden Bild.

Zuverlässigkeit

Der End-to-End-Installationsprozess ist asynchron und auf drei Betriebssysteme aufgeteilt. Prozesse. Während der Installation kann es passieren, dass die Stromversorgung des Geräts unterbrochen wird. nicht genügend Speicherplatz zur Verfügung steht oder andere Probleme auftreten, sodass die Installationsprüfung unvollständig sein. Im besten Fall informiert die Updater-App das System Server meldet, dass die Ausführung nicht erfolgreich war. im schlimmsten Fall, RulesManagerService empfängt keinen Aufruf.

Um dies zu verarbeiten, erfasst der Systemservercode, ob ein ausgelöster die Prüfung auf Updates abgeschlossen ist und den zuletzt geprüften Versionscode der Daten Die App ist. Wenn das Gerät inaktiv ist und aufgeladen wird, kann der Systemservercode die den aktuellen Status. Bei einer unvollständigen Updateprüfung oder unerwarteten Daten App-Version löst sie spontan eine Updateprüfung aus.

Sicherheit

Wenn diese Option aktiviert ist, führt der RulesManagerService-Code auf dem Systemserver um sicherzustellen, dass das System sicher ist.

• Probleme, die auf ein falsch konfiguriertes System-Image hinweisen, verhindern, dass ein Gerät Booten; Beispiele hierfür sind eine fehlerhafte Updater- oder Daten-App-Konfiguration oder der Updater oder Daten-App ist nicht in /system/priv-app.
• Probleme, die darauf hinweisen, dass eine fehlerhafte Data-App installiert wurde, verhindern nicht, das Gerät startet, aber verhindern, dass eine Updateprüfung ausgelöst wird. Beispiele fehlende erforderliche Systemberechtigungen enthalten oder die Daten-App keine ContentProvider für den erwarteten URI verwenden.

Dateiberechtigungen für die Verzeichnisse /data/misc/zoneinfo sind die mithilfe von SELinux-Regeln erzwungen werden. Wie alle APKs muss auch die Daten-App vom derselbe Schlüssel, der zum Signieren der /system/priv-app-Version verwendet wurde. Die Daten-App ist benötigen einen speziellen, OEM-spezifischen Paketnamen und Schlüssel.

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 System-Image-Build ein.
• Konfigurieren Sie den Systemserver, um den RulesManagerService zu aktivieren.

Vorbereitung

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

• Einen dedizierten App-spezifischen Signaturschlüssel für die Data-App erstellen
• Release- und Versionsverwaltungsstrategie für Zeitzonenaktualisierungen erstellen welche Geräte aktualisiert werden und wie sie Updates nur auf Geräten installiert werden, die sie benötigen. Zum Beispiel möchten OEMs eine einzige Daten-App für alle Geräte haben oder sich für Daten-Apps für verschiedene Geräte Die Entscheidung wirkt sich auf die Paketauswahl aus. Name, möglicherweise die verwendeten Versionscodes und die QA-Strategie.
• Herausfinden, ob er Android-Zeitzonendaten verwenden möchte von AOSP erhalten oder eigene erstellen.

Daten-App erstellen

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

OEMs können die Daten-App mit einem eigenen Symbol, Namen, eigenen Übersetzungen und weitere Details. Da die Daten-App jedoch nicht gestartet werden kann, erscheint das Symbol unter Einstellungen > Apps angezeigt.

Die Daten-App sollte mit einem tapas-Build erstellt werden. erstellt, die APKs erstellt, die zum System-Image hinzugefügt werden können (für die erste veröffentlicht und signiert und über einen App-Shop vertrieben (für nachfolgende Updates). Details zur Verwendung von Tapas finden Sie unter Aufbau des Daten-App, die Tapas verwendet.

OEMs müssen die Daten-App, die im System-Image eines Geräts vorgefertigt ist, /system/priv-app Um vorgefertigte APKs hinzuzufügen, die von den Tapas-Mitgliedern generiert wurden im System-Image enthalten, können OEMs die Beispieldateien in das packages/apps/TimeZoneData/oem_template/data_app_prebuilt Die Beispielvorlagen enthalten auch Build-Ziele zum Einbinden von Testversionen der Daten-App in Testsuiten.

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

OEMs müssen die Updater- und Daten-App-APKs im Das Verzeichnis /system/priv-app des System-Images. Zu diesem Zweck System-Image-Build muss explizit die Updater-App und die vorkonfigurierte Daten-App enthalten Ziele.

Die Updater-App muss mit dem Plattformschlüssel signiert und als anderen System-Apps. Das Ziel ist definiert in packages/apps/TimeZoneUpdater als TimeZoneUpdater. Die Die Aufnahme von Daten-Apps ist OEM-spezifisch und hängt davon ab, welcher Zielname für den vorab erstellen.

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Konfigurationsüberschreibungen sollten im System-Image enthalten sein (nicht im Anbieter- oder sonstigen Image). da ein falsch konfiguriertes Gerät den Start verweigern kann. Wenn die Konfiguration überschreibt im Anbieter-Image auf ein System-Image ohne Daten-App (oder Daten-App/Updater-App-Paketnamen) gelten als Fehlkonfiguration.

xTS-Tests

xTS bezieht sich auf jede OEM-spezifische Testsuite, die der standardmäßigen Android-Version ähnelt. Testsuites mit Tradefed (z. B. CTS und VTS). OEMs, die einen solchen Test die folgenden Tests für Android-Zeitzonen-Updates hinzufügen: Standorte:

• packages/apps/TimeZoneData/testing/xts enthält den Code die für einfache automatisierte Funktionstests erforderlich sind.
• packages/apps/TimeZoneData/oem_template/xts enthält eine Leseprobe Verzeichnisstruktur zum Einbinden von Tests in einer Tradefed-ähnlichen xTS-Suite. Wie bei anderen Vorlagenverzeichnissen verwenden, wird von den OEMs erwartet, dass sie diese in ihre Anforderungen.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt enthält eine Konfiguration zur Build-Zeit, um die erforderlichen vordefinierten Test-APKs einzuschließen durch den Test.

Zeitzonenaktualisierungen erstellen

Wenn IANA neue Zeitzonenregeln veröffentlicht, Patches zur Aktualisierung von Releases in AOSP. OEMs nutzen die standardmäßig verwendete Android-Version. System- und Distro-Dateien können diese Commits abrufen und damit ein neues Version ihrer Daten-App und veröffentlichen dann die neue Version, um ihre Geräte zu aktualisieren. in der Produktion.

Da Daten-Apps Distributionsdateien enthalten, die eng mit Android-Versionen verbunden sind, OEMs müssen eine neue Version der Daten-App für alle unterstützten Android-Version, die ein OEM aktualisieren möchte. Wenn ein OEM beispielsweise Updates für Android 8.1, 9 und 10 muss der Vorgang dreimal abgeschlossen werden.

Schritt 1: System-/Zeitzonen- und externe Datendateien sowie ICS-Dateien aktualisieren

In diesem Schritt nehmen OEMs Android-Commits für system/timezone und external/icu von Release-dev-Zweige in AOSP und wenden diese Commits auf ihre Kopie von des Android-Quellcodes.

Der AOSP-Patch für System/Zeitzone enthält aktualisierte Dateien in system/timezone/input_data und system/timezone/output_data. OEMs, die zusätzliche lokale die Eingabedateien ändern und dann die Dateien in system/timezone/input_data und external/icu nach Dateien in output_data generieren.

Die wichtigste Datei ist system/timezone/output_data/distro/distro.zip, was automatisch eingefügt, wenn das APK der Daten-App erstellt wird.

Schritt 2: Versionscode der Daten-App aktualisieren

In diesem Schritt aktualisieren OEMs den Versionscode der Daten-App. Der Build nimmt automatisch distro.zip auf, aber die neue Version des Die Daten-App muss einen neuen Versionscode haben, damit sie als neu erkannt wird und für Folgendes verwendet wird: eine vorinstallierte Daten-App oder eine auf einem Gerät installierte Daten-App durch eine aktualisieren.

Beim Erstellen der Daten-App mit Dateien, die kopiert wurden aus package/apps/TimeZoneData/oem_template/data_app, finden Sie hier: Versionscode bzw. Versionsname für das APK in Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Ähnliche Einträge sind in testing/Android.mk zu finden (die die Codes der Testversionen müssen höher sein als die der System-Image-Version. Weitere Informationen Beispielversion mit Codestrategie ansehen wenn das Beispielschema oder ein ähnliches Schema verwendet wird, Versionscodes müssen 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 mit Tapas, signieren das generierte APK testen und freigeben:

• Bei noch nicht veröffentlichten Geräten oder bei der Vorbereitung eines Systemupdates veröffentlichtes Gerät), reichen Sie die neuen APKs im vordefinierten Verzeichnis der Daten-App ein. um sicherzustellen, dass für das System-Image und die xTS-Tests die neuesten APKs verwendet werden. OEMs sollten Testen Sie, ob die neue Datei ordnungsgemäß funktioniert, d. h., sie muss CTS und alle OEM-spezifische automatisierte und manuelle Tests).
• Bei auf veröffentlichten Geräten, die keine Systemupdates mehr erhalten, das signierte APK werden möglicherweise nur über einen App-Shop veröffentlicht.

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

Codestrategie für Daten-App-Version

Die Daten-App benötigt eine geeignet , um sicherzustellen, dass Geräte die richtigen APKs erhalten. Für Beispiel: Wenn ein Systemupdate empfangen wird, das ein älteres APK als eines enthält, aus dem App-Shop heruntergeladen haben, sollte die App-Shop-Version beibehalten werden.

Der APK-Versionscode sollte die folgenden Informationen enthalten:

• Distroformatversion (Haupt- und Nebenversion)
• Eine zunehmende (undurchsichtige) Versionsnummer

Derzeit steht das API-Level der Plattform stark in Beziehung zur Version des Distributionsformats da jedes API-Level normalerweise einer neuen Version der ITS zugeordnet ist. führt dazu, dass die Distributionsdateien nicht kompatibel sind. Zukünftig kann Android dies so ändern, dass eine Distributionsdatei mit mehreren Android-Plattform-Releases (und APIs) wird im Versionscodeschema der Daten-App nicht verwendet).

Beispiel für eine Strategie mit Versionscode

Dieses beispielhafte Versionsverwaltungsnummernschema sorgt dafür, dass ein höheres Distributionsformat Versionen niedrigere Distributionsformatversionen ersetzen. AndroidManifest.xml verwendet android:minSdkVersion, um sicherzustellen, dass alte Geräte keine Versionen mit einem höheren Distributionsformat erhalten als sie verarbeiten können.

Abbildung 6: Beispiel für eine Strategie mit Versionscode.

Das Schema könnte besser gepackt werden, wenn statt Dezimalzahlen ein Binärcode verwendet würde, aber hat den Vorteil, dass dieses Schema menschenlesbar ist. Wenn der vollständige Zahlenbereich erschöpft ist, könnte sich der Name des Daten-App-Pakets ändern.

Der Versionsname ist eine menschenlesbare Darstellung der Details, z. B. Beispiel: major=001,minor=001,iana=2017a, revision=1,respin=2. Beispiele finden Sie in der folgenden Tabelle.

• Die Beispiele 1 und 2 zeigen zwei APK-Versionen für dieselbe IANA-Version 2017a. mit verschiedenen Hauptformatversionen. 2 ist numerisch höher als 1, damit neuere Geräte die höhere Version erhalten. Die Mit minSdkVersion wird sichergestellt, dass O-Geräten die Version P nicht bereitgestellt wird.
• Beispiel 3 ist eine Überarbeitung/Korrektur für 1 und ist numerisch höher als 1.
• Die Beispiele 4 und 5 zeigen die Releases von O-MR1 und P von 2017b. Zahlenangaben ersetzen sie frühere IANA-Versionen/Android-Versionen ihrer jeweiligen ihre Vorgänger.
• In den Beispielen 6 und 7 sind die Releases von O-MR1 und P von 2018a zu sehen.
• Beispiel 8 zeigt die Verwendung von Y, um das Schema Y=0 vollständig zu ersetzen.
• In Beispiel 9 wird gezeigt, wie die Lücke zwischen 3 und 4 genutzt wird, um erneut zu drehen. die APK-Datei.

Da jedes Gerät mit einem standardmäßigen APK mit passenden Versionen ausgeliefert wird, finden Sie in der System-Image haben, 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. A Gerät mit einer in /data installierten O-MR1-Version, die dann ein Systemupdate auf P verwendet die Version /system bevorzugt die O-MR1-Version in /data, da die P-Version immer höher ist als jede andere für O-MR1 vorgesehene App.

Die Daten-App mit Tapas entwickeln

OEMs sind für die Verwaltung der meisten Aspekte der Zeitzonendaten-App und das System-Image richtig konfiguriert. Die Daten-App soll eine mit einem tapas-Build, der APKs erstellt, die zum das System-Image (für die erste Version) erstellt und über einen App-Shop (für spätere Updates)

Tapas ist eine vereinfachte Version des Android-Builds. System, das einen reduzierten Quellbaum zur Erstellung verteilbarer Versionen Apps. OEMs, die mit dem normalen Android-Build-System vertraut sind, sollten Build-Dateien aus dem normalen Android-Plattform-Build erstellen.

Manifest erstellen

Ein reduzierter Quellbaum wird normalerweise mit einer benutzerdefinierten Manifestdatei erreicht, die bezieht sich nur auf die Git-Projekte, die vom Build-System und zum Erstellen der Nachdem Sie die Anweisungen in Bei der Erstellung einer Daten-App sollten OEMs mindestens zwei OEM-spezifische Git-Projekte, die mithilfe der Vorlagendateien unter packages/apps/TimeZoneData/oem_template:

• Ein Git-Projekt enthält App-Dateien wie das Manifest und den Build-Dateien, die zum Erstellen der APK-Datei der App erforderlich sind, z. B. vendor/oem/apps/TimeZoneData. Dieses Projekt hat auch enthält 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 die System-Image-Builds und in die xTS-Tests.

Der App-Build nutzt mehrere andere Git-Projekte, die mit dem Plattform erstellen oder OEM-unabhängige Codebibliotheken enthalten.

Das folgende Manifest-Snippet enthält die minimale Anzahl von Git-Projekten die zur Unterstützung eines O-MR1-Builds der Daten-App für Zeitzonen erforderlich sind. OEMs müssen ihre OEM-spezifischen Git-Projekte hinzufügen (die in der Regel ein Projekt enthalten, enthält das Signaturzertifikat) an dieses Manifest und können andere Zweige entsprechend.

   <!-- 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 die Quellstruktur erstellt wurde, rufen Sie den Build tapas auf. mit den folgenden Befehlen:

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 für Tests durchführen. Diese Dateien können zur Aufnahme in das vorkonfigurierte Verzeichnis System-Image und/oder werden über einen App-Shop für kompatible Geräte.