feat(android): --gradleFlavor to build a product flavor

[farfromrefug]

What

An app that declares product flavors in its gradle configuration has no way to tell the CLI which one to build. The task name is built as:

const baseTaskName = buildData.androidBundle ? "bundle" : "assemble";

so the CLI always asks for assembleDebug/assembleRelease — which gradle rejects once flavors exist, because there is no flavourless variant to assemble.

--gradleFlavor foo inserts the flavor into the task name:

ns build android --gradleFlavor foo --release   # assembleFooRelease
ns run android --gradleFlavor foo               # assembleFooDebug
ns build android --gradleFlavor foo --aab       # bundleFooRelease

The flavor is capitalized to match gradle's task naming, and a flavor that is already capitalized is left alone.

Build output

No special handling needed. A flavored build lands in build/outputs/apk/<flavor>/<buildType> with a name like app-foo-debug.apk. getAllAppPackages already falls back to a recursive walk of the output directory, and the android getValidBuildOutputData regex is

(<packageName>|app)-.*-(Debug|Release)(-unsigned)?\.apk

which matches the flavored name as is.

Tests

npm test — 1860 passing. Added cases in test/services/android/gradle-build-args-service.ts for the debug, release, app bundle and already-capitalized forms.

Notes

From https://github.com/Akylas/nativescript-cli. Independent of #6129, #6130, #6131 and #6132, though it adds an option next to gradlePath in lib/options.ts like some of those do — expect a small textual conflict depending on merge order.

[coderabbitai]

Warning

Review limit reached

@farfromrefug, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 31 minutes

Limit details: You’ve used all 4 included reviews currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: de8058c1-0846-40f0-b866-df5a97e3ea66

📥 Commits

Reviewing files that changed from the base of the PR and between 2f9f2e0 and c6a6a97.

📒 Files selected for processing (9)

• docs/man_pages/project/testing/build-android.md
• docs/man_pages/project/testing/debug-android.md
• docs/man_pages/project/testing/run-android.md
• lib/data/build-data.ts
• lib/declarations.d.ts
• lib/definitions/build.d.ts
• lib/options.ts
• lib/services/android/gradle-build-args-service.ts
• test/services/android/gradle-build-args-service.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}