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 fournisseurs ajoutent de nouveaux hooks, de nouvelles API ou de nouvelles fonctionnalités aux bibliothèques AOSP. Cette section fournit des directives pour étendre les bibliothèques AOSP d'une manière qui ne brise pas CTS/VTS.

Remplacement immédiat

Toutes les bibliothèques partagées modifiées doivent être compatibles binaires et remplacer directement leur homologue AOSP. Tous les utilisateurs AOSP existants doivent pouvoir utiliser la bibliothèque partagée modifiée sans recompilation. Cette exigence implique ce qui suit :

  • Les fonctions AOSP ne doivent pas être supprimées.
  • Les structures ne doivent pas être modifiées si elles sont exposées à leurs utilisateurs.
  • Les conditions préalables aux fonctions ne doivent pas être renforcées.
  • Les fonctions doivent fournir des fonctionnalités équivalentes.
  • La post-condition des fonctions ne doit pas être affaiblie.

Classifications de modules étendus

Classer les modules selon les fonctionnalités qu'ils définissent et utilisent .

Remarque : Les fonctionnalités sont utilisées ici à la place 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 de définition uniquement AOSP (DA-Module) ne définissent pas de nouvelles fonctionnalités qui n'étaient pas dans l'homologue 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 de libcrypto.so avec des instructions SIMD (sans ajouter de nouvelles fonctions), alors 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 d'équivalent AOSP.
    • Exemple 1. Si un fournisseur ajoute une fonction d'assistance à libjpeg.so pour accéder à certaines données internes, alors le libjpeg.so modifié sera une 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 , alors libfoo.so sera une DX-Lib.

En fonction des fonctionnalités utilisées par un module, les modules peuvent être classés en UA-Module et UX-Module .

  • Les modules AOSP utilisant uniquement (UA-Module) utilisent uniquement les fonctionnalités AOSP dans leurs implémentations. Ils ne s'appuient sur aucune extension non-AOSP.
    • Exemple 1. Une bibliothèque AOSP intacte et non modifiée est un module UA.
    • Exemple 2. Si une bibliothèque partagée modifiée libjpeg.so repose uniquement sur d'autres API AOSP, alors ce sera un module UA.
  • Les modules d'extension d'utilisation (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 , alors 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 fonction nouvellement ajoutée de libexif.so , alors son libjpeg.so modifié sera un module UX.

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 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 fonctionnalités étendues. 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 en premier les bibliothèques partagées dans la partition du fournisseur). Cependant, les bibliothèques LL-NDK ne doivent pas être copiées, les modules du fournisseur ne doivent donc 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 immédiat 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 du GSI peuvent ne pas parvenir à se lier ou entraîner des comportements non définis.