カスタムフォントを実装する

Android 15 以降では、可変フォントの実行時のレンダリングの効率性と粒度が改善しています。このアップデートにより、ベンダーは新しい可変フォント構成を fonts.xml ではなく font_fallback.xml に追加する必要があります。fonts.xml は非推奨となります。詳しくは、可変フォントのサポートをご参照ください

Android 11 以前のバージョンでは、AOSP（/system/fonts パーティション内）またはベンダーパーティション（/product/fonts パーティションまたは /system/fonts パーティション内）でデバイスにインストールされているフォントファイルを更新するには、OEM によるシステムアップデートが必要でした。この要件は絵文字の互換性に大きな影響を与えます。Android 12 では、FontManager システムサービスを使用することで、インストール済みのフォントファイルを管理し、システムアップデートを行わずにデバイスにインストールされているフォントファイルを更新できます。

Android 12 には、FontManagerService、Font Updater、Application の 3 つのプロセスインタラクションがあります。

FontManagerService は、システムサーバー内の集中管理システムです。FontManagerService には、ユーザーごとの最新のシステムフォント設定が格納されます。

FontUpdater は、signature|privileged 権限チェックによって信頼される、プラグイン可能なフォントアップデータです。FontUpdater は FontManagerService と通信して、現在のシステムフォント設定を取得、インストール、削除、更新します。FontUpdater は、プロセス間通信（IPC）メカニズムを使用して新しいフォントファイルのコンテンツを渡すことができます。FontManagerService は、/data/fonts ファイルなど、誰でも読み取れるストレージにコンテンツを保存します。このストレージは保護されます。SELinux ポリシーの制約により、FontManagerService のみがこのストレージに書き込みを行えます。

Application クラスは、起動時にシステムフォント設定を bindApplication メソッドの引数として渡します。その後、フォント設定を初期化し、アプリプロセスで使用できるようにします。

可変フォントのサポート

Android 15 以降では、可変フォント構成は次の形式を使って font_fallback.xml で指定されます。

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

この形式では、可変フォントには静的フォントのすべての属性に加え、追加の supportedAxes 属性が含まれています。supportedAxes 属性はサポートされている軸タグのカンマ区切りのリストです。Android 15 では wght 軸と ital 軸のみ指定できます。

supportedAxes 属性が指定されていない場合、font ノードは axis の子で指定された可変フォントの単一インスタンスの静的フォントして機能します。

supportedAxes 属性が指定されている場合、実行時にシステムは動的に指定された太さとスタイル値のフォントインスタンスを作成します。

デベロッパーは android.graphics.fonts.SystemFonts#getAvailableFonts Java API または ASystemFontIterator_open NDK API を使用して、システムにインストールされたフォントファイルのリストを取得できます。このアップデートをサポートするデベロッパー向け API について詳細は、OpenType 可変フォント API の改善と buildVariableFamily をご覧ください。

フォントをカスタマイズする

一部の OEM は、自社のブランドを表現するために AOSP でフォントファイルをインストールまたは置換します。Android 12 はこの機能をサポートしていますが、デバイスで絵文字フォントを更新するための要件が追加されています。絵文字フォントファイルの変更や更新を行わない OEM の場合、この機能を使用する必要はありません。

フォントファイル、特に NotoColorEmoji ファイルの更新は GMS Core を介して Google が行います。/system パーティションの NotoColorEmoji.ttf ファイルの変更や削除は行わないでください。また、/frameworks/base/data/fonts/fonts.xml から同ファイルを削除しないでください。フォントをカスタマイズする方法は 3 つあります。

NotoColorEmoji.ttf ファイルを OEM ブランドの絵文字フォントに置き換える。
地域のニーズに応じて NotoColorEmoji.ttf ファイルを変更する。
他のフォントファイルを置換または変更する。

AOSP で絵文字フォントを変更していない場合は、何もする必要はありません。絵文字フォントをカスタマイズする場合は、この後のセクションの手順を行ってください。

NotoColorEmoji.ttf を OEM ブランドの絵文字フォントに置き換える

NotoColorEmoji.ttf ファイルを OEM ブランドの絵文字フォントファイルに置き換えるには、フォントの代替チェーンの直前に絵文字フォントを配置します。

独自のフォント（OEMCustomEmoji.ttf）を /system パーティションに配置します。

/frameworks/base/data/fonts/fonts.xml（Android 15 以降では /frameworks/base/data/fonts/font-fallback.xml）を以下のコードに沿って修正します。

<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 を変更する

次の手順に沿って、地域市場のニーズに合わせてカスタマイズします。

別の名前（Modified\_NotoColorEmoji.ttf など）で独自の NotoColorEmoji ファイルを作成します。
元の NotoColorEmoji.ttf ファイルの前に配置してください。

ステップ 2 を実行すると、元の NotoColorEmoji.ttf の代わりに、Modified\NotoColorEmoji.ttf でサポートされている修正されたグリフが表示されます。Google では次のことをおすすめします。

このフォントには必要なグリフのみを含めます。
修正されていないグリフを元の NotoColorEmoji.ttf ファイルに委任して、デバイスが今後の絵文字リリースでデザインの修正を受けられるようにします。

グリフを削除する: NotoColorEmoji.ttf ファイルからグリフを削除するには、ステップ 1 と 2 に沿って、cmap で glyph ID = 0 を指定します。

リージョンフラグを使用する: ターゲットグリフがリージョンフラグの場合は、グリフ ID を不明な国コードとして指定します（country code = "ZZ" を使用します）

トウフグリフを作成する: トウフグリフを使用する場合、そのグリフの ID を明示的に指定できます。glyphID = 0 を指定すると、関連付けられているアプリは「グリフが利用できない」と解釈します。たとえば、この属性を使用すると、Paint#hasGlyph アプリは false を返します。

他のフォントファイルを置換または変更する

他のフォントを置き換えるか変更する場合、カスタマイズの方法は、地域市場のニーズに応じて TTF ファイルを変更する場合と同様です。実行時に AOSP で更新された不明なフォントファイルは無視され、更新されません。デバイス内の不明なフォントは Google によって無視されます。これには、AOSP で元のフォントから変更されたフォントファイルが含まれます。

フォントの更新は Google により GMS Core で行われますが、一般的なフォントの更新メカニズムはすべての OEM が利用できます。OEM は、前提条件を満たす、フォントファイルに署名する、ランタイムでフォントを更新するの手順に沿って、追加のフォントアップデータをインストールできます。

前提条件を満たす

フォントの更新メカニズムでは、fs-verity Linux カーネル機能を使用します。デバイスが fs-verity に準拠していることを確認し、デバイスに証明書を含めます。

フォントファイルに署名する

フォントファイルはリスクのあるリソースであるため、信頼されたキーで検証する必要があります。更新するすべてのフォントファイルを慎重に確認し、秘密鍵で署名します。署名は fs-verity と互換性がある必要があります。

ランタイムでフォントを更新する

FontManager システムアプリがフォントの更新を行います。FontManager アプリは、インストールされた最新のシステムのフォントステータスを提供し、署名付きでフォントファイルを更新できます。更新アプリを呼び出すには、アプリの許可リストとマニフェストに UPDATE_FONT signature|privileged 権限を追加します。

アプリの更新機能に UPDATE_FONT signature|privileged 権限を付与します。