Wtyczka Androida do obsługi Gradle w wersji 4.2.0 (marzec 2021 r.)

Zgodność

Wersja minimalna Wersja domyślna Uwagi
Gradle 6.7.1 Nie dotyczy Więcej informacji znajdziesz w artykule o aktualizowaniu Gradle.
Narzędzia do kompilacji pakietu SDK 30.0.2 30.0.2 Zainstaluj lub skonfiguruj narzędzia SDK do kompilacji.
NDK Nie dotyczy 21.4.7075529 Zainstaluj lub skonfiguruj inną wersję NDK.

Nowe funkcje

Ta wersja wtyczki Androida do obsługi Gradle zawiera te nowe funkcje.

Domyślnie język Java w wersji 8

Od wersji 4.2 wtyczka Androida do obsługi Gradle będzie domyślnie używać języka Java w wersji 8. Java 8 zapewnia dostęp do wielu nowszych funkcji języka, w tym do wyrażeń lambda, odwołań do metod i statycznych metod interfejsu. Pełną listę obsługiwanych funkcji znajdziesz w dokumentacji Javy 8.

Aby zachować stare działanie, w pliku na poziomie modułu wyraźnie określ Javę 7: build.gradle.kts lub build.gradle

// build.gradle
android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}
// build.gradle.kts
android {
  ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_7
    targetCompatibility = JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

Nowy kompilator zasobów JVM

Nowy kompilator zasobów JVM w narzędziu wtyczki Androida do obsługi Gradle w wersji 4.2 zastępuje części kompilatora zasobów AAPT2, co może poprawić wydajność kompilacji, zwłaszcza na komputerach z systemem Windows. Nowy kompilator zasobów JVM jest domyślnie włączony.

Obsługa podpisywania w wersji 3 i 4

Wtyczka Androida do obsługi Gradle w wersji 4.2 obsługuje teraz formaty podpisywania plików APK w wersji 3 i APK w wersji 4. Aby włączyć jeden lub oba te formaty w kompilacji, dodaj te właściwości do pliku na poziomie modułu build.gradle lub build.gradle.kts:

// build.gradle
android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}
// build.gradle.kts
android {
  ...
  signingConfigs {
      config {
          ...
          enableV3Signing = true
          enableV4Signing = true
      }
  }
}

Podpisywanie plików APK w wersji 4 umożliwia szybkie wdrażanie dużych plików APK za pomocą ADB przyrostowej instalacji plików APK w Androidzie 11. Ta nowa flaga obsługuje krok podpisywania plików APK w procesie wdrażania.

Konfigurowanie podpisywania aplikacji w zależności od wariantu

We wtyczce Androida do obsługi Gradle można teraz włączać i wyłączać podpisywanie aplikacji w zależności od wariantu.

Ten przykład pokazuje, jak ustawić podpisywanie aplikacji w zależności od wariantu za pomocą metody onVariants() w Kotlinie lub Groovy:

androidComponents {
    onVariants(selector().withName("fooDebug")) {
        signingConfig {
            enableV1Signing false
            enableV2Signing true
        }
    }
}

Nowa właściwość Gradle: android.native.buildOutput

Aby zmniejszyć ilość niepotrzebnych informacji w danych wyjściowych kompilacji, wtyczka Androida do obsługi Gradle w wersji 4.2 filtruje komunikaty z kompilacji C/C++, które używają CMake i ndk-build, domyślnie wyświetlając tylko dane wyjściowe kompilatora C/C++. Wcześniej dla każdego skompilowanego pliku generowany był wiersz danych wyjściowych , co powodowało wyświetlanie dużej ilości komunikatów informacyjnych.

Jeśli chcesz zobaczyć wszystkie dane wyjściowe C/C++, ustaw nową właściwość Gradle android.native.buildOutput na verbose.

Tę właściwość możesz ustawić w pliku gradle.properties lub w wierszu poleceń.

gradle.properties
android.native.buildOutput=verbose

Wiersz poleceń
-Pandroid.native.buildOutput=verbose

Domyślna wartość tej właściwości to quiet.

Zmiana działania w przypadku plików gradle.properties

Od wtyczki Androida do obsługi Gradle w wersji 4.2 nie można już zastępować właściwości Gradle z podprojektów. Innymi słowy, jeśli zadeklarujesz właściwość w plikugradle.properties w podprojekcie zamiast w projekcie głównym, zostanie ona zignorowana.

Na przykład w poprzednich wersjach wtyczka Androida do obsługi Gradle odczytywała wartości z <var>projectDir</var>/gradle.properties, <var>projectDir</var>/app/gradle.properties, <var>projectDir</var>/library/gradle.properties, itp. W przypadku modułów aplikacji, jeśli ta sama właściwość Gradle była obecna zarówno w <var>projectDir</var>/gradle.properties jak i w <var>projectDir</var>/app/gradle.properties, pierwszeństwo miała wartość z <var>projectDir</var>/app/gradle.properties.

W wtyczce Androida do obsługi Gradle w wersji 4.2 to działanie zostało zmienione i wtyczka nie będzie wczytywać wartości z gradle.properties w podprojektach (np. <var>projectDir</var>/app/gradle.properties). Ta zmiana odzwierciedla nowe działanie Gradle i obsługuje buforowanie konfiguracji

Więcej informacji o ustawianiu wartości w gradle.properties plikach znajdziesz w dokumentacji Gradle.

Zmiany w zgodności i konfiguracji Gradle

Gdy narzędzie do kompilacji Gradle jest uruchamiane w Android Studio, używa pakietu JDK dołączonego do Studio. W poprzednich wersjach do Studio był dołączony pakiet JDK 8. W wersji 4.2, jest jednak dołączony pakiet JDK 11. Używanie nowego dołączonego pakietu JDK do uruchamiania Gradle może powodować pewne problemy ze zgodnością lub wpływać na wydajność JVM ze względu na zmiany w mechanizmie odśmiecania. Te problemy opisujemy poniżej.

Uwaga: chociaż zalecamy uruchamianie Gradle z pakietem JDK 11, w oknie Struktura projektu można zmienić pakiet JDK używany do uruchamiania Gradle. Zmiana tego ustawienia spowoduje zmianę tylko pakietu JDK używanego do uruchamiania Gradle, a nie pakietu JDK używanego do uruchamiania samego Studio.

Zgodność Studio z wtyczką Androida do obsługi Gradle

Android Studio 4.2 może otwierać projekty, które używają wtyczki Androida do obsługi Gradle w wersji 3.1 lub nowszej, pod warunkiem że wtyczka Androida do obsługi Gradle jest uruchomiona w Gradle w wersji 4.8.1 lub nowszej. Więcej informacji o zgodności Gradle znajdziesz w artykule Aktualizowanie Gradle.

Optymalizowanie kompilacji Gradle pod kątem pakietu JDK 11

Ta aktualizacja do pakietu JDK 11 wpływa na domyślną konfigurację mechanizmu odśmiecania JVM, ponieważ pakiet JDK 8 używa równoległego mechanizmu odśmiecania, a pakiet JDK 11 – mechanizmu odśmiecania G1.

Aby potencjalnie poprawić wydajność kompilacji, zalecamy testowanie kompilacji Gradle z równoległym mechanizmem odśmiecania. W pliku gradle.properties ustaw te wartości:

org.gradle.jvmargs=-XX:+UseParallelGC

Jeśli w tym polu są już ustawione inne opcje, dodaj nową opcję:

org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC

Aby zmierzyć szybkość kompilacji przy różnych konfiguracjach, zapoznaj się z artykułem Profilowanie kompilacji.

Nieskompresowane pliki DEX w plikach APK, gdy minSdk = 28 lub nowszy

Gdy minSdk = 28 lub nowszy, wtyczka Androida do obsługi Gradle domyślnie pakuje nieskompresowane pliki DEX w plikach APK. Powoduje to zwiększenie rozmiaru pliku APK, ale zmniejsza rozmiar instalacji na urządzeniu, a rozmiar pobierania jest mniej więcej taki sam.

Aby wymusić na wtyczce Androida do obsługi Gradle pakowanie skompresowanych plików DEX, możesz dodać te informacje do pliku build.gradle file:

android {
    packagingOptions {
        dex {
            useLegacyPackaging true
        }
    }
}

Używanie DSL do pakowania skompresowanych bibliotek C/C++

Zalecamy pakowanie bibliotek C/C++ w postaci nieskompresowanej, ponieważ zmniejsza to rozmiar instalacji aplikacji, rozmiar pobierania aplikacji i czas wczytywania aplikacji przez użytkowników. Jeśli jednak chcesz, aby wtyczka Androida do obsługi Gradle pakowała skompresowane biblioteki C/C++ podczas kompilowania aplikacji, ustaw useLegacyPackaging na true w pliku build.gradle aplikacji:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

Flaga useLegacyPackaging zastępuje atrybut manifestu extractNativeLibs. Więcej informacji znajdziesz w informacji o wersji Biblioteki natywne domyślnie pakowane w postaci nieskompresowanej.