Preparare la raccolta per il rilascio

In questa pagina vengono descritte le proprietà e le opzioni necessarie per preparare il progetto della libreria Android per la pubblicazione utilizzando il plug-in Android per Gradle (AGP). Anche se imposti alcune di queste proprietà all'inizio della creazione della libreria, consulta le seguenti indicazioni per ottimizzare le impostazioni.

Scegli uno spazio dei nomi

Le librerie Android devono dichiarare uno spazio dei nomi in modo da poter generare una classe R univoca quando vengono compilate le relative risorse. Questo spazio dei nomi deve corrispondere strettamente 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:

Alla moda

android {
  namespace = 'com.example.library'
}

Kotlin

android {
  namespace = "com.example.library"
}

Lo spazio dei nomi è una proprietà della libreria rivolta agli sviluppatori. Non è correlata 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 manifest, il che generava confusione.

Scegli un valore minSdkVersion

La scelta di un minSdkVersion per la tua libreria è un aspetto importante della pubblicazione della libreria. minSdkVersion deve riflettere la versione minima di Android supportata dal tuo codice.

Quando scegli un minSdkVersion, tieni presente quanto segue:

  • La scelta di un valore minSdkVersion basso generalmente consente una distribuzione più ampia della tua libreria.

    Il codice di una libreria in genere non viene eseguito, a meno che l'app non lo chiami esplicitamente. Un'app può comunque essere eseguita su una versione di Android precedente a quella richiesta da una dipendenza della libreria, se quest'ultima non è essenziale per la funzionalità di base dell'app, eseguendo controlli di runtime prima di chiamare la libreria. Pertanto, imposta il valore minSdkVersion della tua libreria su un livello sufficientemente basso da consentire l'incorporamento nelle app e la chiamata quando possibile, per raggiungere più utenti.

  • La scelta di un valore elevato per minSdkVersion potrebbe impedire alle applicazioni di includere la libreria.

    Il fusore dei manifest, un passaggio di AGP che unisce i file manifest dell'app e delle sue dipendenze, impone che nessuna dipendenza abbia un minSdkVersion superiore a quello dell'app.

  • La scelta di un valore elevato per minSdkVersion potrebbe indurre gli sviluppatori di app a disattivare i controlli di sicurezza per l'unione dei manifest, causando problemi in un secondo momento nel processo di build.

    Poiché l'unione dei manifest impedisce ai progetti di app di includere librerie con un valore minSdkVersion superiore a quello dell'app stessa, gli sviluppatori di app potrebbero disattivare i controlli di sicurezza dell'unione dei manifest per ridurre al minimo gli errori di build. Tuttavia, ciò rischia di causare veri e propri problemi di incompatibilità a valle.

  • La scelta di un valore elevato per minSdkVersion potrebbe essere necessaria in casi speciali in cui il manifest di una libreria include un broadcast receiver o un altro meccanismo tramite il quale il relativo codice viene attivato automaticamente.

    In questi casi, la scelta di un valore minSdkVersion elevato garantisce l'esecuzione del codice. In alternativa, puoi disattivare il comportamento automatico in modo che l'app possa attivare l'esecuzione della libreria dopo aver eseguito i controlli corretti.

Per consentire l'incorporamento nelle app, utilizza l'annotazione RequiresApi nella libreria per indicare ai chiamanti che devono eseguire controlli di runtime. Android Lint utilizza le informazioni di RequiresApi per le sue ispezioni. Per ulteriori risorse sull'utilizzo delle annotazioni per migliorare il codice API e le API, consulta Migliora l'ispezione del codice con le annotazioni.

Configura i metadati AAR

Una libreria Android viene pacchettizzata sotto forma di file Android ARchive (AAR). I metadati AAR sono costituiti da proprietà che aiutano AGP a utilizzare le librerie. Se la tua libreria viene utilizzata da una configurazione incompatibile e i metadati AAR sono configurati, gli utenti visualizzano un messaggio di errore che li aiuta a risolvere il problema.

Scegli un valore minCompileSdk

A partire dalla versione 4.1, AGP supporta minCompileSdk. Indica il valore minimo di compileSdk che i progetti consumer possono utilizzare. Se la tua libreria contiene voci o risorse del manifest 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:

Alla moda

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 assegna la priorità alle posizioni delle impostazioni come segue durante il processo di build:

  1. buildTypes{}

  2. productFlavors{}

  3. defaultConfig{}

Nell'esempio precedente, in cui minCompileSdk è definito sia in defaultConfig{} sia 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 Crea con i set di risorse.

Abilita i dispositivi di test

Le fixture di test vengono comunemente utilizzate per configurare il codice sottoposto a test o facilitare i test di un componente. A partire dalla versione 7.1, AGP può creare fixture di test per i progetti di librerie, oltre ai progetti di applicazioni e funzionalità dinamiche.

Quando pubblichi una libreria che altri possono utilizzare, valuta la possibilità di creare fixture di test per la tua API. Le fixture di test possono essere attivate nel file build.gradle a livello di modulo:

Alla moda

android {
  testFixtures {
    enable = true
  }
}

Kotlin

android {
  testFixtures {
    enable = true
  }
}

Quando attivi le fixture di test, Gradle crea automaticamente un set di risorse src/testFixtures in cui puoi scrivere le fixture di test.

Per saperne di più, consulta la documentazione di Gradle sull'utilizzo delle fixture di test.