Benutzerdefinierte Schriftarten implementieren

Ab Android 15 werden variable Schriftarten zur Laufzeit effizienter und detaillierter gerendert. Nach diesem Update müssen Anbieter font_fallback.xml statt fonts.xml neue Konfigurationen für variable Schriftarten hinzufügen, da fonts.xml eingestellt wird. Weitere Informationen finden Sie unter Unterstützung für variable Schriftarten.

Unter Android 11 und niedriger ist für die Aktualisierung der auf dem Gerät installierten Schriftartdateien in AOSP (in der Partition /system/fonts) oder in den Anbieterpartitionen (in den Partitionen /product/fonts oder /system/fonts) ein Systemupdate des OEM erforderlich. Diese Anforderung hat erhebliche Auswirkungen auf die Emoji-Kompatibilität. In Android 12 können Sie den Systemdienst FontManager verwenden, um installierte Schriftdateien zu verwalten und auf dem Gerät installierte Schriftdateien ohne Systemupdate zu aktualisieren.

Android 12 bietet drei Prozessinteraktionen: FontManagerService, Font Updater und Application.

FontManagerService ist das zentrale Verwaltungssystem auf dem Systemserver. FontManagerService speichert die neuesten Systemschrifteinstellungen pro Nutzer.

FontUpdater ist ein austauschbarer Schriftart-Updater, dem eine signature|privileged-Berechtigungsprüfung als vertrauenswürdig einstuft. FontUpdater kommuniziert mit dem FontManagerService, um die aktuellen Einstellungen für Systemschriftarten abzurufen, zu installieren, zu entfernen oder zu aktualisieren. Die FontUpdater kann neue Inhalte der Schriftartdatei mithilfe von IPC-Mechanismen (Inter-Process Communication) übergeben. Die FontManagerService speichert den Inhalt an einem für alle lesbaren Speicherort, z. B. in den /data/fonts-Dateien. Dieser Speicher wird geschützt. Sie kann nur von der FontManagerService-Richtlinie in der SELinux-Richtlinie geschrieben werden.

Wenn die Application-Klasse gestartet wird, werden die Systemschrifteinstellungen als Argumente der bindApplication-Methode übergeben. Anschließend werden die Schrifteinstellungen für die Verwendung durch den App-Prozess initialisiert.

Unterstützung für variable Schriftarten

Ab Android 15 werden Konfigurationen für variable Schriftarten in font_fallback.xml im folgenden Format angegeben:

<family lang="und-Ethi" supportedAxes="wght,ital">
    <font>NotoSansEthiopic-VF.ttf</font>
</family>

In diesem Format hat eine variable Schrift alle Attribute einer statischen Schrift mit einem zusätzlichen supportedAxes-Attribut. Ein supportedAxes-Attribut ist eine durch Kommas getrennte Liste unterstützter Achsen-Tags. Unter Android 15 können nur die Achsen wght und ital angegeben werden.

Wenn das supportedAxes-Attribut nicht angegeben ist, dient der font-Knoten als statischer Schriftschnitt einer einzelnen Instanz einer variablen Schrift, die mit axis-Untergeordneten angegeben ist.

Wenn das Attribut supportedAxes angegeben ist, erstellt das System zur Laufzeit dynamisch eine Schriftinstanz für den angegebenen Schriftstärken- und Stilwert.

Hinweis: Damit Apps, die bisher fonts.xml direkt verwenden, weiterhin unterstützt werden, müssen Änderungen an font_fallback.xml auch an fonts.xml vorgenommen werden. Aus Gründen der Kompatibilität der Anwendungen wird die Syntax supportedAxes jedoch in der Legacy-Datei fonts.xml nicht unterstützt. Informationen zur unterstützten Syntax finden Sie in den Codekommentaren zu fonts.xml und font_fallback.xml.

Entwickler können die android.graphics.fonts.SystemFonts#getAvailableFonts-Java API oder die ASystemFontIterator_open-NDK API verwenden, um eine Liste der vom System installierten Schriftdateien abzurufen. Informationen zu Entwickler-APIs, die dieses Update unterstützen, finden Sie unter Verbesserte OpenType Variable Font API und buildVariableFamily.

Schriftarten anpassen

Einige OEMs installieren oder ersetzen Schriftdateien in AOSP, um ihre Marken zu präsentieren. Android 12 unterstützt diese Funktion, es müssen jedoch zusätzliche Anforderungen an die Aktualisierung der Emoji-Schriftarten auf den Geräten gelten. OEMs, die Emoji-Schriftartdateien nicht ändern oder aktualisieren, müssen diese Funktion nicht verwenden.

Google aktualisiert die Schriftdateien, insbesondere die NotoColorEmoji-Dateien, über GMS Core. Ändern oder entfernen Sie die NotoColorEmoji.ttf-Datei daher nicht aus der Partition /system und auch nicht aus /frameworks/base/data/fonts/fonts.xml. Es gibt drei Möglichkeiten, wie Sie Ihre Schriftarten anpassen können:

1. Ersetzen Sie die Datei NotoColorEmoji.ttf durch eine Emoji-Schriftart mit OEM-Markenbezug.
2. Passen Sie die Datei NotoColorEmoji.ttf an Ihre lokalen Marktanforderungen an.
3. Ersetzen oder ändern Sie andere Schriftartdateien.

Wenn Sie keine Emoji-Schriftarten in AOSP ändern, müssen Sie nichts unternehmen. Wenn Sie die Emoji-Schriftarten anpassen möchten, folgen Sie der Anleitung in den folgenden Abschnitten.

NotoColorEmoji.ttf durch Emoji-Schriftarten des OEMs ersetzen

Wenn Sie die Datei NotoColorEmoji.ttf durch Ihre Emoji-Schriftartdatei mit OEM-Marke ersetzen möchten, platzieren Sie die Emoji-Schriftart direkt vor der Schriftarten-Fallback-Kette:

1. Fügen Sie Ihre eigene Schriftart mit dem Namen OEMCustomEmoji.ttf in die Partition /system ein.

2. Ändern Sie /frameworks/base/data/fonts/fonts.xml (und /frameworks/base/data/fonts/font-fallback.xml in Android 15 und höher) wie im folgenden Code:

   <family lang="ko">
   <font weight="400" style="normal" index="1">NotoSansCJK-Regular.ttc</font>
   </family>
   <!-- ADD FOLLOWING LINE -->
   <family lang="und-Zsye">
      <font weight="400" style="normal">OEMCustomEmoji.ttf</font>
   </family>
   <!-- END OF MODIFICATION -->
   <family lang="und-Zsye">
      <font weight="400" style="normal">NotoColorEmoji.ttf</font>
   </family>
   <family lang="und-Zsym">
      <font weight="400" style="normal">NotoSansSymbols-Regular-Subsetted2.ttf</font>
   </family>
   

NotoColorEmoji.ttf für lokale Märkte anpassen

Führen Sie die folgenden Schritte aus, um sie an Ihre lokalen Märkte anzupassen:

1. Erstellen Sie eine eigene NotoColorEmoji-Datei mit einem anderen Namen, z. B. Modified\_NotoColorEmoji.ttf.
2. Platzieren Sie sie vor der ursprünglichen NotoColorEmoji.ttf-Datei.

Nachdem Sie Schritt 2 ausgeführt haben, wird das von Modified\NotoColorEmoji.ttf unterstützte geänderte Symbol anstelle des ursprünglichen NotoColorEmoji.ttf angezeigt. Google empfiehlt Folgendes:

• Nur das erforderliche Zeichen in dieser Schriftart haben.
• Delegieren Sie unveränderte Glyphen an die ursprüngliche NotoColorEmoji.ttf-Datei, damit Ihre Geräte alle Designkorrekturen erhalten, die in zukünftigen Emoji-Versionen vorgenommen werden.

Glyphen entfernen:Wenn Sie Glyphen aus der Datei NotoColorEmoji.ttf entfernen möchten, führen Sie die Schritte 1 und 2 aus und geben Sie glyph ID = 0 in Ihrer KML-Datei an.

Regionales Flag verwenden:Wenn das Zielsymbol ein regionales Flag ist, geben Sie die Glyphen-ID als unbekannten Ländercode an. (Verwenden Sie country code = "ZZ".)

Tofu-Glyphe erstellen:Sie können explizit eine Tofu-Glyphen-ID angeben, wenn Sie eine verwenden möchten. Wenn Sie glyphID = 0 angeben, wird dies von der entsprechenden App als „Glyph ist nicht verfügbar“ interpretiert. Wenn Sie dieses Attribut beispielsweise verwenden, gibt die Paint#hasGlyph-App false zurück.

Andere Schriftdateien ersetzen oder ändern

Um andere Schriftarten zu ersetzen oder zu ändern, erfolgt die Anpassung ähnlich wie die Anpassung der TTF-Dateien an die lokalen Marktanforderungen. Unbekannte Schriftdateien, die während der Laufzeit im AOSP aktualisiert werden, werden ignoriert und nicht aktualisiert. Google ignoriert unbekannte Schriftarten auf Ihrem Gerät. Dazu gehören auch Schriftdateien, die aus den ursprünglichen Schriftarten in AOSP geändert wurden.

Die Aktualisierung der Schriftarten wird zwar von Google in GMS Core vorgenommen, der allgemeine Mechanismus für die Aktualisierung von Schriftarten steht jedoch allen OEMs zur Verfügung. OEMs können zusätzliche Schriftart-Aktualisierungsprogramme installieren. Folgen Sie dazu der Anleitung unter Voraussetzungen erfüllen, Schriftdateien signieren und Schriftarten in der Laufzeit aktualisieren.

Voraussetzungen für Meet

Der Mechanismus zum Aktualisieren von Schriftarten verwendet die fs-verity-Funktion des Linux-Kernels. Prüfen Sie, ob Ihr Gerät fs-verity-konform ist, und fügen Sie das Zertifikat auf Ihrem Gerät hinzu.

Schriftartendateien für Unterschriften

Da Schriftartdateien riskante Ressourcen sind, müssen sie mit vertrauenswürdigen Schlüsseln verifiziert werden. Prüfen Sie alle Schriftdateien, die aktualisiert werden sollen, sorgfältig und signieren Sie sie mit Ihrem privaten Schlüssel. Die Signatur muss mit fs-verity kompatibel sein.

Schriftart für Laufzeit aktualisieren

Die FontManager-System-App aktualisiert die Schriftarten. Die FontManager App bietet den Status des aktuell installierten Systemschriftzugs und die Möglichkeit, Schriftdateien mit Signaturen zu aktualisieren. Wenn Sie Apps aktualisieren möchten, fügen Sie die Berechtigung UPDATE_FONT signature|privileged Ihrer Zulassungsliste für Apps und Ihrem Manifest hinzu.

Gewähren Sie der Aktualisierungsfunktion Ihrer App die Berechtigung UPDATE_FONT signature|privileged.