Wtyczka Androida do obsługi Gradle 3.4.0 (kwiecień 2019 r.)

Ta wersja wtyczki na Androida wymaga:

Minimalna wersja Wersja domyślna Uwagi
Gradle 5.1.1 5.1.1 Więcej informacji znajdziesz w artykule Aktualizowanie Gradle. W Gradle 5.0 i nowszych wersjach domyślny rozmiar stosu pamięci demona Gradle zmniejsza się z 1 GB do 512 MB. Może to spowodować spadek wydajności kompilacji. Aby zastąpić to domyślne ustawienie, określ rozmiar stosu demona Gradle w pliku gradle.properties projektu.
Narzędzia do kompilowania pakietu SDK 28.0.3 28.0.3 Zainstaluj lub skonfiguruj narzędzia do kompilowania pakietu SDK.

3.4.3 (lipiec 2020 r.)

Ta niewielka aktualizacja zapewnia zgodność z nowymi ustawieniami domyślnymi i funkcjami dotyczącymi widoczności pakietów w Androidzie 11.

Szczegółowe informacje znajdziesz w informacjach o wersji 4.0.1.

3.4.2 (lipiec 2019 r.)

Ta drobna aktualizacja obsługuje Android Studio 3.4.2 i zawiera różne poprawki błędów oraz ulepszenia działania aplikacji. Aby zobaczyć listę istotnych poprawek błędów, przeczytaj odpowiedni post na blogu z aktualnościami dotyczącymi wersji.

3.4.1 (maj 2019 r.)

Ta niewielka aktualizacja obsługuje Android Studio 3.4.1 i zawiera różne poprawki błędów oraz ulepszenia działania aplikacji. Aby zobaczyć listę istotnych poprawek błędów, przeczytaj odpowiedni post na blogu z aktualnościami dotyczącymi wersji.

Nowe funkcje

  • Nowe konfiguracje zależności sprawdzania błędów: zmieniliśmy działanie narzędzia lintChecks i wprowadziliśmy nową konfigurację zależności lintPublish, aby zapewnić Ci większą kontrolę nad tym, które sprawdzania błędów są uwzględniane w pakiecie w bibliotekach Androida.

    • lintChecks: to istniejąca konfiguracja, której należy używać do sprawdzania błędów lint, które chcesz uruchamiać tylko podczas kompilowania projektu lokalnie. Jeśli wcześniej używałeś/używałaś konfiguracji zależności lintChecks, aby uwzględnić sprawdzanie błędów w publikowanym pliku AAR, musisz przenieść te zależności, aby zamiast tego używać nowej konfiguracji lintPublish opisanej poniżej.
    • lintPublish: użyj tej nowej konfiguracji w projektach biblioteki w przypadku kontroli błędów, które chcesz uwzględnić w opublikowanym pliku AAR, jak pokazano poniżej. Oznacza to, że projekty, które korzystają z Twojej biblioteki, stosują te kontrole lint.

    Poniższy przykładowy kod używa obu konfiguracji zależności w lokalnym projekcie biblioteki Androida.

    dependencies {
      // Executes lint checks from the ':lint' project at build time.
      lintChecks project(':lint')
      // Packages lint checks from the ':lintpublish' in the published AAR.
      lintPublish project(':lintpublish')
    }
            
    dependencies {
      // Executes lint checks from the ':lint' project at build time.
      lintChecks(project(":lint"))
      // Packages lint checks from the ':lintpublish' in the published AAR.
      lintPublish(project(":lintpublish"))
        }
            
    • Ogólnie zadania pakowania i podpisywania powinny być wykonywane szybciej. Jeśli zauważysz regresję wydajności związaną z tymi zadaniami, zgłoś błąd.

Zmiany w zachowaniu

  • Ostrzeżenie dotyczące wycofywania wtyczki funkcji aplikacji błyskawicznych na Androida: jeśli nadal używasz wtyczki com.android.feature do kompilowania aplikacji błyskawicznych, wtyczka Androida do obsługi Gradle w wersji 3.4.0 wyświetli ostrzeżenie o wycofaniu. Aby mieć pewność, że nadal będziesz mieć możliwość tworzenia aplikacji błyskawicznych w przyszłych wersjach tego wtyczka, zmień aplikację błyskawiczną na korzystającą z wtyczka dynamicznych funkcji, który umożliwia publikowanie zarówno wersji instalowanych, jak i błyskawicznych aplikacji z jednego pakietu Android App Bundle.

  • R8 jest domyślnie włączone: R8 łączy desugaring, kompresowanie, zaciemnianie, optymalizację i dekompilację w jednym kroku, co skutkuje znaczną poprawą wydajności kompilacji. R8 zostało wprowadzone w komponencie Android Gradle w wersji 3.3.0 i jest teraz domyślnie włączone w przypadku projektów aplikacji i bibliotek Androida korzystających z komponentu w wersji 3.4.0 lub nowszej.

Na poniższym obrazku znajdziesz ogólny opis procesu kompilacji przed wprowadzeniem wersji R8.

Przed R8 ProGuard był innym etapem kompilacji niż dexing i desugaring.

Obecnie w wersji R8 desugaring, shrinking, obfuscating, optymalizacja i dexing (D8) są wykonywane w jednym kroku, jak pokazano poniżej.

W wersji R8 desugaring, shrinking, obfuscating, optymalizacja i dexing są wykonywane w ramach jednego kroku kompilacji.

Pamiętaj, że R8 jest przeznaczony do współpracy z dotychczasowymi regułami ProGuard, więc prawdopodobnie nie będziesz musiał podejmować żadnych działań, aby korzystać z R8. Jednak ze względu na to, że jest to inna technologia niż ProGuard i jest przeznaczona specjalnie do projektów na Androida, kompresowanie i optymalizowanie może spowodować usunięcie kodu, którego ProGuard nie usuwa. W tej nietypowej sytuacji może być konieczne dodanie dodatkowych reguł, aby zachować ten kod w wyniku kompilacji.

Jeśli wystąpią problemy z użyciem R8, przeczytaj najczęstsze pytania dotyczące zgodności R8, aby sprawdzić, czy istnieje rozwiązanie Twojego problemu. Jeśli rozwiązanie nie zostało udokumentowane, zgłoś błąd. Możesz wyłączyć R8, dodając jeden z tych wierszy do pliku gradle.properties projektu:

      # Disables R8 for Android Library modules only.
      android.enableR8.libraries = false
      # Disables R8 for all modules.
      android.enableR8 = false
      
    

Uwaga: jeśli w danym typie kompilacji w pliku build.gradle modułu aplikacji ustawisz wartość useProguard na false, wtyczka Androida do obsługi Gradle użyje R8 do kompresji kodu aplikacji w tym typie kompilacji, niezależnie od tego, czy wyłączysz R8 w pliku gradle.properties projektu.

  • Narzędzia ndkCompile są wycofywane: jeśli spróbujesz użyć narzędzia ndkBuild do skompilowania bibliotek natywnych, pojawi się błąd kompilacji. Zamiast tego użyj CMake lub ndk-build, aby dodać kod C i C++ do projektu.

Znane problemy

  • Obecnie nie jest wymagane prawidłowe używanie unikalnych nazw pakietów, ale w późniejszych wersjach wtyczki wymagania te będą bardziej rygorystyczne. W pliku plugina Gradle na Androida w wersji 3.4.0 możesz sprawdzić, czy Twój projekt deklaruje dopuszczalne nazwy pakietów. Aby to zrobić, dodaj do pliku gradle.properties poniższy wiersz.

              android.uniquePackageNames = true
              
            

    Więcej informacji o ustawianiu nazwy pakietu za pomocą wtyczki Gradle dla Androida znajdziesz w artykule Ustawianie identyfikatora aplikacji.