Preparare la raccolta per il rilascio

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

Scegli uno spazio dei nomi

Le librerie Android devono dichiarare uno spazio dei nomi per poter generare un classe R quando le relative risorse vengono compilate. Questo spazio dei nomi deve corrispondere esattamente pacchetto della classe principale della libreria per evitare confusione quando gli utenti importano corsi della libreria e il relativo corso R.

A partire da AGP 7.0, puoi impostare spazio dei nomi nel file build.gradle dell'app, come mostrato nell'esempio di codice che segue:

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 è e l'identità dell'applicazione, che viene impostata utilizzando applicationId proprietà.

Nelle versioni precedenti di AGP, sia la proprietà applicationId (per un app) e la proprietà namespace (per una libreria) potrebbero essere impostate utilizzando package del file manifest , il che ha creato confusione.

Scegli un valore minSdkVersion

Scegliere una minSdkVersion per la tua raccolta è un aspetto importante della sua pubblicazione. La minSdkVersion deve riflettere la versione minima di Android supportata dal tuo codice assistenza in tempo reale.

Tieni presente i seguenti aspetti nella scelta di un minSdkVersion:

  • Un valore minSdkVersion basso in genere consente una distribuzione più ampia nella tua raccolta.

    Il codice di una libreria solitamente non viene eseguito, a meno che l'app la chiama esplicitamente. Un'app può comunque essere eseguita su una versione di Android che è inferiore a quanto richiesto da una dipendenza dalla libreria, se quest'ultima non è essenziale per la funzionalità di base dell'app, eseguendo controlli di runtime prima di chiamare nella libreria. Di conseguenza, imposta un valore di minSdkVersion della raccolta abbastanza basso da può essere incorporato nelle app e chiamato quando possibile, per aiutare a raggiungere utenti.

  • La scelta di un minSdkVersion alto potrebbe impedire alle applicazioni di includere nella raccolta.

    L'unione dei file manifest, ovvero un passaggio in AGP che unisce i file manifest dall'app e dalle sue dipendenze, applica in modo forzato che hanno un valore minSdkVersion più alto di quello dell'app.

  • La scelta di un valore minSdkVersion alto potrebbe richiedere agli sviluppatori di app di disattivarla controlli di sicurezza dell'unione di manifest, che causano problemi nelle fasi successive del processo di compilazione.

    Perché l'unione dei manifest impedisce ai progetti di app di includere librerie con un valore minSdkVersion più alto di quello dell'app stessa, gli sviluppatori di app potrebbe disattivare i controlli di sicurezza dell'unione dei manifest per ridurre al minimo la build errori. Tuttavia, questo rischia di veri problemi di incompatibilità a valle.

  • Potrebbe essere necessario scegliere un valore minSdkVersion alto nei casi speciali in cui il file manifest di una biblioteca include un broadcast receiver o un altro meccanismo mediante il cui codice viene attivato automaticamente.

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

Per consentire l'incorporamento nelle app, utilizza RequiresApi in per indicare ai chiamanti che devono eseguire i controlli di runtime. Android Lint utilizza le informazioni RequiresApi per le ispezioni. Per altre risorse sull'utilizzo delle annotazioni per migliorare il codice API e le API, consulta Migliorare il codice un'ispezione con annotazioni.

Configura i metadati AAR

Una raccolta Android è pacchettizzata sotto forma di un file di archivio Android (AAR). I metadati AAR sono costituiti da proprietà che aiutano AGP utilizza le librerie. Se la tua raccolta viene utilizzata da un configurazione e i metadati AAR sono impostati, agli utenti viene visualizzato un errore per aiutarli a risolvere il problema.

Scegli un valore minCompileSdk

A partire dalla versione 4.1, AGP supporta minCompileSdk Indica il numero minimo compileSdk utilizzabili dai progetti di consumo. Se la libreria contiene voci manifest o che utilizzano attributi della piattaforma più recenti, devi imposta questo valore.

Il valore minCompileSdk può essere impostato in defaultConfig{}, productFlavors{} e buildTypes{} blocchi nella sezione build.gradle a livello di modulo file:

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 dà la priorità alle impostazioni più posizioni nel seguente modo durante il processo di creazione:

  1. buildTypes{}

  2. productFlavors{}

  3. defaultConfig{}

Nell'esempio precedente, dove minCompileSdk è definito in entrambi defaultConfig{} e productFlavors{}, productFlavors{} ha la priorità e il valore minCompileSdk è impostato su 30.

Per scoprire di più su come Gradle assegna la priorità alle impostazioni quando combini codice e risorse; consulta Creazione con il codice sorgente di grandi dimensioni.

Attiva impianti di test

Espositori per i test sono comunemente utilizzati per impostare il codice da testare o per facilitare i test di un di strumento di authoring. A partire dalla versione 7.1, AGP può creare impianti di test per la libreria oltre a progetti di applicazioni e funzionalità dinamiche.

Quando pubblichi una libreria per l'utilizzo da parte di altri, valuta la possibilità di creare test per la tua API. Gli attrezzatura di test possono essere attivati a livello di modulo File build.gradle:

Alla moda

android {
  testFixtures {
    enable = true
  }
}

Kotlin

android {
  testFixtures {
    enable = true
  }
}

Quando attivi gli impianti per i test, Gradle crea automaticamente src/testFixtures set di origini in cui è possibile scrivere impianti di test.

Per saperne di più, consulta la documentazione di Gradle sull'utilizzo dispositivi per i test.