Preparare la raccolta per il rilascio

Questa pagina descrive 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 hai impostato alcune di queste proprietà all'inizio della creazione della tua raccolta, consulta le seguenti indicazioni per ottimizzare le impostazioni.

Scegliere uno spazio dei nomi

Le librerie Android devono dichiarare uno spazio dei nomi in modo da poter generare una classe R univoca quando le risorse vengono compilate. Questo spazio dei nomi deve corrispondere strettamente al pacchetto di classi radice della libreria per evitare confusione quando gli utenti importano classi regolari dalla libreria e dalla relativa classe R.

A partire da AGP 7.0, puoi impostare namespace nel file build.gradle dell'app, come mostrato nel seguente esempio di codice:

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

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

Lo spazio dei nomi è una proprietà della libreria visibile 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 manifest, il che creava confusione.

Scegli un valore di minSdkVersion

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

Tieni presente le seguenti considerazioni quando scegli un minSdkVersion:

• La scelta di un valore basso per minSdkVersion consente in genere 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 inferiore a quella richiesta da una dipendenza della libreria, se la libreria non è essenziale per la funzionalità principale dell'app, eseguendo controlli di runtime prima di chiamare la libreria. Pertanto, imposta il valore minSdkVersion della libreria su un valore sufficientemente basso da poter essere incorporato nelle app e chiamato quando possibile, per raggiungere un maggior numero di utenti.

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

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

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

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

• La scelta di un valore elevato di minSdkVersion potrebbe essere necessaria in casi speciali in cui il manifest di una libreria include un ricevitore di trasmissione o un altro meccanismo mediante il quale il suo codice viene attivato automaticamente.

  In questi casi, la scelta di un valore elevato per minSdkVersion 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 tua libreria per indicare ai chiamanti che devono eseguire controlli di runtime. Android Lint utilizza le informazioni RequiresApi per le sue ispezioni. Per ulteriori risorse sull'utilizzo delle annotazioni per migliorare il codice API e le API, consulta Migliorare l'ispezione del codice con le annotazioni.

Configurare i metadati AAR

Una libreria Android è inclusa in un 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 minimo compileSdk che i progetti di consumo possono utilizzare. Se la tua libreria contiene voci del 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:

android {
  defaultConfig {
    aarMetadata {
      minCompileSdk = 29
    }
  }
  productFlavors {
    foo {
      ...
      aarMetadata {
        minCompileSdk = 30
      }
    }
  }
}

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 nel seguente ordine durante il processo di build:

1. buildTypes{}

2. productFlavors{}

3. defaultConfig{}

Nell'esempio precedente, in cui 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 Compilare con i set di origine.

Abilita i test fixture

I test fixture vengono comunemente utilizzati per configurare il codice in fase di test o per facilitare i test di un componente. A partire dalla versione 7.1, AGP può creare test fixture per i progetti di libreria oltre che per i progetti di applicazioni e funzionalità dinamiche.

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

android {
  testFixtures {
    enable = true
  }
}

android {
  testFixtures {
    enable = true
  }
}

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

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