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

Ta wersja wtyczki Androida wymaga:

Wersja minimalna Wersja domyślna Uwagi
Gradle 5.1.1 5.1.1 Więcej informacji znajdziesz w artykule o aktualizowaniu Gradle. Jeśli używasz Gradle w wersji 5.0 lub nowszej, domyślny rozmiar sterty pamięci demona Gradle zmniejsza się z 1 GB do 512 MB. Może to spowodować pogorszenie wydajności kompilacji. Aby zastąpić to ustawienie domyślne, określ rozmiar sterty demona Gradle w pliku gradle.properties projektu.
Narzędzia do kompilacji pakietu SDK 28.0.3 28.0.3 Zainstaluj lub skonfiguruj narzędzia SDK do kompilacji.

3.4.3 (lipiec 2020 r.)

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

Szczegóły znajdziesz w informacjach o wersji 4.0.1.

3.4.2 (lipiec 2019 r.)

Ta niewielka aktualizacja obsługuje Android Studio 3.4.2 i zawiera różne poprawki błędów oraz ulepszenia wydajności. Listę ważnych poprawek błędów znajdziesz w powiązanym poście na blogu Release Updates.

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 wydajności. Listę ważnych poprawek błędów znajdziesz w powiązanym poście na blogu Release Updates.

Nowe funkcje

  • Nowe konfiguracje zależności sprawdzania za pomocą lintera: zmieniło się działanie lintChecks. Wprowadziliśmy też nową konfigurację zależności lintPublish, która daje większą kontrolę nad tym, które sprawdzenia za pomocą lintera są pakowane w bibliotekach Androida.

    • lintChecks: jest to istniejąca konfiguracja, której należy używać w przypadku sprawdzeń za pomocą lintera, które mają być uruchamiane tylko podczas lokalnego kompilowania projektu. Jeśli wcześniej używasz konfiguracji zależności lintChecks do uwzględniania sprawdzeń za pomocą lintera w opublikowanym pliku AAR, musisz przeprowadzić migrację tych zależności do zamiast tego używać nowej lintPublish konfiguracji opisanej poniżej.
    • lintPublish: użyj tej nowej konfiguracji w projektach bibliotek w przypadku sprawdzeń za pomocą lintera, które chcesz uwzględnić w opublikowanym pliku AAR, jak pokazano poniżej. Oznacza to, że projekty, które korzystają z Twojej biblioteki również stosują te sprawdzenia za pomocą lintera.

    Poniższy przykładowy kod używa obu konfiguracji zależności w a 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 przygotowywania pakietów i podpisywania powinny być wykonywane szybciej Jeśli zauważysz regresję wydajności związaną z tymi zadaniami, proszę zgłoś błąd.

Zmiany w zachowaniu

  • Ostrzeżenie o wycofaniu wtyczki funkcji aplikacji błyskawicznych na Androida warning: jeśli nadal używasz wtyczki com.android.feature do kompilowania aplikacji błyskawicznej, wtyczka Androida do obsługi Gradle w wersji 3.4.0 wyświetli ostrzeżenie o wycofaniu. Aby mieć pewność, że nadal możesz kompilować aplikację błyskawiczną w przyszłych wersjach wtyczki, przeprowadź migrację aplikacji błyskawicznej do wtyczki funkcji dynamicznych, która umożliwia też publikowanie zarówno zainstalowanej, jak i błyskawicznej wersji aplikacji z jednego pakietu Android App Bundle.

  • R8 jest domyślnie włączony: R8 integruje odludrzanie, zmniejszanie, zaciemnianie kodu, optymalizowanie i dexowanie w jednym kroku, co znacznie poprawia wydajność kompilacji. R8 został wprowadzony w wtyczce Androida do obsługi Gradle w wersji 3.3.0 i jest teraz domyślnie włączony zarówno w projektach aplikacji, jak i bibliotek Androida korzystających z wtyczki w wersji 3.4.0 lub nowszej.

Obraz poniżej przedstawia ogólny proces kompilacji przed wprowadzeniem R8.

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

Teraz dzięki R8 odludrzanie, zmniejszanie, zaciemnianie kodu, optymalizowanie i dexowanie (D8) są wykonywane w jednym kroku, jak pokazano poniżej.

W przypadku R8 odludrzanie, zmniejszanie, zaciemnianie kodu, optymalizacja i indeksowanie DEX są wykonywane w ramach jednego kroku kompilacji.

Pamiętaj, że R8 jest zaprojektowany do współpracy z dotychczasowymi regułami ProGuard, więc prawdopodobnie nie musisz podejmować żadnych działań, aby korzystać z R8. Jednak ponieważ jest to technologia inna niż ProGuard, zaprojektowana specjalnie dla projektów na Androida, zmniejszanie i optymalizacja mogą spowodować usunięcie kodu, którego ProGuard nie usunął. W takiej mało prawdopodobnej sytuacji może być konieczne dodanie dodatkowych reguł, aby zachować ten kod w danych wyjściowych kompilacji.

Jeśli masz problemy z używaniem R8, zapoznaj się z najczęstszymi pytaniami dotyczącymi zgodności z R8 , aby sprawdzić, czy istnieje rozwiązanie Twojego problemu. Jeśli rozwiązanie nie jest udokumentowane, zgłoś błąd. Możesz wyłączyć R8, dodając jeden z tych wierszy do pliku projektu: gradle.properties

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

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

  • ndkCompile jest wycofywany: jeśli spróbujesz użyć ndkBuild do skompilowania bibliotek natywnych, otrzymasz teraz błąd kompilacji. Zamiast tego użyj CMake lub ndk-build, aby dodać kod w językach C i C++ do projektu.

Znane problemy

  • Obecnie nie jest wymuszane prawidłowe używanie unikalnych nazw pakietów ale w nowszych wersjach wtyczki będzie to bardziej rygorystyczne. W wtyczce Androida do obsługi Gradle w wersji 3.4.0 możesz włączyć sprawdzanie, czy Twój projekt deklaruje akceptowalne nazwy pakietów, dodając do pliku gradle.properties wiersz poniżej.

              android.uniquePackageNames = true
              
            

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