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ć bardzo zbliżona 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 AGP 7.0, możesz ustawić przestrzeń nazw w pliku build.gradle aplikacji, jak pokazano w tym przykładzie kodu:

Dynamiczny

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

Kotlin

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

Przestrzeń nazw to właściwość biblioteki widoczna dla dewelopera. Nie jest ona powiązana 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 pliku manifestu, co powodowało nieporozumienia.

Wybierz wartość minSdkVersion

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

Podczas wybierania minSdkVersion pamiętaj o tych kwestiach:

  • Wybranie niskiej wartości minSdkVersion zwykle pozwala na szerszą dystrybucję biblioteki.

    Kod biblioteki zwykle nie jest wykonywany, chyba że aplikacja wywoła go bezpośrednio. Aplikacja może nadal działać na wersji Androida starszej 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 wykonywane są testy w czasie działania. Dlatego ustaw minSdkVersion biblioteki na wystarczająco niską wartość, aby można było ją umieszczać w aplikacjach i wywoływać, gdy jest to możliwe, co pomoże dotrzeć do większej liczby użytkowników.

  • Wybór 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.

  • Wybór 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 z wyższą wartością minSdkVersion niż sama aplikacja, deweloperzy aplikacji mogą wyłączyć kontrole bezpieczeństwa scalania plików manifestu, aby zminimalizować błędy 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 uruchamia jej 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 umożliwić umieszczanie w aplikacjach, użyj adnotacji RequiresApi w bibliotece, aby wskazać wywołującym, ż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ą AGP korzystać z bibliotek. Jeśli 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 to 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 w productFlavors{}, priorytet ma productFlavors{}, a zmienna minCompileSdk ma wartość 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ć zestawy testowe dla 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 osprzęt testowy, Gradle automatycznie utworzy zbiór źródeł src/testFixtures, w którym możesz pisać osprzęt testowy.

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