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 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.so avec des instructions SIMD (sans ajouter de nouvelles fonctions), alors le libcrypto.so modifié 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.so pour accéder à certaines données internes, alors le libjpeg.so modifié 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 , alors libfoo.so sera une DX-Lib.

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.so ne 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.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 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.