OEM-Design-Tokens sind eine Android Automotive OS (AAOS)-Implementierung des Material Design- Systems. Im Gegensatz zum Algorithmus- oder Benutzerauswahlansatz für Tokenwerte auf Mobilgeräten legen OEMs Design-Tokenwerte fest. Design-Token stellen kleine, wiederholte Designentscheidungen dar, die den visuellen Stil eines Designsystems ausmachen und statische Werte durch selbsterklärende Namen ersetzen. Token entsprechen denen, die vom Material Design-System definiert werden.
OEM-Token-Bibliothek
Auf OEM-Design-Tokens wird über die OEM-Token-Bibliothek verwiesen, die aus den drei in Abbildung 1 dargestellten Komponenten besteht.
Abbildung 1. Komponenten der OEM-Token-Bibliothek.
Statische Bibliothek
Die statische Bibliothekskomponente der OEM-Token-Bibliothek erleichtert den Zugriff auf Token-Werte wie folgt.
- Stellt APIs für den Zugriff auf OEM-Werte für Token bereit.
- Ermöglicht das Opt-In-Überschreiben von Token-Referenzen im Design mit OEM-Werten.
Gemeinsame Bibliothek
Die gemeinsam genutzte Bibliothekskomponente ist für die Definition von Folgendem verantwortlich:
- Bibliotheksname.
- Boolesches Opt-in zur Aktivierung für OEM-Tokenwerte.
- Stil, der OEM-Tokenwerte bereitstellt.
Um den OEM-Besitz dieser gemeinsam genutzten Bibliothekskomponente, einschließlich eines OEM-definierten Paketnamens, zu berücksichtigen, können OEMs eine Überschreibung der gemeinsam genutzten Bibliotheksimplementierung erstellen.
Abbildung 2. Überschreiben Sie eine gemeinsam genutzte Bibliotheksimplementierung.
Gemeinsam genutzte OEM-Bibliothek
OEM-Überschreibungen der gemeinsam genutzten Bibliothekskomponente ermöglichen das OEM-Eigentum an der Bibliothek und wahren gleichzeitig die Kompatibilität mit anderen Komponenten in der OEM-Token-Bibliothek, indem sie eine Möglichkeit bieten, den Paketnamen und die Signatur durch OEMs festzulegen, während die Implementierung der gemeinsam genutzten Bibliothek ansonsten unverändert bleibt.
Überschreibungen für eine gemeinsam genutzte Bibliothek können wie folgt definiert werden:
override_android_app {
name: "[OEM]-token-shared-lib",
base: "token-shared-lib",
package_name: "com.[OEM].sharedlib",
rename_resources_package: false,
certificate: …
}
Informationen zum Festlegen von Tokenwerten finden Sie unter Angeben von OEM-Tokenwerten .
Anpassungen der gemeinsam genutzten OEM-Bibliothek
Um unterschiedliche Schemata für Token-Werte zu unterstützen (z. B. Modell- oder Antriebsmodusdifferenzierung), können OEMs dynamische Werte für Token bereitstellen, indem sie mit Runtime Resource Overlays (RROs) auf die gemeinsam genutzte OEM-Bibliothek abzielen. Weitere Informationen finden Sie unter Ändern des Werts der Ressourcen einer App zur Laufzeit .
Informationen zum Festlegen von Tokenwerten finden Sie unter Angeben von OEM-Tokenwerten .
Geben Sie OEM-Token-Werte an
Um Tokenwerte anzugeben, legen Sie das entsprechende Attribut im Stil OemStyle auf den erforderlichen Wert fest.
<resources>
<style name="OemStyle">
<item name="colorPrimary">#B0C5FF</item>
<item name="colorOnPrimary">#002B76</item>
<item name="colorPrimaryContainer">#003FA4</item>
<item name="colorOnPrimaryContainer">#D9E2FF</item>
…
</style>
</resources>
Melden Sie sich für OEM-Werte an
Damit Apps auf vom OEM bereitgestellte Token-Werte zugreifen können, müssen OEMs zunächst das Überschreiben von Standard-Token-Werten aktivieren, indem sie den booleschen Wert enable_oem_tokens auf „ true konfigurieren.
RRO-Token-Werte
Ähnlich wie Tokenwerte in OemStyle festgelegt werden, können RROs verwendet werden, um den Stil zu ändern, um alternative Tokenwerte bereitzustellen.
<resources>
<style name="OemStyle">
<item name="com.android.oem.tokens:colorPrimary">#B0C5FF</item>
<item name="com.android.oem.tokens:colorOnPrimary">#002B76</item>
<item name="com.android.oem.tokens:colorPrimaryContainer">#003FA4</item>
<item name="com.android.oem.tokens:colorOnPrimaryContainer">#D9E2FF</item>
…
</style>
</resources>
RROs sollten die Attribute der gemeinsam genutzten Bibliothek für den Stil festlegen, indem sie den Namen der gemeinsam genutzten Bibliothek angeben.
Last zuletzt konfigurieren
Systeme, die eine OEM-Implementierung einer gemeinsam genutzten Token-Bibliothek enthalten, müssen das System so konfigurieren, dass die gemeinsam genutzte Bibliothek nach den App-Klassen geladen wird. Fügen Sie dazu den Bibliotheksnamen ( com.android.oem.tokens ) in die Konfiguration config_sharedLibrariesLoadedAfterApp auf dem System ein. Wenn Sie Zugriff auf Google Automotive Services (GAS) haben, ist dies eine Voraussetzung.
<!-- The OEM token shared library will be loaded after app classes -->
<string-array name="config_sharedLibrariesLoadedAfterApp" translatable="false">
<item>com.android.oem.tokens</item>
</string-array>
Empfohlene Vorgehensweise
Im Folgenden werden Best Practices für die OEM-Token-Bibliothek beschrieben.
Ermöglichen Sie eine flexible Update-Strategie
Sehen Sie sich die folgenden Strategien an, um sicherzustellen, dass Sie Flexibilität in Bezug auf Aktualisierungen einbauen.
Gemeinsam genutzte OEM-Bibliothek
Da vom System gemeinsam genutzte Bibliotheken auf Systemabbildern vorinstalliert werden müssen, müssen Geräte entweder mit der Bibliothek ausgeliefert werden oder die Bibliothek muss als Teil eines Over-the-Air-Updates (OTA) hinzugefügt werden (weitere Informationen finden Sie unter OTA-Updates ). Allerdings ermöglicht das Einfügen einer Stub-Implementierung einer OEM-Überschreibung einer gemeinsam genutzten OEM-Token-Bibliothek in ein System-Image, dass ein Update auf eine voll funktionsfähige Implementierung zu einem späteren Zeitpunkt auf Geräte übertragen werden kann, ohne dass ein OTA erforderlich ist.
Gemeinsam genutzte Bibliotheks-RROs
Obwohl es nicht erforderlich ist, dass RROs als System-Apps installiert werden, sorgt dies für ein gewisses Update-Verhalten, das möglicherweise gewünscht ist.
- Automatische Updates von Apps, wenn Benutzer nicht angemeldet sind.
- Kann vom Benutzer nicht deinstalliert werden (Benutzer können nur Updates deinstallieren ).