In questa pagina vengono descritte le proprietà e le opzioni necessarie per preparare il tuo progetto della libreria Android per la pubblicazione utilizzando il plug-in Android Gradle (AGP). Anche se hai impostato alcune di queste proprietà prima di creare la libreria, consulta le seguenti indicazioni per ottimizzare le impostazioni.
Scegli uno spazio dei nomi
Le librerie Android devono dichiarare uno spazio dei nomi per poter generare una classe R
univoca quando le loro risorse vengono compilate. Questo spazio dei nomi deve corrispondere esattamente al pacchetto della classe principale della libreria per evitare confusione quando gli utenti importano classi normali dalla libreria e dalla relativa classe R
.
A partire da AGP 7.0, puoi impostare lo spazio dei nomi nel file build.gradle
dell'app, come mostrato nell'esempio di codice seguente:
trendy
android { namespace = 'com.example.library' }
Kotlin
android { namespace = "com.example.library" }
Lo spazio dei nomi è una proprietà della libreria rivolta agli sviluppatori. Non è correlato all'identità dell'applicazione, che viene impostata utilizzando la proprietà applicationId
.
Nelle versioni precedenti di AGP, sia la proprietà applicationId
(per
un'app) sia la proprietà namespace
(per una libreria) potevano essere impostate utilizzando
l'attributo package
del file manifest, creando confusione.
Scegli un valore minSdkVersion
La scelta di un minSdkVersion
per
la tua raccolta è un aspetto importante della pubblicazione della tua raccolta. Il valore
minSdkVersion
dovrebbe riflettere la versione minima di Android supportata
dal tuo codice.
Quando scegli un minSdkVersion
, tieni presente quanto segue:
Se scegli un valore
minSdkVersion
basso, in genere consente una distribuzione più ampia della raccolta.Il codice di una libreria solitamente non viene eseguito, a meno che l'app non lo chiami esplicitamente. Un'app può comunque essere eseguita su una versione di Android inferiore a quanto richiesto da una dipendenza dalla libreria, se la libreria non è essenziale per la funzionalità di base dell'app, eseguendo controlli di runtime prima di chiamare la libreria. Pertanto, imposta il
minSdkVersion
della raccolta in modo che sia sufficientemente bassa da poter essere incorporata nelle app e, quando è possibile, chiamarla per raggiungere più utenti.La scelta di un valore
minSdkVersion
elevato potrebbe impedire alle applicazioni di includere la libreria.La fusione dei file manifest, che è un passaggio in AGP che unisce i file manifest dall'app e dalle sue dipendenze, impone l'applicazione di un valore
minSdkVersion
maggiore a quello dell'app per nessuna dipendenza.Se scegli un valore
minSdkVersion
elevato, gli sviluppatori di app potrebbero disabilitare i controlli di sicurezza dell'unione dei file manifest, causando così problemi in una fase successiva del processo di compilazione.Poiché l'unione dei manifest impedisce ai progetti di app di includere le librerie con un valore
minSdkVersion
maggiore rispetto all'app stessa, gli sviluppatori di app potrebbero disattivare i controlli di sicurezza dell'unione dei manifest per ridurre al minimo gli errori di generazione. Tuttavia, questo rischia di vere problemi di incompatibilità a valle.La scelta di un valore
minSdkVersion
elevato potrebbe essere necessaria in casi speciali in cui il manifest di una libreria include un ricevitore di trasmissione o qualche altro meccanismo mediante il quale il relativo codice viene attivato automaticamente.In questi casi, la scelta di un valore
minSdkVersion
elevato assicura che il codice possa essere eseguito. In alternativa, puoi disattivare il comportamento automatico in modo che l'app possa attivare l'esecuzione della libreria dopo aver effettuato i controlli corretti.
Per consentire l'incorporamento nelle app, utilizza l'annotazione RequiresApi
nella tua libreria per indicare ai chiamanti che devono eseguire controlli di runtime. Android
Lint utilizza le informazioni RequiresApi
per le ispezioni. Per ulteriori risorse sull'uso delle annotazioni per migliorare il codice API e le API, consulta Migliorare l'ispezione del codice con le annotazioni.
Configura i metadati AAR
Una libreria Android viene pacchettizzata sotto forma di file AAR (Android Archive). I metadati AAR sono costituiti da proprietà che aiutano AGP a utilizzare le librerie. Se la tua libreria viene utilizzata da una configurazione non compatibile e i metadati AAR sono impostati, agli utenti viene mostrato un messaggio di errore che li aiuta a risolvere il problema.
Scegli un valore minCompileSdk
A partire dalla versione 4.1, AGP supporta
minCompileSdk
.
Questo indica il valore minimo di compileSdk
che i progetti possono utilizzare. Se la tua libreria contiene voci manifest o risorse che utilizzano attributi della piattaforma più recenti, devi impostare questo valore.
Il valore minCompileSdk
può essere impostato nei blocchi defaultConfig{}
,
productFlavors{}
e buildTypes{}
nel file build.gradle
a livello di modulo:
trendy
android { defaultConfig { aarMetadata { minCompileSdk = 29 } } productFlavors { foo { ... aarMetadata { minCompileSdk = 30 } } } }
Kotlin
android { defaultConfig { aarMetadata { minCompileSdk = 29 } } productFlavors { register("foo") { ... aarMetadata { minCompileSdk = 30 } } } }
Se imposti minCompileSdk
in più posizioni, Gradle dà la priorità alle posizioni
delle impostazioni come segue durante il processo di creazione:
buildTypes{}
productFlavors{}
defaultConfig{}
Nell'esempio precedente, dove minCompileSdk
è definito sia in defaultConfig{}
che in productFlavors{}
, productFlavors{}
ha la priorità e minCompileSdk
è impostato su 30.
Per scoprire di più su come Gradle assegna la priorità alle impostazioni quando combina codice e risorse, consulta Creare con set di sorgenti.
Abilita attrezzature di test
Gli apparecchi di test sono comunemente utilizzati per configurare il codice da testare o per facilitare i test di un componente. A partire dalla versione 7.1, AGP può creare attrezzature di test per i progetti di libreria, oltre che per i progetti di applicazioni e con funzionalità dinamiche.
Quando pubblichi una libreria che può essere utilizzata da altri utenti, valuta la possibilità di creare attrezzature di test per l'API. Le attrezzature di test possono essere attivate nel file build.gradle
a livello di modulo:
trendy
android { testFixtures { enable = true } }
Kotlin
android { testFixtures { enable = true } }
Quando attivi gli apparecchi di test, Gradle crea automaticamente un
set di origine src/testFixtures
in cui puoi scrivere gli endpoint di test.
Per ulteriori informazioni, consulta la documentazione di Gradle sull'utilizzo degli apparecchi di test.