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:
- 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
- Google oder der Android-Partner bereitet ein Update für das Zeitzonendatenmodul vor (APEX-Datei) mit den aktualisierten Zeitzonen.
- 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
) verwendettzdata
undtzlookup.xml
-Dateien. - Nativer Bibliothekscode in
bionic/
, z. B. fürmktime
, Ortszeit-Systemaufrufe), verwendet die Dateitzdata
. - 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/
- undbionic/
-Code verwenden den/data
-Kopie vontzdata
undtzlookup.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:
- 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.
- 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
- 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
- Fragt den aktuellen Gerätestatus durch Aufrufen von RulesManagerService ab.
- 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.
Abbildung 5: Prüfung abgeschlossen.
- 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.
- Gestaffelten Vorgang mit Erstellung, Ersetzung,
und/oder Löschen der
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
Attribut | Beschreibung | Überschreiben erforderlich? |
---|---|---|
config_enableUpdateableTimeZoneRules |
Muss auf true festgelegt sein, um den RulesManagerService zu aktivieren. |
Ja |
config_timeZoneRulesUpdateTrackingEnabled |
Muss auf true festgelegt sein, damit das System auf Änderungen überwacht
der Daten-App. |
Ja |
config_timeZoneRulesDataPackage |
Paketname der OEM-spezifischen Daten-App. | Ja |
config_timeZoneRulesUpdaterPackage |
Konfiguriert für die Standard-Updater-App. Änderung nur bei Angabe eines einer anderen Updater-App. | Nein |
config_timeZoneRulesCheckTimeMillisAllowed |
Zulässige Zeit zwischen der Auslösung einer Updateprüfung durch den „RulesManagerService“ und eine Antwort auf die Installation, Deinstallation oder Aktion. Nachher kann ein spontaner Zuverlässigkeitstrigger generiert werden. | Nein |
config_timeZoneRulesCheckRetryCount |
Die Anzahl der aufeinanderfolgenden nicht erfolgreichen Updateprüfungen, die vor dem RulesManagerService beendet die Generierung weiterer. | Nein |
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.
![Versionsprüfung](https://source.android.com/static/docs/core/permissions/images/tz_version_check.png?authuser=4&hl=de)
Abbildung 6: Beispiel für eine Strategie mit Versionscode.
Beispiel | Wert | Zweck |
---|---|---|
J | Reserviert | Ermöglicht zukünftige alternative Schemas/Test-APKs. Anfangs (implizit) 0. Da der zugrunde liegende Typ ein 32-Bit-Int-Typ mit Vorzeichen ist, unterstützt dieses Schema bis zu zwei zukünftige Überarbeitungen des Nummerierungsschemas. |
01 | Hauptformatversion | Erfasst die Version im Hauptformat mit 3 Dezimalstellen. Das Distributionsformat unterstützt Hier werden drei Dezimalstellen, aber nur zwei Ziffern verwendet. Es ist unwahrscheinlich, dass 100 erreicht werden. unter Berücksichtigung des erwarteten größeren Inkrements pro API-Level. Hauptversion 1 entspricht auf API-Level 27. |
1 | Version des Nebenformats | Erfasst die Version im Nebenformat mit 3 Dezimalstellen. Das Distributionsformat unterstützt Hier werden drei Dezimalstellen verwendet, aber nur eine. Es ist unwahrscheinlich, dass die 10 erreicht wird. |
X | Reserviert | Ist bei Produktions-Releases 0 (kann bei Test-APKs anders sein). |
ZZZZZ | Intransparente Versionsnummer | Bei Bedarf zugewiesene Dezimalzahl. Enthält Lücken für das Zulassen von Interstitials Aktualisierungen vorgenommen werden. |
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.
# | Versionscode | minSdkVersion | {Major format version},{Minor format version},{IANA-Regeln 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 |
- 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.