-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add android documentation for use Flaker with multiple build variants
- Loading branch information
danil
committed
Apr 13, 2024
1 parent
831ddc2
commit a459be6
Showing
1 changed file
with
42 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
# Usage | ||
|
||
## Setting Up Flaker with Multiple Variants on Android | ||
|
||
When integrating Flaker into an Android project that includes more than just the standard debug and release variants, it's essential to configure Flaker to handle these additional variants properly. | ||
One crucial aspect of this configuration is using matchingFallbacks in your project's build.gradle file. Here's why and how you should do it: | ||
|
||
### Why Use matchingFallbacks? | ||
|
||
Android projects often include custom build types or flavors, which may not directly match those of the dependencies they rely on. When Flaker attempts to match variants between your app and its dependencies, it may encounter situations where a direct match is not possible due to differences in build types or flavors. In such cases, matchingFallbacks provides a mechanism to specify alternative matches, ensuring proper variant resolution. | ||
|
||
### Adding matchingFallbacks to Your Project | ||
|
||
To ensure Flaker handles multiple variants correctly in your project, you should add matchingFallbacks to your project's build.gradle file, specifying fallback build types or flavors that Flaker should try when direct matches are unavailable. Here's how you can do it: | ||
|
||
#### 1) Build Type | ||
```kotlin | ||
android { | ||
buildTypes { | ||
release { | ||
} | ||
stage { | ||
matchingFallbacks = ['debug', 'qa', 'release'] | ||
} | ||
} | ||
} | ||
``` | ||
|
||
#### 2) Product Flavor | ||
```kotlin | ||
android { | ||
productFlavors { | ||
create("paid") { | ||
dimension = "tier" | ||
} | ||
create("free") { | ||
dimension = "tier" | ||
matchingFallbacks += listOf("demo", "trial") | ||
} | ||
} | ||
} | ||
``` |