Przygotowywanie biblioteki do publikacji

Na tej stronie opisujemy właściwości i opcje potrzebne do przygotowania projektu biblioteki Androida do publikacji za pomocą wtyczki Androida do obsługi Gradle (AGP). Nawet jeśli niektóre z tych właściwości zostały ustawione na początku tworzenia biblioteki, zapoznaj się z poniższymi wskazówkami, aby zoptymalizować ustawienia.

Wybierz przestrzeń nazw

Biblioteki Androida muszą deklarować przestrzeń nazw, aby mogły wygenerować unikalną klasę R podczas kompilowania zasobów. Ta przestrzeń nazw powinna być ściśle dopasowana do pakietu klasy głównej biblioteki, aby uniknąć nieporozumień, gdy użytkownicy importują zwykłe klasy z biblioteki i jej klasy R.

Począwszy od wtyczki Androida do obsługi Gradle 7.0, możesz ustawić przestrzeń nazw w pliku build.gradle aplikacji, jak pokazano w tym przykładowym kodzie:

Dynamiczny

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

Kotlin

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

Przestrzeń nazw to właściwość biblioteki widoczna dla dewelopera. Nie jest on powiązany z tożsamością aplikacji, która jest ustawiana za pomocą właściwości applicationId.

W poprzednich wersjach wtyczki Androida do obsługi Gradle właściwości applicationId (w przypadku aplikacji) i namespace (w przypadku biblioteki) można było ustawić za pomocą atrybutu package w pliku manifestu, co powodowało nieporozumienia.

Wybierz wartość minSdkVersion

Wybór minSdkVersion dla biblioteki jest ważnym aspektem jej publikowania. minSdkVersion powinien odzwierciedlać minimalną wersję Androida, którą może obsługiwać Twój kod.

Podczas wybierania minSdkVersion pamiętaj o tych kwestiach:

  • Wybór niskiej wartości minSdkVersion zwykle pozwala na szerszą dystrybucję biblioteki.

    Kod biblioteki zwykle nie jest wykonywany, chyba że aplikacja wywołuje go bezpośrednio. Aplikacja może nadal działać na wersji Androida niższej niż wymagana przez zależność biblioteki, jeśli biblioteka nie jest niezbędna do działania podstawowych funkcji aplikacji. W takim przypadku przed wywołaniem biblioteki przeprowadzane są testy w czasie działania. Dlatego ustaw minSdkVersion biblioteki na wystarczająco niską wartość, aby można było ją umieścić w aplikacjach i wywoływać, gdy jest to możliwe, co pomoże dotrzeć do większej liczby użytkowników.

  • Wybranie wysokiej wartości minSdkVersion może uniemożliwić aplikacjom dołączenie biblioteki.

    Narzędzie do scalania plików manifestu, które jest etapem w AGP, podczas którego scalane są pliki manifestu z aplikacji i jej zależności, wymusza, aby żadne zależności nie miały wyższej wartości minSdkVersion niż aplikacja.

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

    Ponieważ scalanie plików manifestu uniemożliwia projektom aplikacji dołączanie bibliotek o wyższej wartości minSdkVersion niż sama aplikacja, deweloperzy aplikacji mogą wyłączyć kontrole bezpieczeństwa scalania plików manifestu, aby zminimalizować liczbę błędów kompilacji. Może to jednak spowodować problemy z niezgodnością na dalszych etapach.

  • Wybór wysokiej wartości minSdkVersion może być konieczny w szczególnych przypadkach, gdy manifest biblioteki zawiera odbiornik komunikatów lub inny mechanizm, który automatycznie aktywuje kod.

    W takich przypadkach wybranie wysokiej wartości minSdkVersion zapewnia możliwość uruchomienia kodu. Możesz też wyłączyć automatyczne działanie, aby aplikacja mogła zdecydować się na uruchomienie biblioteki po przeprowadzeniu odpowiednich testów.

Aby zezwolić na umieszczanie w aplikacjach, użyj adnotacji RequiresApi w bibliotece, aby poinformować wywołujące ją elementy, że muszą przeprowadzić testy w czasie działania. Android Lint używa informacji RequiresApi do przeprowadzania kontroli. Więcej informacji o używaniu adnotacji do ulepszania kodu interfejsu API i samych interfejsów API znajdziesz w artykule Ulepszanie kontroli kodu za pomocą adnotacji.

Konfigurowanie metadanych AAR

Biblioteka Androida jest spakowana w formie pliku Android Archive (AAR). Metadane AAR składają się z właściwości, które pomagają wtyczce Androida do obsługi Gradle korzystać z bibliotek. Jeśli Twoja biblioteka jest używana przez niezgodną konfigurację i skonfigurowano metadane AAR, użytkownicy zobaczą komunikat o błędzie, który pomoże im rozwiązać problem.

Wybierz wartość 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{} i buildTypes{} w pliku build.gradle na poziomie modułu:

Dynamiczny

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

Kotlin

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

Jeśli ustawisz minCompileSdk w kilku miejscach, Gradle podczas procesu kompilacji nada priorytet lokalizacjom ustawień w następujący sposób:

  1. buildTypes{}

  2. productFlavors{}

  3. defaultConfig{}

W poprzednim przykładzie, w którym zmienna minCompileSdk jest zdefiniowana zarówno w defaultConfig{}, jak i productFlavors{}, priorytet ma productFlavors{}, a wartość zmiennej minCompileSdk jest ustawiona na 30.

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

Włączanie urządzeń testowych

Urządzenia testowe są często używane do konfigurowania testowanego kodu lub ułatwiania testów komponentu. Od wersji 7.1 AGP może tworzyć urządzenia testowe na potrzeby projektów bibliotek, a także projektów aplikacji i funkcji dynamicznych.

Jeśli publikujesz bibliotekę, z której będą korzystać inni, rozważ utworzenie zestawów testowych dla interfejsu API. Środowiska testowe można włączyć w pliku build.gradle na poziomie modułu:

Dynamiczny

android {
  testFixtures {
    enable = true
  }
}

Kotlin

android {
  testFixtures {
    enable = true
  }
}

Gdy włączysz testowe bazy danych, Gradle automatycznie utworzy zbiór źródeł src/testFixtures, w którym możesz je zapisywać.

Więcej informacji znajdziesz w dokumentacji Gradle dotyczącej używania zestawów testowych.