Using Build Flavors - strukturyzacja folderów źródłowych i build.gradle poprawnie

"smaki produktów" na Androida

Czasami pytano mnie, jak pracować z różnymi hostami, ikonami, a nawet nazwami pakietów, deppując na różnych wersjach tej samej aplikacji.

Istnieje wiele powodów, aby to zrobić i jeden prosty sposób: smaki produktów.

Możesz zdefiniować na swojej kompilacji.gradle script takie rzeczy opisywałem wcześniej.

smaki produktu Część artykułu jest napisana z myślą o produkcie smaki, więc czym one są? Jeśli chodzi o dokumentację Androida:

Smak produktu definiuje dostosowaną wersję aplikacji zbudowanej przez projekt. Pojedynczy projekt może mieć różne smaki, które zmieniają wygenerowaną aplikację.

Jak można je zdefiniować? Musisz pisać na swojej budowie.gradle jakie smaki chcesz zdefiniować:

productFlavors {  
        ...
        devel {
            ...
        }

        prod {
            ...
        }
    }

Teraz będziemy mieli dwa różne smaki naszej aplikacji. Możesz to sprawdzić na Android Studio również w wariantach kompilacji tab

Warianty budowy

wiele nazw pakietów

Co zrobić, jeśli chcesz mieć zainstalowaną w telefonie jedną aplikację ze stanem deweloperskim i jedną ze stanem produkcyjnym. Jak być może wiesz, możesz zainstalować tylko jedną aplikację o tej samej nazwie pakietu(jeśli spróbujesz zainstalować jakiś nowy APK z tym samym, który jest zainstalowany w telefonie, spróbuje go zaktualizować).

Jedyne, co musisz zrobić, to zdefiniować go na każdym produkcie smaki:

android {  
    productFlavors {
        devel {
            applicationId "zuul.com.android.devel"
        }
        prod {
            applicationId "zuul.com.android"
        }
    }
}

Wysyłanie żądań do wielu hostów w zależności od smaku Tak jak wcześniej, musisz podać kilka paramów w polu konfiguracji smaku produktu.

android {  
    productFlavors {
        devel {
            applicationId "zuul.com.android.devel"
            buildConfigField 'String', 'HOST', '"http://192.168.1.34:3000"'

        }

        prod {
            applicationId "zuul.com.android"
               buildConfigField 'String', 'HOST', '"http://api.zuul.com"'

        }
    }
}

Jako przykład spróbujemy pokazać, w jaki sposób można zintegrować to z Retrofit, aby wysłać żądanie do odpowiedniego serwera bez obsługi, który serwer kierujesz i w oparciu o smak. W tym przypadku jest to fragment aplikacji Zuul na Androida:

public class RetrofitModule {

    public ZuulService getRestAdapter() {
        RestAdapter restAdapter = new RestAdapter.Builder()
                .setEndpoint(BuildConfig.HOST)
                .setLogLevel(RestAdapter.LogLevel.FULL)
                .build();
        return restAdapter.create(ZuulService.class);
    }

}

Jak widać wystarczy użyć BuildConfigclass, aby uzyskać dostęp do zmiennej, którą właśnie zdefiniowałeś.

Dowolna zmienna dostępna za pomocą Twojego kodu Zmienna HOST nie jest jedyną, którą możesz ujawnić w kodzie. Możesz to zrobić z czym chcesz:

prod {  
    applicationId "zuul.com.android"
    buildConfigField 'String', 'HOST', '"http://api.zuul.com"'
    buildConfigField 'String', 'FLAVOR', '"prod"'
    buildConfigField "boolean", "REPORT_CRASHES", "true"
}

Możesz uzyskać do nich dostęp w następujący sposób:

BuildConfig.HOST  
BuildConfig.FLAVOR  
BuildConfig.REPORT_CRASHES  

Różne ikony na smak Jeśli chcesz mieć różne ikony dla smaku, dzięki czemu możesz wizualnie wykryć, którą otwierasz (możesz to zrobić również po nazwie... Ale to nie może zmieścić przestrzeń!), po prostu trzeba zdefiniować nowe struktury katalogów dla każdego ze smaków.

W przykładzie, którego właśnie użyłem, są dwa smaki: devel i prod. Następnie możemy zdefiniować dwie nowe struktury katalogów, dzięki czemu możemy zdefiniować zasoby, które chcemy:

Struktura

To działa z innymi rodzajami zasobów, takimi jak strings.xml, integers.xml, arrays.xml, itp.

Konfiguracja Ustawień Podpisywania

Aby ręcznie skonfigurować konfiguracje podpisywania dla typu release build przy użyciu Gradle konfiguracja budowy:

1.Utwórz keystore. Keystore to plik binarny zawierający zestaw kluczy prywatnych. Musisz trzymać klucz w bezpiecznym miejscu. 2.Utwórz klucz prywatny. Klucz prywatny reprezentuje podmiot, który ma być identyfikowany z aplikacją, taki jak osoba lub firma. 3.Dodaj konfigurację podpisywania do kompilacji na poziomie modułu.plik gradle:

android {
...
defaultConfig {...}
signingConfigs {
    release {
        storeFile file("myreleasekey.keystore")
        storePassword "password"
        keyAlias "MyReleaseKey"
        keyPassword "password"
    }
}
buildTypes {
    release {
        ...
        signingConfig signingConfigs.release
    }
}

}

Wygeneruj podpisany APK:

Aby wygenerować podpisany APK, wybierz Build > Generate Podpisany APK z menu głównego. Pakiet w app / build / apk / app-release.apk jest teraz podpisany kluczem wydania.

Ref: https://developer.android.com/studio/build/build-variants.html#signing,http://blog.brainattica.com/how-to-work-with-flavours-on-android/

Wydaje się, że musisz przeładować swój projekt po dodaniu nowych smaków w build.gradle. Następnie zobaczysz 4 warianty kompilacji w widoku warianty kompilacji(uzyskasz do nich dostęp z lewej krawędzi okna).

Jeśli chodzi o dodatkowe katalogi źródłowe, wydaje się, że trzeba je tworzyć ręcznie: src/flavor1/java i src/flavor2/java. Zobaczysz, że zmiana smaku w widoku "Build Variants" zmieni aktualnie aktywne katalogi źródłowe (katalog jest niebieski, gdy jest active source directory )

Wreszcie, "gradle stworzy nowe zestawy źródeł dla twoich nowych smaków" oznacza, że gradle stworzy obiekty android.sourceSets.flavor1 i android.sourceSets.flavor2 i będziesz mógł ich używać w swojej kompilacji.Gradle script. Ale te obiekty są tworzone dynamicznie, dlatego nie widzisz ich w build.gradle (proponuję przeczytać to: http://www.gradle.org/docs/current/userguide/tutorial_using_tasks.html szczególnie 6.6: wyjaśnia tworzenie dynamicznych zadań. Skrypt gradle jest to groovy script, więc proponuję zapoznać się również z groovy)

Miałem ten sam problem, kiedy migrowałem mój projekt do Gradle. Problem polegał na tym, że kompilator nie znalazł odpowiedniego folderu zasobów. Naprawiłem to, dodając to pod elementem android w build."gradle": {]}

sourceSets {
        main {
            res.srcDirs = ['myProject/res']
        }
    }

Coś, co jest ważne i zablokowało mnie na jakiś czas, to to, że nazwa smaku, która musi pasować do pakietu, w przeciwieństwie do pakietu zdefiniowanego wewnątrz definicji smaku w gradle. Na przykład:

src/flavor1/java/com/foo/A.java

Dopasuje

productFlavors {
  flavor1 {
    packageName 'com.android.studio.test.foobar'
  }
}

Ale

src/foobar/java/com/foo/A.java nie będzie używany do kompilacji flavor1.

W gradle:

Dla typów budowania potrzebujesz tylko:

buildTypes {
   release{
    //proguard, signing etc.
   }
   debug {
    //development
   }
  }
}

A potem do smaków dodajesz te, których potrzebujesz

productFlavors {
    pro {
        applicationIdSuffix '.paid'
        buildConfigField 'boolean', 'PRO', 'true'
    }
    free {
        applicationIdSuffix '.free'
        buildConfigField 'boolean', 'PRO', 'false'
    }
}