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 podawanymi niżej 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łuje go w prosty sposób. Aplikacja może nadal działać w wersji Androida, która jest starsza niż wymagana przez zależność od biblioteki (jeśli biblioteka nie jest niezbędna do podstawowej funkcjonalności aplikacji), dzięki sprawdzaniu w czasie wykonywania przed wywołaniem biblioteki. 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.

    Zespój manifestu to etap w AGP, który łączy pliki manifestu z aplikacji i jej zależności. Dzięki temu żadna zależność nie ma 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.

    ponieważ narzędzie do scalania manifestów uniemożliwia projektom aplikacji uwzględnianie bibliotek o większym minSdkVersion niż sama aplikacja, deweloperzy aplikacji mogą wyłączyć kontrole bezpieczeństwa narzędzia do scalania manifestów, aby zminimalizować błędy kompilacji. 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, że kod będzie mógł się wykonać. Możesz też wyłączyć automatyczne działanie, aby aplikacja mogła zdecydować o wykonaniu biblioteki 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 na 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 korzystające z nowszych atrybutów platformy, musisz ustawić tę wartość.

Wartość minCompileSdk można ustawić w blokach defaultConfig{}, productFlavors{} i 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 w parametrach defaultConfig{} i productFlavors{}, parametr productFlavors{} ma wyższy priorytet, 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 kompilacji 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 inni mogli z niej korzystać, 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ódłowy, w którym możesz zapisywać testowe uchwyty.

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