À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Implémenter des polices personnalisées

À partir d'Android 15, les polices variables sont affichées au moment de l'exécution avec une efficacité et une précision accrues. Avec cette mise à jour, les fournisseurs doivent ajouter de nouvelles configurations de polices variables à font_fallback.xml au lieu de fonts.xml, car fonts.xml est obsolète. Pour en savoir plus, consultez Prise en charge des polices variables.

Dans Android 11 et les versions antérieures, la mise à jour des fichiers de police installés sur l'appareil dans AOSP (dans la partition /system/fonts) ou dans les partitions du fournisseur (dans les partitions /product/fonts ou /system/fonts) nécessite une mise à jour du système de l'OEM. Cette exigence a un impact significatif sur la compatibilité des emoji. Dans Android 12, vous pouvez utiliser le service système FontManager pour gérer les fichiers de police installés et mettre à jour les fichiers de police installés sur l'appareil sans mise à jour du système.

Android 12 propose trois interactions de processus : FontManagerService, Font Updater et Application.

FontManagerService est le système de gestion central du serveur système. FontManagerService stocke les derniers paramètres de police système par utilisateur.

FontUpdater est un programme de mise à jour de police enfichable qui est approuvé par une vérification des autorisations signature|privileged. FontUpdater communique avec FontManagerService pour obtenir, installer, supprimer ou mettre à jour les paramètres actuels de la police système. FontUpdater peut transmettre le contenu de nouveaux fichiers de police via des mécanismes de communication interprocessus (IPC). FontManagerService enregistre le contenu dans un emplacement de stockage accessible à tous, par exemple dans les fichiers /data/fonts. Cet espace de stockage est protégé. Il peut être écrit par la FontManagerService uniquement, par la règle SELinux.

Lorsque la classe Application est lancée, elle transmet les paramètres de police du système en tant qu'arguments de la méthode bindApplication, puis elle initialise les paramètres de police pour qu'ils soient utilisés par le processus de l'application.

Prise en charge des polices variables

À partir d'Android 15, les configurations de polices variables sont spécifiées dans font_fallback.xml au format suivant :

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

Dans ce format, une police variable possède tous les attributs d'une police statique, avec un attribut supportedAxes supplémentaire. Un attribut supportedAxes est une liste de tags d'axe compatibles séparés par une virgule. Avec Android 15, seuls les axes wght et ital peuvent être spécifiés.

Si l'attribut supportedAxes n'est pas spécifié, le nœud font fonctionne comme une police statique d'une seule instance d'une police variable spécifiée avec des enfants axis.

Si l'attribut supportedAxes est spécifié, le système crée dynamiquement une instance de police pour la valeur de style et de poids donnée au moment de l'exécution.

Les développeurs peuvent utiliser l'API Java android.graphics.fonts.SystemFonts#getAvailableFonts ou l'API NDK ASystemFontIterator_open pour obtenir la liste des fichiers de police installés sur le système. Pour en savoir plus sur les API pour les développeurs compatibles avec cette mise à jour, consultez API améliorée pour les polices variables OpenType et buildVariableFamily.

Personnaliser les polices

Certains OEM installent ou remplacent des fichiers de police dans AOSP pour afficher leur marque. Android 12 est compatible avec cette fonctionnalité, mais ajoute des exigences pour que les polices d'emoji soient à jour sur les appareils. Les OEM qui ne modifient ni ne mettent à jour les fichiers de police d'emoji n'ont pas besoin d'utiliser cette fonctionnalité.

Google met à jour les fichiers de police, en particulier les fichiers NotoColorEmoji, via GMS Core. Par conséquent, ne modifiez ni ne supprimez le fichier NotoColorEmoji.ttf de la partition /system, et ne le supprimez pas de /frameworks/base/data/fonts/fonts.xml. Notez que vous disposez de trois options pour personnaliser vos polices :

Remplacez le fichier NotoColorEmoji.ttf par une police d'emoji de marque OEM.
Modifiez le fichier NotoColorEmoji.ttf en fonction des besoins de votre marché local.
remplacer ou modifier d'autres fichiers de police ;

Si vous ne modifiez pas les polices d'emoji dans AOSP, aucune action n'est requise de votre part. Si vous souhaitez personnaliser les polices d'emoji, suivez les instructions des sections suivantes.

Remplacer NotoColorEmoji.ttf par des polices d'emoji de marque OEM

Pour remplacer le fichier NotoColorEmoji.ttf par votre fichier de polices d'emoji de marque OEM, placez la police d'emoji juste avant la chaîne de secours de police :

Placez votre propre police, appelée OEMCustomEmoji.ttf, dans la partition /system.

Modifiez /frameworks/base/data/fonts/fonts.xml (et /frameworks/base/data/fonts/font-fallback.xml dans Android 15 et versions ultérieures) comme dans le code suivant :

<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>

Modifier NotoColorEmoji.ttf pour répondre aux besoins du marché local

Pour personnaliser votre application en fonction des besoins de votre marché local, procédez comme suit :

Créez votre propre fichier NotoColorEmoji avec un nom différent (Modified\_NotoColorEmoji.ttf, par exemple).
Placez-le avant le fichier NotoColorEmoji.ttf d'origine.

Après l'étape 2, le glyphe modifié compatible avec Modified\NotoColorEmoji.ttf s'affiche à la place du glyphe d'origine NotoColorEmoji.ttf. Google recommande les pratiques suivantes :

ne comportent que le glyphe nécessaire.
Déléguez les glyphes non modifiés au fichier NotoColorEmoji.ttf d'origine afin que vos appareils reçoivent les corrections de conception apportées aux futures versions d'emoji.

Supprimer des glyphes : pour supprimer des glyphes du fichier NotoColorEmoji.ttf, suivez les étapes 1 et 2, et spécifiez glyph ID = 0 dans votre cmap.

Utilisez un flag de région : si le glyphe cible est un flag de région, spécifiez l'ID du glyphe comme code pays inconnu. (Utilisez country code = "ZZ".)

Créer un glyphe tofu : vous pouvez spécifier explicitement un ID de glyphe tofu si vous souhaitez en utiliser un. Lorsque vous spécifiez glyphID = 0, l'application associée interprète cela comme "le glyphe n'est pas disponible". Par exemple, lorsque vous utilisez cet attribut, l'application Paint#hasGlyph renvoie false.

Remplacer ou modifier d'autres fichiers de police

Pour remplacer ou modifier d'autres polices, la personnalisation est semblable à celle permettant de modifier les fichiers TTF pour les besoins du marché local. Les fichiers de police inconnus qui sont mis à jour dans l'AOSP au moment de l'exécution sont ignorés et ne sont pas mis à jour. Google ignore les polices inconnues sur votre appareil. Cela inclut les fichiers de police qui ont été modifiés à partir des polices d'origine dans AOSP.

Bien que les mises à jour des polices soient effectuées par Google dans GMS Core, le mécanisme général de mise à jour des polices est ouvert à tous les OEM. Les OEM peuvent installer des programmes de mise à jour de polices supplémentaires en suivant les étapes décrites dans Respecter les prérequis, Signer les fichiers de police et Effectuer des mises à jour de police au moment de l'exécution.

Respecter les conditions préalables

Le mécanisme de mise à jour des polices utilise la fonctionnalité fs-verity du noyau Linux. Vérifiez que votre appareil est conforme à la norme fs-verity et incluez le certificat dans votre appareil.

Signer des fichiers de police

Les fichiers de police étant des ressources à risque, ils doivent être validés avec des clés fiables. Examinez attentivement tous les fichiers de police à mettre à jour, puis signez-les avec votre clé privée. La signature doit être compatible avec fs-verity.

Mettre à jour les polices au moment de l'exécution

L'application système FontManager effectue les mises à jour des polices. L'application FontManager fournit l'état de la dernière police système installée et permet de mettre à jour les fichiers de police avec des signatures. Pour appeler les applications de mise à jour, ajoutez l'autorisation UPDATE_FONT signature|privileged à votre liste d'autorisation des applications et à votre fichier manifeste.

Accordez l'autorisation UPDATE_FONT signature|privileged à la fonction de mise à jour de votre application.