W poprzednim wpisie opisane zostały bloki mające największą szansę na zmianę w trakcie pracy nad projektem w Unity. Warto jednak poznać plik mainTemplate w całości, dlatego dowiedz się jakie wartości są konfigurowane w bloku android.
Cały blok android
android {
compileSdkVersion **APIVERSION**
buildToolsVersion '**BUILDTOOLS**'
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
defaultConfig {
minSdkVersion **MINSDKVERSION**
targetSdkVersion **TARGETSDKVERSION**
applicationId '**APPLICATIONID**'
ndk {
abiFilters **ABIFILTERS**
}
versionCode **VERSIONCODE**
versionName '**VERSIONNAME**'
}
lintOptions {
abortOnError false
}
aaptOptions {
noCompress = ['.unity3d', '.ress', '.resource', '.obb'**STREAMING_ASSETS**]
}**SIGN**
buildTypes {
debug {
minifyEnabled **MINIFY_DEBUG**
useProguard **PROGUARD_DEBUG**
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-unity.txt'**USER_PROGUARD**
jniDebuggable true
}
release {
minifyEnabled **MINIFY_RELEASE**
useProguard **PROGUARD_RELEASE**
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-unity.txt'**USER_PROGUARD****SIGNCONFIG**
}
}**PACKAGING_OPTIONS****SPLITS**
**BUILT_APK_LOCATION**
bundle {
language {
enableSplit = false
}
density {
enableSplit = false
}
abi {
enableSplit = true
}
}
}**SPLITS_VERSION_CODE****REPOSITORIES****SOURCE_BUILD_SETUP**
Blok kompilacji
Odpowiada za narzędzia, które zostaną wykorzystane do zbudowania projektu. Zmienna compileSdkVersion zostaje uzupełniana przez unity liczbą określającą wersję API Android SDK (np. 25), zaś buildToolsVersion – wersję narzędzia do budowania buildtools, np. 25.0.1. Zmienna compileOptions odpowiada za wersje javy użytej do skompilowania kodu i javy na którą ma zostać przeznaczona dana aplikacja. Tutaj na sztywno mamy określone, że obydwie wersje będą w wersji 1.8.
compileSdkVersion **APIVERSION**
buildToolsVersion '**BUILDTOOLS**'
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
Blok defaultConfig
W tym bloku prawie wszystkie wartości są uzupełniane zgodnie z tym, co zostało uzupełnione w oknie PlayerSettings w edytorze Unity.
defaultConfig {
minSdkVersion **MINSDKVERSION**
targetSdkVersion **TARGETSDKVERSION**
applicationId '**APPLICATIONID**'
ndk {
abiFilters **ABIFILTERS**
}
versionCode **VERSIONCODE**
versionName '**VERSIONNAME**'
}
Zgodnie z wartościami podanymi na Screenie 1, wartości będą przedstawiały się następująco:
| MINSDKVERSION | 5.0 ‘Lollipop’, API level 21 |
| TARGETSDKVERSION | najwyższy zainstalowany |
| APPLICATIONID | com.organizacja.nazwagry |
| VERSIONCODE | 29 |
| VERSIONNAME | 1.1.0 |
Sprawdzenie wartości możemy sprawdzić w pliku AndroidManifest.xml w AndroidStudio otwierając zbudowane *.apk.
<?xml version="1.0" encoding="utf-8"?>
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="29"
android:versionName="1.1.0"
android:installLocation="1"
android:compileSdkVersion="28"
android:compileSdkVersionCodename="9"
package="com.organizacja.nazwagry"
platformBuildVersionCode="29"
platformBuildVersionName="1.1.0">
<uses-sdk
android:minSdkVersion="21"
android:targetSdkVersion="28" />
...
Blok lint i AAPT
lintOptions {
abortOnError false
}
aaptOptions {
noCompress = ['.unity3d', '.ress', '.resource', '.obb'**STREAMING_ASSETS**]
}
Lint jest narzędziem z Android Studio, które służy do skanowania kodu i plików projektu w poszukiwaniu potencjalnych problemów, np. strukturalnych. Każdy taki błąd jest następnie raportowany za pomocą wiadomości o określonym stopniu błędu (krytycznym, niskim, itd.). Wszystko to odbywa się w czasie budowania projektu, dlatego w przypadku potencjalnego błędu wykrytego przez lint – budowanie nie powiedzie się. Opcja abortOnError oznacza tyle, że wszelkie takie błędy ignorujemy, tj. pozwalamy procesowi budowania przejść dalej, a ewentualnie logi z błędami lub ostrzeżeniami — odczytać później. Zbiór dostępnych dodatkowych opcji można sprawdzić TUTAJ.
AAPT, czyli Android Asset Packaging Tool, jest narzędziem z SDK Androida do pakowania plików i zasobów do pliku *.apk. Dodatkowo pozwala przeglądać, tworzyć, aktualizować paczki kompatybilne z .zip oraz kompilować zasoby to plików binarnych. Zmienna noCompress określa jakie pliki nie będą kompresowane w aplikacji. W tym przypadku domyślnie nie będą to pliki unity3d, pliki .resource, .obb oraz streamowane assety. Pozostałe opcje AAPT można podejrzeć TUTAJ.
Blok buildTypes
By zrozumieć ten blok trzeba omówić czym jest minifikacja oraz proguard.
Minifikacją (ang. minification) nazywamy proces, w którym kod zostanie poddany zmniejszeniu dzięki usunięciu lub zmianie niepotrzebnych rzeczy bez zmiany jego funkcjonowania.. Robi się to poprzez usunięcie białych znaków, znaków nowych linii, komentarzy, itd., dzięki czemu końcowy kod źródłowy waży mniej.
Proguard zaś jest narzędziem open source. Pomaga on utrzymać mniejszy rozmiar projektu oraz przyśpieszyć jego wykonywanie. Proces, na którym opiera się proguard składa się z czterech kroków:
- Zmniejszeniu kodu (ang. shrink), np. dzięki minikacji. Wykrywa nieużywany kod i go usuwa (np. klasy, atrybuty, metody, zmienne).
- Zoptymalizowaniu kodu bajtowego.
- Obfuskacji czyli nadaniu klasom, metodom itd. beznaczeniowych nazw. Czyni również kod trudniejszy do inżynierii wstecznej.
- Weryfikacji.
W Unity możemy wykorzystać proguard w swoim projekcie, jednak robiąc to musimy pamiętać, że niektóre zewnętrzne biblioteki wymagają dopisania do niego dodatkowej konfiguracji.
| MINIFY_DEBUG | włączenie |
| PROGUARD_DEBUG | włączenie |
| MINIFY_RELEASE | włączenie minifikacji w aplikacji releasowej |
| PROGUARD_RELEASE | włączenie |
| USER_PROGUARD | Nasz plik proguard, np. proguard-user.txt |
buildTypes {
debug {
minifyEnabled **MINIFY_DEBUG**
useProguard **PROGUARD_DEBUG**
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-unity.txt'**USER_PROGUARD**
jniDebuggable true
}
release {
minifyEnabled **MINIFY_RELEASE**
useProguard **PROGUARD_RELEASE**
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-unity.txt'**USER_PROGUARD****SIGNCONFIG**
}
}
Blok bundle
Ostatnim blokiem z jakim mamy do czynienia w całym bloku android jest blok bundle. Dzięki bundle nie musimy budować kilku różnych plików *.apk dostosowanych do różnych urządzeń, lecz tworzymy jedną aplikację, która dynamicznie pobiera odpowiednie resourcy. W przypadku języka oraz gęstości występowania pikseli na ekranie wartości są domyślnie ustawione na false, w przypadku abi wartość domyślna jest true.
bundle {
language {
enableSplit = false
}
density {
enableSplit = false
}
abi {
enableSplit = true
}
}
Podsumowanie mainTemplate.gradle w Unity
Linki pod każdym blokiem prowadzą do obszerniejszych opracowań danych tematów. Mam nadzieję, że taki pobieżny wpis pokazał ci gdzie możesz szukać informacji na temat bloków znajdujących się w pliku konfiguracyjnym i uzmysłowił, że Gradle nie jest takim strasznym narzędziem 🙂
