Android Setup

Prepare the Android build environment

The recorded Android project uses Kotlin and Jetpack Compose with a Gradle wrapper. Its review environment calls for JDK 17, Android SDK platform 35, AGP 8.7.3 and Gradle 8.9. The project's pinned build files are the authority for a specific checkout. Do not replace them with the latest versions from unrelated tutorials merely to resolve a runtime wallet problem.

Install the required pieces

Install Android Studio or a command-line SDK environment from official Android distribution channels. Ensure Java points to a JDK compatible with the pinned Android Gradle Plugin. Install the compile platform and build tools requested by the build. Android Studio can configure the SDK path for the checkout; command-line users can create local.properties with sdk.dir after inspecting whether that file already exists. Keep machine-specific paths out of commits.

java -version
bash gradlew --version
bash gradlew --no-daemon :app:testDebugUnitTest :app:lintDebug :app:assembleDebug

The wrapper may need network access the first time. A failure to download Gradle or Maven dependencies is an environment failure, not a passing or failing application test. Preserve the exact failing command and error. Do not claim the suite passed because the same revision reportedly passed elsewhere. Cached artifacts can help repeat a build, but they should not hide which dependencies were actually resolved.

Avoid unnecessary dependency changes

The Mobile Wallet Adapter dependency already exists in the Android candidate. Official Kotlin documentation names the com.solanamobile client artifacts; older copied examples containing fictional package names should not be added. A dependency upgrade needs its own compatibility review and gate. Adding a web-wallet package to an Android project does not create a local wallet application or repair a dropped authorization result.

Use the repository's conservative memory settings when the build host has limited RAM. If Gradle exits for memory pressure, check available memory, worker counts and concurrent workloads. Do not immediately raise heap settings beyond what the machine can supply. Keep a record of changes that affect reproducibility, especially when a developer compares build behavior between a PC and a laptop.

Separate build tools from runtime tools

A successful Gradle build does not imply an emulator can boot. The build uses Java and Android compilation tools; an accelerated emulator additionally depends on host virtualization and graphics support. Conversely, a running emulator can install an APK without proving that the source gate passed. Treat those as two independent preparations. This distinction prevents the mistaken claim that a working build guarantees a working KVM stack.

The historical APK is debug-signed. Installing it over another package with a different certificate can fail, and uninstalling removes app data and device-bound keys. On a fresh test emulator that may be acceptable, but it should never be presented as a harmless routine step for an existing installation. Prefer a separate test environment when preserving receipts, vault contents or durable operations matters.

Verify the result

Locate app/build/outputs/apk/debug/app-debug.apk after a successful assemble task. Record its size and hash. Read the test results and lint report, including skipped tests. If the gate generated evidence under a commit-specific directory, inspect what it actually copied; do not assume an independent checker suite was collected by the Android script. The setup is complete when its output is identifiable and its missing checks are documented, not when a terminal simply stops printing errors.

---

Wiki home · Qualification updates · Sources and credits