Implementieren von Fallback für benutzerdefinierte Schriftarten

In Android 11 und niedriger erfordert das Aktualisieren von auf dem Gerät installierten Schriftartdateien in AOSP (in der /system/fonts -Partition) oder den Herstellerpartitionen (in den /product/fonts oder /system/fonts -Partitionen) ein Systemupdate vom OEM. Diese Anforderung hat erhebliche Auswirkungen auf die Emoji-Kompatibilität. In Android 12 können Sie den FontManager -Systemdienst verwenden, um installierte Schriftartdateien zu verwalten und auf dem Gerät installierte Schriftartdateien ohne Systemaktualisierung zu aktualisieren.

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

Der FontManagerService ist das zentrale Verwaltungssystem im Systemserver. FontManagerService speichert die neuesten Systemschrifteinstellungen pro Benutzer.

Der FontUpdater ist ein Plug-in-Font-Updater, dem eine signature|privileged Berechtigungsprüfung vertraut. Der FontUpdater kommuniziert mit dem FontManagerService , um aktuelle Systemschrifteinstellungen abzurufen, zu installieren, zu entfernen oder zu aktualisieren. Der FontUpdater kann neue Schriftartdateiinhalte durch Interprozesskommunikations-(IPC)-Mechanismen übergeben. Der FontManagerService speichert die Inhalte an einem weltweit lesbaren Speicherort, wie beispielsweise in den Dateien /data/fonts . Dieser Speicher wird bewacht. Es kann nur vom FontManagerService nach der SELinux-Richtlinie geschrieben werden.

Wenn die Application -Klasse gestartet wird, übergibt sie die Systemschrifteinstellungen als Argumente an die bindApplication Methode; dann initialisiert es die Schrifteinstellungen zur Verwendung durch den Anwendungsprozess.

Implementieren benutzerdefinierter Schriftarten

Einige OEMs installieren oder ersetzen Schriftdateien in AOSP, um ihre Marken anzuzeigen. Android 12 unterstützt diese Funktion, fügt jedoch Anforderungen hinzu, um Emoji-Schriftarten auf Geräten auf dem neuesten Stand zu halten. OEMs, die Emoji-Schriftartdateien nicht ändern oder aktualisieren, müssen diese Funktion nicht verwenden.

Google aktualisiert die Schriftartdateien, insbesondere die NotoColorEmoji Dateien über GMS Core, also ändern oder entfernen Sie die NotoColorEmoji.ttf -Datei nicht von der /system Partition und entfernen Sie sie nicht aus /system/etc/fonts.xml . Beachten Sie die folgenden drei Möglichkeiten, wie Sie Ihre Schriftarten anpassen können:

  1. Ersetzen Sie die NotoColorEmoji.ttf -Datei durch eine OEM-Emoji-Schriftart.
  2. Passen Sie die Datei NotoColorEmoji.ttf an die Anforderungen Ihres lokalen Marktes an.
  3. Ersetzen oder ändern Sie andere Schriftartdateien.

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

Ersetzen von NotoColorEmoji.ttf durch OEM-Emoji-Schriftarten

Um die Datei NotoColorEmoji.ttf durch Ihre Emoji-Schriftartendatei mit OEM-Marke zu ersetzen, platzieren Sie die Emoji-Schriftart direkt vor der Font-Fallback-Kette:

  1. Platzieren Sie Ihre eigene Schriftart mit dem Namen OEMCustomEmoji.ttf in der /system -Partition.
  2. /system/etc/fonts.xml 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>
    

Anpassung von NotoColorEmoji.ttf an lokale Marktanforderungen

Befolgen Sie diese Schritte, um sie an Ihre lokalen Marktanforderungen anzupassen:

  1. Erstellen Sie Ihre eigene NotoColorEmoji -Datei mit einem anderen Namen; nennen Sie es beispielsweise Modified\_NotoColorEmoji.ttf .
  2. Platzieren Sie es vor der ursprünglichen NotoColorEmoji.ttf -Datei.

Nachdem Sie Schritt 2 ausgeführt haben, wird die geänderte Glyphe, die von Modified\NotoColorEmoji.ttf unterstützt wird, anstelle der ursprünglichen NotoColorEmoji.ttf . Google empfiehlt Folgendes:

  • Haben Sie nur die notwendige Glyphe in dieser Schriftart.
  • 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: Um Glyphen aus der Datei NotoColorEmoji.ttf zu entfernen, befolgen Sie die Schritte 1 und 2 und geben Sie in Ihrer cmap die glyph ID = 0 an.

Verwenden Sie eine regionale Flagge: Wenn die Zielglyphe eine regionale Flagge 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-Glyphe-ID angeben, wenn Sie eine verwenden möchten. Wenn Sie glyphID = 0 angeben, interpretiert die zugehörige App dies als „Glyphe ist nicht verfügbar“. Wenn Sie beispielsweise dieses Attribut verwenden, gibt die Paint#hasGlyph App false zurück.

Ersetzen oder ändern Sie andere Schriftartdateien

Um andere Schriftarten zu ersetzen oder zu modifizieren, ist die Anpassung ähnlich wie beim Modifizieren der tff Dateien für lokale Marktanforderungen. Unbekannte Schriftartdateien, die zur Laufzeit im AOSP aktualisiert werden, werden ignoriert und nicht aktualisiert. Google ignoriert unbekannte Schriftarten auf Ihrem Gerät. Dazu gehören Schriftartdateien, die von den ursprünglichen Schriftarten in AOSP geändert wurden.

Obwohl Schriftaktualisierungen von Google in GMS Core durchgeführt werden, steht der allgemeine Schriftaktualisierungsmechanismus allen OEMs offen. OEMs können zusätzliche Schriftartaktualisierungen installieren, indem sie die Schritte in Erfüllen der Voraussetzungen , Signieren von Schriftartdateien und Durchführen von Runtime-Schriftartaktualisierungen ausführen.

Voraussetzungen erfüllen

Der Schriftartaktualisierungsmechanismus verwendet die fs-verity Linux-Kernel-Funktion. Stellen Sie sicher, dass Ihr Gerät fs-verity konform ist, und schließen Sie das Zertifikat in Ihr Gerät ein.

Schriftdateien signieren

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

Runtime-Font-Updates vornehmen

Die FontManger System-App führt Schriftartaktualisierungen durch. Die FontManager App bietet den neuesten Status der installierten Systemschriften und die Möglichkeit, Schriftdateien mit Signaturen zu aktualisieren. Um Update-Apps aufzurufen, fügen Sie die UPDATE_FONT signature|privileged Berechtigung zu Ihrer App-Zulassungsliste und zu Ihrem Manifest hinzu.

Stellen Sie die UPDATE_FONT signature|privileged Berechtigung für die Updater-Funktion Ihrer App bereit.