Extensions VNDK

Les fabricants d'appareils Android modifient le code source des bibliothèques AOSP pour pour diverses raisons. Certains fournisseurs réimplémentent les fonctions dans les bibliothèques AOSP pour d'améliorer les performances tandis que les autres fournisseurs ajoutent de nouveaux hooks, de nouvelles API les fonctionnalités des bibliothèques AOSP. Cette section fournit des consignes étendant les bibliothèques AOSP d'une manière qui n'affecte pas CTS/VTS.

Remplacement par dépôt direct

Toutes les bibliothèques partagées modifiées doivent être compatibles avec le système binaire. de remplacement de leur homologue AOSP. Toutes les valeurs existantes Les utilisateurs AOSP doivent pouvoir utiliser la bibliothèque partagée modifiée sans les recompositions. 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 condition post-condition des fonctions ne doit pas être affaiblie.

Classifications de modules étendus

classer les modules en fonction des fonctionnalités qu'ils définissent et utiliser.

Remarque: Les fonctionnalités sont utilisées ici. au lieu de l'API/de l'ABI, car il est possible d'ajouter des fonctionnalités sans modifier n'importe quelle API/ABI.

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

  • Defining-only-AOSP Modules (DA-Module) ne définissent pas de nouvelles qui ne faisaient pas partie de l'équivalent AOSP.
    • Exemple 1. Une bibliothèque AOSP intacte et non modifiée est une DA-Module.
    • Exemple 2. Si un fournisseur réécrit les fonctions dans libcrypto.so avec des instructions SIMD (sans en ajouter de nouveaux) ), le libcrypto.so modifié sera un DA-Module.
  • Defining-Extension modules (DX-Module) définit soit 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, la classe modifiée libjpeg.so 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, puis libfoo.so sera une DX-Lib.

Selon les fonctionnalités utilisées par un module, les modules peuvent être classés dans UA-Module et UX-Module.

  • Utiliser des modules AOSP uniquement (UA-Module) n'utilisent que les fonctionnalités AOSP dans leurs implémentations. Elles ne s'appuient sur aucune extension autre qu'AOSP.
    • Exemple 1. Une bibliothèque AOSP intacte et non modifiée est une UA-Module".
    • Exemple 2. Si une bibliothèque partagée modifiée libjpeg.so repose uniquement sur d'autres API AOSP, il s'agira alors d'un UA-Module.
  • Utiliser des modules d'extension (UX-Module) s'appuie sur des modules n'appartenant pas à 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 et son libjpeg.so modifié utilisent le fonction libexif.so récemment ajoutée, son état modifié libjpeg.so sera un module UX.

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

Fonctionnalités utilisées
AOSP uniquement (UA) Extension (UX)
Fonctionnalités définies AOSP uniquement (DA) Annonces dynamiques du Réseau de Recherche (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 le La bibliothèque AOSP portant le même nom ne dispose pas des fonctionnalités étendues. Si les modules des fournisseurs dépendent directement ou indirectement des fonctionnalités étendues, les fournisseurs doivent copier les bibliothèques partagées DAUX, DXUA et DXUX vers le fournisseur ; partition (les processus du fournisseur recherchent toujours les bibliothèques partagées du fournisseur partitionner en premier). Toutefois, les bibliothèques LL-NDK ne doivent pas être copiées. les modules ne doivent pas utiliser les fonctionnalités étendues définies par le LL-NDK.

Les bibliothèques partagées DAUA peuvent rester sur la partition du système si les la bibliothèque AOSP correspondante peuvent fournir les mêmes fonctionnalités et le même fournisseur les modules continuent de fonctionner lorsque la partition système est écrasée par un Image système (GSI).

Le remplacement direct est important, car les bibliothèques VNDK non modifiées dans le GSI sera lié aux bibliothèques partagées modifiées en cas de collision de noms. Si le Les bibliothèques AOSP sont modifiées d'une manière incompatible avec l'API/l'ABI, l'AOSP les bibliothèques de GSI peuvent échouer à s'associer ou entraîner des comportements non définis.