Extensions VNDK

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 ajoutent de nouveaux hooks, de nouvelles API ou de nouvelles fonctionnalités aux bibliothèques AOSP. Cette section fournit des consignes pour étendre les bibliothèques AOSP sans endommager CTS/VTS.

Remplacement par insertion

Toutes les bibliothèques partagées modifiées doivent être compatibles avec les binaires et remplacées par leur homologue AOSP. Tous les utilisateurs AOSP existants doivent pouvoir utiliser la bibliothèque partagée modifiée sans recompilation. Cette exigence implique les éléments suivants:

  • Les fonctions AOSP ne doivent pas être supprimées.
  • Les structures ne doivent pas être modifiées si elles 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 postcondition des fonctions ne doit pas être affaiblie.

Classifications de modules étendues

Classez les modules en fonction des fonctionnalités qu'ils définissent et utilisent.

Remarque: Le terme fonctionnalités est utilisé ici au lieu d'API/ABI, car il est possible d'ajouter des fonctionnalités sans modifier d'API/ABI.

Selon les fonctionnalités définies dans un module, les modules peuvent être classés en modules DA et modules DX:

  • Les modules DA (Defining-only-AOSP Module) ne définissent pas de nouvelles fonctionnalités qui n'étaient pas présentes dans le module AOSP.
    • Exemple 1 Une bibliothèque AOSP intacte et non modifiée est un module DA.
    • Exemple 2 Si un fournisseur réécrit les fonctions dans libcrypto.so avec des instructions SIMD (sans ajouter de nouvelles fonctions), le libcrypto.so modifié sera un module DA.
  • Les modules d'extension de définition (DX-Module) définissent de nouvelles fonctionnalités ou n'ont pas de contrepartie AOSP.
    • Exemple 1 Si un fournisseur ajoute une fonction d'assistance à libjpeg.so pour accéder à certaines données internes, libjpeg.so modifié sera une bibliothèque DX 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, libfoo.so sera une bibliothèque DX.

Selon les fonctionnalités utilisées par un module, il peut être classé en tant que module UA ou module UX.

  • Les modules utilisant uniquement AOSP (UA-Module) n'utilisent que les fonctionnalités AOSP dans leurs implémentations. Elles ne reposent sur aucune extension autre qu'AOSP.
    • Exemple 1 Une bibliothèque AOSP intacte et non modifiée est un module UA.
    • Exemple 2 Si une bibliothèque partagée libjpeg.so modifiée ne repose que sur d'autres API AOSP, il s'agit d'un module UA.
  • Les modules d'utilisation d'extensions (UX-Module) s'appuient sur certaines fonctionnalités non AOSP dans leurs implémentations.
    • Exemple 1 Si un libjpeg.so modifié repose sur une autre bibliothèque non AOSP nommée libjpeg_turbo2.so, le libjpeg.so modifié sera un module UX.
    • Exemple 2 Si un fournisseur ajoute une nouvelle fonction à son libexif.so modifié et que son libjpeg.so modifié utilise la nouvelle fonction ajoutée à partir de libexif.so, son libjpeg.so modifié sera un module UX.

Les définitions et les utilisations sont indépendantes les unes des autres:

Fonctionnalités utilisées
Uniquement AOSP (UA) Étendue (UX)
Fonctionnalités définies Uniquement AOSP (DA) DAUA DAUX
Étendu (DX) DXUA DXUX

Mécanisme d'extension VNDK

Les modules du fournisseur qui s'appuient sur des fonctionnalités étendues ne fonctionneront pas, car la bibliothèque AOSP du même nom ne dispose pas de ces fonctionnalités. 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 dans la partition du fournisseur (les processus du fournisseur recherchent toujours d'abord les bibliothèques partagées dans la partition du fournisseur). Toutefois, les bibliothèques LL-NDK ne doivent pas être copiées. Par conséquent, 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 que 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 par glisser-déposer est important, car les bibliothèques VNDK non modifiées du GSI s'associeront aux bibliothèques partagées modifiées en cas de collision de noms. Si les bibliothèques AOSP sont modifiées de manière incompatible avec l'API/ABI, l'association des bibliothèques AOSP dans le GSI peut échouer ou entraîner des comportements non définis.