La distribuzione del middleware creato con l'NDK solleva alcuni problemi aggiuntivi che gli sviluppatori di app non devono preoccuparsi. Le librerie precompilate impongono alcune delle loro scelte di implementazione agli utenti.
Scegliere i livelli API e le versioni NDK
I tuoi utenti non possono utilizzare un valore minSdkVersion inferiore al tuo. Se i tuoi utenti app devono essere eseguiti sull'API 21, non puoi creare per l'API 24. Puoi creare il tuo libreria per un livello API inferiore rispetto a quello dei tuoi utenti. Puoi creare contenuti per le API 16 e la compatibilità con gli utenti dell'API 21.
Le versioni NDK sono in gran parte compatibili tra loro, ma a volte vengono apportate modifiche che ne compromettono la compatibilità. Se sai che tutti i tuoi utenti utilizzano la stessa versione dell'NDK, è meglio utilizzare la stessa versione. In caso contrario, utilizza la versione più recente.
Utilizzo dell'STL
Se scrivi codice C++ e utilizzi STL, la scelta tra libc++_shared e
libc++_static influisce sugli utenti se distribuisci una libreria condivisa. Se
distribuire una libreria condivisa, devi usare libc++_shared o assicurarti che
I simboli di libc++ non sono esposti nella tua raccolta. Il modo migliore per farlo è
dichiarare esplicitamente la tua piattaforma ABI con uno script di versione.
Un'altra opzione meno efficace è quella di utilizzare -Wl,--exclude-libs,libc++_static.a
-Wl,--exclude-libs,libc++abi.a per il collegamento. Questo approccio è meno affidabile perché nasconde solo i simboli nelle librerie con nomi espliciti e non vengono generati report di diagnostica per le librerie non utilizzate (un errore ortografico nel nome della libreria non è un errore e spetta all'utente mantenere aggiornato l'elenco delle librerie). Inoltre, questo approccio non nasconde i dettagli della tua implementazione.
Distribuzione di librerie native nei AAR
Il plug-in Android per Gradle può importare dipendenze native distribuite AAR. Se i tuoi utenti utilizzano il plug-in Android Gradle, questa sarà la il modo più semplice per usare la tua raccolta.
Le librerie native possono essere pacchettizzate in un file AAR AGP. Questa sarà la è l'opzione più semplice se la libreria è già creata da external NativeBuild.
Le build non AGP possono utilizzare ndkports o eseguire il packaging manuale seguendo la documentazione di Prefab per creare la sottodirectory prefab/ dell'AAR.
middleware Java con librerie JNI
librerie Java che includono librerie JNI (in altre parole, AAR che contengono
jniLibs) devi prestare attenzione che le librerie JNI che includono non
sono in conflitto con altre librerie nell'app dell'utente. Ad esempio, se l'AAR include
libc++_shared.so, ma una versione di libc++_shared.so diversa da quella dell'app
ne verrà installata solo una, pertanto l'APK potrebbe
comportamento degli utenti.
La soluzione più affidabile è che le librerie Java non includano più di una
libreria JNI (questo è un buon consiglio anche per le app). Tutte le dipendenze, inclusa la biblioteca STL, devono essere collegate in modo statico alla libreria di implementazione e deve essere utilizzato uno script di versione per applicare l'interfaccia ABI. Ad esempio, una libreria Javacom.example.foo che include la libreria JNIlibfooimpl.so deve utilizzare il seguente script di versione:
LIBFOOIMPL {
global:
JNI_OnLoad;
local:
*;
};
Questo esempio utilizza registerNatives tramite JNI_OnLoad come descritto nei suggerimenti di JNI
per garantire che la superficie ABI minima sia esposta e che il tempo di caricamento della libreria sia
ridotto a icona.