feat(android): generate BuildConfig.java per variant with default + user fields

.github/workflows/plugin-build.yml

@@ -943,7 +943,7 @@ jobs:
           }
           first="$(build)"
           echo "$first"
-          grep -q '18 ran, 0 up-to-date' <<<"$first"
+          grep -q '20 ran, 0 up-to-date' <<<"$first"
           # The apk is complete: manifest, merged resources, resource table,
           # and the dex grafted onto the aapt2 output.
           unzip -l /tmp/android/build/android/debug/app-debug.apk > /tmp/android/apk.list
@@ -956,15 +956,15 @@ jobs:
           # up-to-date: derived paths resolve against the injected
           # projectDir, never the invocation directory.
           cd /
-          grep -q '0 ran, 18 up-to-date' <<<"$(build)"
+          grep -q '0 ran, 20 up-to-date' <<<"$(build)"
           # A resource change reruns the resource chain and everything that
-          # consumes it, but not the mkdirs.
+          # consumes it, but not the mkdirs or BuildConfig generation.
           cd /tmp/android
           sed -i 's/Uliab CI Example/Uliab CI Example v2/' res/values/strings.xml
-          grep -q '13 ran, 5 up-to-date' <<<"$(build)"
+          grep -q '13 ran, 7 up-to-date' <<<"$(build)"
           # A source change reruns compile and the dex/package chain only.
           sed -i 's|setContentView(R.layout.activity_main);|setContentView(R.layout.activity_main); // v2|' src/Main.java
-          grep -q '8 ran, 10 up-to-date' <<<"$(build)"
+          grep -q '8 ran, 12 up-to-date' <<<"$(build)"
           # A compile level the SDK does not have must fail configure, not
           # javac, proving discovery ran inside the plugin.
           sed -i 's/compileSdk = 36/compileSdk = 99/' build.ulb
@@ -1057,7 +1057,7 @@ jobs:
           }
           first_kt="$(build_kt)"
           echo "$first_kt"
-          grep -q '20 ran, 0 up-to-date' <<<"$first_kt"
+          grep -q '22 ran, 0 up-to-date' <<<"$first_kt"
           unzip -l /tmp/android-kt/build/android/debug/app-debug.apk > /tmp/android-kt/apk.list
           grep -q 'AndroidManifest.xml' /tmp/android-kt/apk.list
           grep -q 'classes.dex' /tmp/android-kt/apk.list

PROGRESS.md

@@ -26,12 +26,12 @@
 - [x] `ulite/android` — Kotlin support (2026-08-22): the android-plugin crate (0.3.0, ABI 0.7) now compiles mixed Java+Kotlin and Kotlin-only modules. `sources` accepts both `.java` and `.kt` files. `partition_sources` splits them; `compileJava` (javac, always registered) compiles user `.java` plus the aapt2-generated `R.java`; `compileKotlin` (kotlinc, registered when `.kt` sources exist) depends on `compileJava` and sees the classes dir on its classpath so it resolves the module's own Java classes and R references. The manifest declares `kotlinc`. `reject_unknown_extensions` accepts `.java` and `.kt`. 30 unit tests (added `partition_sources` edge cases, `kotlinc_android_args` invocation tests), clippy/fmt clean. CI `android-build` gains a Kotlin-only end-to-end scenario: `.kt` source referencing `R.layout`, full packaging chain, APK contains `classes.dex`.
 - [x] `ulite/android` Kotlin review fixes (2026-08-22): (1) CI workflow uses `$GITHUB_WORKSPACE` absolute path for plugin wasm copy (was relative `../ulb-plugins/` which failed after `cd /tmp/android`), (2) CI adds DEX-level assertion verifying `Lcom/example/ulite/Main;` class is present in the packaged dex (not just that `classes.dex` exists), (3) `d8_args` accepts `extra_jars` parameter; when Kotlin sources exist, `kotlin-stdlib.jar` is resolved from the compile classpath and included in D8 program inputs so the APK contains Kotlin runtime classes, (4) compile order documented — Java compiles before Kotlin because R.java must be compiled first for kotlinc to resolve R.* references; mutual Java↔Kotlin references beyond R.java need multi-pass compilation (future work). 31 android plugin unit tests, clippy/fmt clean.
 - [x] `ulite/android` — Compose compiler plugin support (2026-08-22): the android-plugin crate reads a `compose = true` key inside the `android {}` block. When enabled, the compose compiler plugin JAR is located on the compile classpath via `find_compose_compiler_jar` and loaded via `-Xplugin=<path>` — the standard Kotlin CLI contract for compiler plugins. The kmp plugin parses `android.compose` from its config and applies the same mechanism. The `d8_merge_args` function gains an `extra_jars` parameter for kotlin-stdlib inclusion in the kmp mergeDex task, and the extra JARs are declared as task inputs for proper fingerprinting. 7 unit tests added for compose flag parsing, JAR discovery, and kotlinc arg generation (`bool_value` helper for optional boolean keys). 39 android + 14 jvm + 24 kmp = 77 tests, clippy/fmt clean.
+- [x] `ulite/android` — BuildConfig generation (2026-08-25): the android-plugin crate (ABI 0.7) generates a `BuildConfig.java` source file per variant during configure. Nine default fields (APPLICATION_ID, BUILD_TYPE, DEBUG, FLAVOR, VERSION_CODE, VERSION_NAME, MIN_SDK_VERSION, TARGET_SDK_VERSION, COMPILE_SDK_VERSION) are populated from the `android {}` block and variant's effective values. User-defined fields are declared via `buildConfigField ["type", "name", "initializer"]` list triples inside the `android {}` block. The generated file lives at `<build>/<variant>/generated/buildconfig/<namespace>/BuildConfig.java` and is added to `javac`'s `-sourcepath` so it resolves at compile time. Task `generateBuildConfig<V>` depends on `prepareBuildDir` and is a dependency of `compileJava<V>`. Also fixed `merge_variant_sources` to resolve base paths before deduplication. 50 android plugin tests, clippy/fmt clean.
 
 ## Next up (priority order)
 1. `ulite/kmp` — per-target `implementation`/`api` deps scopes: source-set `deps {}` currently resolve every declaration onto the source set's single classpath; scoping by target is future work
 2. `ulite/android` — Compose runtime dependency wiring and BOM support
 3. `ulite/android` — per-variant source-set layering (androidMain vs debug vs release source-set overrides)
-4. `ulite/android` — BuildConfig generation from build metadata
 
 ## Observed issues (not fixed, noted for later)
 - The `jvm` plugin writes KSP's `-java-output-dir` but has no way to compile the generated Java: `kotlinc` (2.2.0, on this JDK) emits no classes for `.java` sources in any invocation shape tested, and `javac` requires an explicit file list that a task's static inputs cannot enumerate after KSP has run. Documented in REFERENCE.md; a mixed module's javac task could adopt `-sourcepath <generated java dir>` so referenced generated Java compiles — not wired yet.