Przygotowywanie biblioteki do publikacji

Na tej stronie znajdziesz opis właściwości i opcji, które są potrzebne do przygotowania projektu biblioteki na Androida do opublikowania za pomocą wtyczki Androida do obsługi Gradle (AGP). Nawet jeśli niektóre z tych właściwości ustawisz na początku tworzenia biblioteki, zapoznaj się z tymi wskazówkami, aby zoptymalizować ustawienia.

Wybierz przestrzeń nazw

Biblioteki Androida muszą zadeklarować przestrzeń nazw, aby podczas kompilowania zasobów mogły wygenerować unikalną klasę R. Ten obszar nazw powinien być jak najbardziej zbliżony do pakietu klasy głównej biblioteki, aby uniknąć zamieszania, gdy użytkownicy importują zwykłe klasy z biblioteki i jej klasy R.

Począwszy od wersji AGP 7.0, możesz ustawić przestrzeń nazw w pliku build.gradle aplikacji, jak pokazano w tym przykładzie kodu:

Groovy

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

Kotlin

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

Przestrzeń nazw to właściwość biblioteki przeznaczona dla programistów. Nie jest ona powiązana z tożsamością aplikacji, która jest ustawiana za pomocą właściwości applicationId.

W poprzednich wersjach AGP za pomocą atrybutu package w pliku manifestu można było ustawić zarówno właściwość applicationId (dla aplikacji), jak i właściwość namespace (dla biblioteki), co powodowało zamieszanie.

Wybierz wartość minSdkVersion

Wybór minSdkVersion dla biblioteki jest ważnym aspektem publikowania biblioteki. Wartość minSdkVersion powinna odpowiadać minimalnej wersji Androida, którą obsługuje Twój kod.

Wybierając minSdkVersion, weź pod uwagę te kwestie:

  • Wybór niskiej wartości minSdkVersion pozwala na szersze rozpowszechnianie biblioteki.

    Kod biblioteki jest zwykle wykonywany tylko wtedy, gdy aplikacja wywoła go wprost. Aplikacja może działać w wersji Androida, która jest starsza niż wymagana przez zależność od biblioteki (jeśli biblioteka nie jest niezbędna do działania głównej funkcjonalności aplikacji), ponieważ przed wywołaniem biblioteki przeprowadza kontrole w czasie wykonywania. Dlatego ustaw minSdkVersion biblioteki na wystarczająco niskim poziomie, aby można było ją osadzić w aplikacjach i wywoływać w miarę możliwości, co pomoże dotrzeć do większej liczby użytkowników.

  • Wybór wysokiej wartości minSdkVersion może uniemożliwić aplikacjom uwzględnianie biblioteki.

    Złączanie manifestu to etap w AGP, w ramach którego zliczane są pliki manifestu z aplikacji i jej zależności. Dzięki temu żadne zależności nie mają wyższego minSdkVersion niż aplikacja.

  • Wybranie wysokiej wartości minSdkVersion może skłonić deweloperów aplikacji do wyłączenia kontroli bezpieczeństwa podczas scalania pliku manifestu, co może spowodować problemy w późniejszych etapach procesu kompilacji.

    Kompilator manifestu uniemożliwia projektom aplikacji uwzględnianie bibliotek o większym minSdkVersion niż sama aplikacja. Aby zminimalizować błędy kompilacji, deweloperzy aplikacji mogą wyłączyć kontrole bezpieczeństwa w kompilatorze manifestu. Może to jednak spowodować problemy z niezgodnością w dalszych etapach.

  • Wybór wysokiej wartości minSdkVersion może być konieczny w szczególnych przypadkach, gdy manifest biblioteki zawiera odbiornik transmisji lub inny mechanizm, za pomocą którego kod jest automatycznie uruchamiany.

    W takich przypadkach wybór wysokiej wartości parametru minSdkVersion zapewnia możliwość uruchomienia kodu. Możesz też wyłączyć automatyczne działanie, aby aplikacja mogła uruchomić bibliotekę po wykonaniu odpowiednich kontroli.

Aby umożliwić umieszczanie w aplikacjach, użyj adnotacji RequiresApi w bibliotece, aby wskazać wywołującym, że muszą wykonać weryfikację w czasie wykonywania. Android Lint używa informacji RequiresApi do przeprowadzania inspekcji. Więcej informacji o używaniu adnotacji do ulepszania kodu i interfejsów API znajdziesz w artykule Ulepszanie inspekcji kodu za pomocą adnotacji.

Konfigurowanie metadanych AAR

Biblioteka Androida jest pakowana w postaci pliku archiwum Androida (AAR). Metadane AAR zawierają właściwości, które pomagają AGP korzystać z bibliotek. Jeśli Twoja biblioteka jest używana przez niekompatybilną konfigurację, a metadane AAR są skonfigurowane, użytkownicy zobaczą komunikat o błędzie, który pomoże im rozwiązać problem.

Wybieranie wartości minCompileSdk

Od wersji 4.1 AGP obsługuje minCompileSdk. Wskazuje minimalną wartość compileSdk, której mogą używać projekty korzystające z usługi. Jeśli biblioteka zawiera wpisy w pliku manifestu lub zasoby, które korzystają z nowszych atrybutów platformy, musisz ustawić tę wartość.

Wartość minCompileSdk można ustawić w blokach defaultConfig{}, productFlavors{}buildTypes{} w pliku build.gradle na poziomie modułu:

Groovy

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

Kotlin

android {
  defaultConfig {
    aarMetadata {
      minCompileSdk = 29
    }
  }
  productFlavors {
    register("foo") {
      ...
      aarMetadata {
        minCompileSdk = 30
      }
    }
  }
}

Jeśli ustawienie minCompileSdk jest określone w kilku miejscach, Gradle przypisuje priorytety lokalizacji ustawień w ten sposób:

  1. buildTypes{}

  2. productFlavors{}

  3. defaultConfig{}

W poprzednim przykładzie, w którym parametr minCompileSdk jest zdefiniowany zarówno w definicji defaultConfig{}, jak i productFlavors{}, priorytet ma definicja productFlavors{}, a parametr minCompileSdk ma wartość 30.

Więcej informacji o tym, jak Gradle ustala priorytety ustawień podczas łączenia kodu i zasobów, znajdziesz w artykule Tworzenie za pomocą zbiorów źródeł.

Włączanie testowych urządzeń końcowych

Testowe dane testowe są często używane do konfigurowania testowanego kodu lub ułatwiania testów komponentu. Począwszy od wersji 7.1, AGP może tworzyć testowe uchwyty nie tylko w przypadku projektów aplikacji i projektów funkcji dynamicznych, ale też projektów bibliotek.

Gdy publikujesz bibliotekę, aby mogli z niej korzystać inni, rozważ utworzenie testowych danych testowych dla swojego interfejsu API. Elementy testowe można włączyć w pliku build.gradle na poziomie modułu:

Groovy

android {
  testFixtures {
    enable = true
  }
}

Kotlin

android {
  testFixtures {
    enable = true
  }
}

Gdy włączysz testowe uchwyty, Gradle automatycznie utworzy zestaw src/testFixtures źródeł, w którym możesz pisać testowe uchwyty.

Więcej informacji znajdziesz w dokumentacji Gradle na temat używania testów testowych.