Hello friends, Thanks for reading my previous post on HB Blog 141: Android Configure Build Variants - Part 1.
This post will show you how you can configure build variants to create different versions of your app from a single project, and how to properly manage your dependencies and signing configurations.
Build variants are the result of Gradle using a specific set of rules to combine settings, code, and resources configured in your build types and product flavors. Although you do not configure build variants directly, you do configure the build types and product flavors that form them. Each build variant represents a different version of your app that you can build. For example, you might want to build one version of your app that's free, with a limited set of content, and another paid version that includes more. You can also build different versions of your app that target different devices, based on API level or other device variations.
Refer the below link for complete sample code:-
Download Sample Code
Have a look on few code snippets,
//build.gradle
Build variants are the result of Gradle using a specific set of rules to combine settings, code, and resources configured in your build types and product flavors. Although you do not configure build variants directly, you do configure the build types and product flavors that form them. Each build variant represents a different version of your app that you can build. For example, you might want to build one version of your app that's free, with a limited set of content, and another paid version that includes more. You can also build different versions of your app that target different devices, based on API level or other device variations.
Refer the below link for complete sample code:-
Download Sample Code
Have a look on few code snippets,
//build.gradle
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 | apply plugin: 'com.android.application' android { compileSdkVersion 25 buildToolsVersion "25.0.2" defaultConfig { applicationId "com.harshalbenake.buildvariant" minSdkVersion 15 targetSdkVersion 25 versionCode 1 versionName "1.0" } /** * The following sample specifies an applicationIdSuffix for the debug build type, * and configures a "jnidebug" build type that is initialized using settings from * the debug build type. */ buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } debug { applicationIdSuffix ".debug" } /** * The 'initWith' property allows you to copy configurations from other build types, * so you don't have to configure one from the beginning. You can then configure * just the settings you want to change. The following line initializes * 'jnidebug' using the debug build type, and changes only the * applicationIdSuffix and versionNameSuffix settings. */ jnidebug { // This copies the debuggable attribute and debug signing configurations. initWith debug applicationIdSuffix ".jnidebug" jniDebuggable true } } // Specifies the flavor dimensions you want to use. The order in which you // list each dimension determines its priority, from highest to lowest, // when Gradle merges variant sources and configurations. You must assign // each product flavor you configure to one of the flavor dimensions. flavorDimensions "api", "mode" /** * The following code sample creates "demo" and "full" product flavors * which provide their own applicationIdSuffix and versionNameSuffix. * The following code sample uses the flavorDimensions property * to create a "mode" flavor dimension to group the "full" and "demo" product flavors, * and an "api" flavor dimension to group product flavor configurations based on API level */ productFlavors { demo { applicationIdSuffix ".demo" versionNameSuffix "-demo" // Assigns this product flavor to the "mode" flavor dimension. dimension "mode" resValue "string", "app_name", "HB Demo" } full { applicationIdSuffix ".full" versionNameSuffix "-full" dimension "mode" resValue "string", "app_name", "HB Full" } // Configurations in the "api" product flavors override those in "mode" // flavors and the defaultConfig block. Gradle determines the priority // between flavor dimensions based on the order in which they appear next // to the flavorDimensions property above--the first dimension has a higher // priority than the second, and so on. minApi24 { dimension "api" minSdkVersion '24' // To ensure the target device receives the version of the app with // the highest compatible API level, assign version codes in increasing // value with API level. To learn more about assigning version codes to // support app updates and uploading to Google Play, read Multiple APK Support versionCode 30000 + android.defaultConfig.versionCode versionNameSuffix "-minApi24" } minApi23 { dimension "api" minSdkVersion '23' versionCode 20000 + android.defaultConfig.versionCode versionNameSuffix "-minApi23" } minApi21 { dimension "api" minSdkVersion '21' versionCode 10000 + android.defaultConfig.versionCode versionNameSuffix "-minApi21" } } /** * Using the build configuration from the previous section as an example, * suppose you plan to support only API levels 23 and higher for the demo version of the app. * You can use the variantFilter block to filter out all build variant configurations that * combine the "minApi21" and "demo" product flavors. */ variantFilter { variant -> def names = variant.flavors*.name // To check for a certain build type, use variant.buildType.name == "<buildType>" if (names.contains("minApi23") && names.contains("full")) { // Gradle ignores any variants that satisfy the conditions above. setIgnore(true) } } } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:25.3.1' } |
No comments:
Post a Comment