Konwencja nazewnictwa folderów dla wariantów gradle kompilacji

Question

Od pewnego czasu borykam się z wariantami gradle i build.

mam budować te typy zdefiniowane:

• debugowania
• zwalniającą

i te smaki:

• darmo
• płatnych

W jaki sposób mogę zdefiniować unikalne zasoby i zasoby dla określonego wariantu kompilacji, np. FreeDebug? Na przykład chcę mieć cztery różne nazwy aplikacji w zależności od wersji kompilacji i inną ikonę dla każdego wariantu.

Answer 1

Zmagałem się z tym samym problemem. Najpierw użyłem dwóch gałęzi w mojej kontroli źródła, ale to był ból głowy, utrzymujący je w synchronizacji. Gradle to bardzo elastyczny system kompilacji, ale domyślne konwencje nie zawsze są wystarczające. Oto, jak ostatecznie rozwiązałem to w mojej bazie kodu.

skończyło się zasadniczo w następującej strukturze katalogów (uproszczony):

+ src 
    + main 
    | + res 
    | | + values 
    | | - strings.xml 
    | + java 
    | ... 
    + debug 
    | + free 
    | | + res 
    | | + values 
    | |  - strings.xml 
    | + paid 
    | + res 
    | + values 
    |  - strings.xml 
    + free 
    | + res 
    | | + values 
    | | - strings.xml 
    | + java 
    | ... 
    + paid 
    + res 
    | + values 
    | - strings.xml 
    + java 
     ... 

w folderze głównym trzymam wszystko, co jest wspólne dla obu smaków. W wolnym folderze przechowuję wszystko, co jest unikalne w darmowej wersji (to samo dla płatnego). Pliki w folderze smaku zostaną nałożone na wierzch głównego.

Domyślne reguły nakładki będą obsługiwały smaki produktu "za darmo" i "płatne" za pomocą folderów pod "src" o tych samych nazwach. Problem dla mnie zaczął się od nałożenia typów kompilacji.

Jeśli utworzyłem folder debugowania o takiej samej strukturze, co foldery z przyporządkowanymi do niego elementami, zostanie on nałożony na aktualnie używany folder smaku. Doprowadziło to do tej samej nazwy debugowania dla obu smaków, ale chciałem mieć różne nazwy debugowania w zależności od smaku. Po przeprowadzeniu badań wymyśliłem następującą modyfikację mojego pliku kompilacji.

... 

android { 
    buildTypes { 
     debug { 
      ... 
     } 
     release { 
      ... 
     } 
    } 

    productFlavors { 
     free {} 
     paid {} 
    } 
} 

android.applicationVariants.all { variant -> 
    if (variant.buildType.name == "release") { 
     ... 
    } 
    else if (variant.buildType.name == "debug") { 
     switch (variant.name) { 
      case "FreeDebug": 
       variant.mergeResources.doFirst { 
        android.sourceSets.debug.setRoot("src/debug/free") 
       } 
       break; 
      case "PaidDebug": 
       variant.mergeResources.doFirst { 
        android.sourceSets.debug.setRoot("src/debug/paid") 
       } 
       break; 
     } 
    } 
} 

... 

Teraz wariant budowy zostanie zbudowany najpierw nakładając następujące foldery:

PaidRelease -> /src/main + /src/paid 
PaidDebug -> /src/main + /src/paid + /src/debug/paid 

FreeRelease -> /src/main + /src/free 
FreeDebug -> /src/main + /src/free + /src/debug/free 

Answer 2

Zgodnie z można dodać nowy folder src/freeDebug/res lub src/paidRelease/res itp. W celu dostosowania poszczególnych atrybutów dla każdego wariantu konstrukcyjnego.

Answer 3

Struktura folderów podczas tworzenia budować warianty powinny być:

app 
    | 
    ->src 
     | 
     ->buildvariantname1(as defined in gradle) 
          | 
          ->java (follow the same structure here, as in main folder) 
          ->res (follow the same structure here, as in main folder)  

Teraz na wybranie specyficznych wariant, taki jak buildVariantname1debug, zostaną zaznaczone zmiany zapisane w folderze res w tym wariancie.

Nazwę aplikacji należy zdefiniować w pliku string.xml w folderze res-> values, aby nazwa aplikacji została pobrana w zależności od wartości w xml pod każdym wariantem kompilacji. To samo dotyczy ikon aplikacji.

Pierwszy obraz pokazuje, w jaki sposób zadeklarować wariantów wykonania (smaki z różnych nazw pakietów)

Drugi obraz pokazuje, w jaki sposób struktura projektu wygląda jeśli chcesz każdy smak mieć inny kod, kanału alfa i manifestuj się także. Należy pamiętać główną działalność zostanie usunięty z folderu głównego tak, że może istnieć w każdym z wariantów budowy