Les fabricants d'appareils Android modifient le code source des bibliothèques AOSP pour diverses raisons. Certains fournisseurs réimplémentent des fonctions dans les bibliothèques AOSP pour améliorer les performances tandis que d'autres fournisseurs ajoutent de nouveaux hooks, de nouvelles API ou de nouvelles fonctionnalités aux bibliothèques AOSP. Cette section fournit des instructions pour étendre les bibliothèques AOSP d'une manière qui ne rompt pas CTS / VTS.
Remplacement instantané
Toutes les bibliothèques partagées modifiées doivent être des remplacements compatibles binaires de leur homologue AOSP. Tous les utilisateurs AOSP existants doivent pouvoir utiliser la bibliothèque partagée modifiée sans recompilations. Cette exigence implique ce qui suit:
- Les fonctions AOSP ne doivent pas être supprimées.
- Les structures ne doivent pas être modifiées si ces structures sont exposées à leurs utilisateurs.
- La condition préalable des fonctions ne doit pas être renforcée.
- Les fonctions doivent fournir des fonctionnalités équivalentes.
- La post-condition des fonctions ne doit pas être affaiblie.
Classifications de modules étendues
Classez les modules selon les fonctionnalités qu'ils définissent et utilisent .
Remarque : Les fonctionnalités sont utilisées ici au lieu d'API / ABI car il est possible d'ajouter des fonctionnalités sans modifier aucune API / ABI.
En fonction des fonctionnalités définies dans un module, les modules peuvent être classés en DA-Module et DX-Module :
- Les modules AOSP de définition uniquement (module DA) ne définissent pas de nouvelles fonctionnalités qui n'étaient pas dans l'homologue AOSP.
- Exemple 1. Une bibliothèque AOSP non modifiée intacte est un module DA.
- Exemple 2. Si un fournisseur réécrit les fonctions dans
libcrypto.soavec des instructions SIMD (sans ajouter de nouvelles fonctions), alors lelibcrypto.somodifié sera un module DA.
- Les modules de définition d'extension (DX-Module) définissent de nouvelles fonctionnalités ou n'ont pas d'équivalent AOSP.
- Exemple 1. Si un fournisseur ajoute une fonction d'assistance à
libjpeg.sopour accéder à certaines données internes, alors lelibjpeg.somodifié sera un DX-Lib et la fonction nouvellement ajoutée sera la partie étendue de la bibliothèque. - Exemple 2. Si un fournisseur définit une bibliothèque non-AOSP nommée
libfoo.so, alorslibfoo.sosera une DX-Lib.
- Exemple 1. Si un fournisseur ajoute une fonction d'assistance à
Selon les fonctionnalités utilisées par un module, les modules peuvent être classés en UA-Module et UX-Module .
- Les modules utilisant uniquement AOSP (UA-Module) utilisent uniquement les fonctionnalités AOSP dans leurs implémentations. Ils ne reposent sur aucune extension non AOSP.
- Exemple 1. Une bibliothèque AOSP non modifiée intacte est un module UA.
- Exemple 2. Si une bibliothèque partagée modifiée
libjpeg.sone repose que sur d'autres API AOSP, alors ce sera un UA-Module.
- Les modules utilisant l'extension (UX-Module) s'appuient sur certaines fonctionnalités non AOSP dans leurs implémentations.
- Exemple 1. Si un
libjpeg.somodifié repose sur une autre bibliothèque non-AOSP nomméelibjpeg_turbo2.so, alors lelibjpeg.somodifié sera un module UX. - Exemple 2. Si un fournisseur ajoute une nouvelle fonction à son
libexif.somodifié et que sonlibjpeg.somodifié utilise la fonction nouvellement ajoutée delibexif.so, alors sonlibjpeg.somodifié sera un module UX.
- Exemple 1. Si un
Les définitions et les usages sont indépendants les uns des autres:
| Fonctionnalités utilisées | |||
|---|---|---|---|
| Uniquement AOSP (UA) | Étendu (UX) | ||
| Fonctionnalités définies | Uniquement AOSP (DA) | DAUA | DAUX |
| Étendu (DX) | DXUA | DXUX | |
Mécanisme d'extension VNDK
Les modules fournisseurs qui reposent sur des fonctionnalités étendues ne fonctionneront pas car la bibliothèque AOSP du même nom ne dispose pas de la fonctionnalité étendue. Si les modules du fournisseur dépendent directement ou indirectement de fonctionnalités étendues, les fournisseurs doivent copier les bibliothèques partagées DAUX, DXUA et DXUX sur la partition du fournisseur (les processus du fournisseur recherchent toujours les bibliothèques partagées dans la partition du fournisseur en premier). Cependant, les bibliothèques LL-NDK ne doivent pas être copiées, de sorte que les modules du fournisseur ne doivent pas s'appuyer sur les fonctionnalités étendues définies par les bibliothèques LL-NDK modifiées.
Les bibliothèques partagées DAUA peuvent rester sur la partition système si la bibliothèque AOSP correspondante peut fournir les mêmes fonctionnalités et les modules du fournisseur continuent de fonctionner lorsque la partition système est écrasée par une image système générique (GSI).
Le remplacement instantané est important car les bibliothèques VNDK non modifiées dans le GSI seront liées aux bibliothèques partagées modifiées en cas de collision de noms. Si les bibliothèques AOSP sont modifiées d'une manière incompatible API / ABI, les bibliothèques AOSP dans le GSI peuvent ne pas se lier ou entraîner des comportements non définis.