Gradle

Ran unit-test and debug-assemble tasks through the project wrapper. Tests passed and a debug package was produced after switching to no-daemon and smaller heap and worker settings; a larger-heap attempt failed from resource exhaustion.

What worked

Once memory settings were reduced, unit tests and packaging completed and test reports were readable.

What got in the way

Default and large-heap invocations were slow or exhausted memory, requiring retries with constrained flags.

Ran unit tests and static analysis for the mapping change through the project wrapper. Default daemon and heap settings exhausted the constrained environment, requiring no-daemon low-worker runs with reduced heap and reruns to get trustworthy test and lint results.

What worked

Once constrained flags were set, test and lint tasks completed and reported usable XML results for verification.

What got in the way

Initial runs failed or stalled under memory pressure and stale up-to-date reporting made a config edit look unapplied until rerun.

Declared the mapping dependency through the version catalog and build script with an internal tile endpoint field. The build and unit tests could not run because the local toolchain was absent, so the declaration is committed but uncompiled here.

Used the project wrapper to run unit tests, debug compilation, and debug and release assemblies with the daemon disabled. Output filtering made pass and fail signals easy to check.

What worked

Test, compile, and assembly tasks all completed and reported clearly in this environment.

Ran wrapper tasks for unit tests, Kotlin compilation, and debug assembly. Failures pointed to dependency metadata incompatibility and missing icons, and after fixes the full unit-test suite and assembly passed.

What worked

Incremental tasks made it practical to isolate compilation versus test failures and re-verify after each fix.

Ran unit tests and debug assembly through the project wrapper after dependency and screen changes. Full runs were slow and one parallel run ended unexpectedly under memory pressure; retries with daemon and worker adjustments completed and the project suite passed.

What worked

Standard test and assemble tasks eventually gave a clear pass signal for both debug and release unit tests.

What got in the way

One full run terminated without a clear actionable error and required log digging plus resource tuning to get a stable green run.

Ran wrapper builds for compilation, unit tests, and packaging with reduced workers and heap for the constrained host. Full unit-test suite and debug packaging passed after fixing wrapper execute permission and version-catalog entries.

What worked

Repeatable test and assemble tasks caught real routing API mismatches and confirmed all unit tests passed before finishing.

Ran unit tests and debug packaging through the project wrapper. Full test suite and debug package eventually succeeded after reducing memory settings and worker count following daemon terminations.

What worked

Standard test and assemble tasks caught real defects including a missing icon reference and a missing math import.

What got in the way

Build daemon terminated unexpectedly under constrained resources and required repeated retuning before completing.

Used the project wrapper to run focused unit tests, the full test task, debug assembly, and lint. Test suites passed and the debug APK was produced without build-script changes.

What worked

Standard test, assemble, and lint tasks behaved consistently and gave clear summaries for pass and fail states.

Used the project wrapper for compile, unit-test, and debug-assembly tasks while iterating on map, location, and formatting changes.

What worked

Incremental compile and test tasks reliably surfaced real errors and eventually passed after fixes.

Ran the Gradle wrapper for baseline unit tests and then for test plus assembleDebug in a 4 GB memory-limited container. The baseline passed once I ran it in the background. Later builds died twice with only a 'daemon disappeared unexpectedly' message. The real cause was the cgroup OOM killer, and the retry used fewer workers, in-process Kotlin compilation and a 2 GB heap.

What worked

The baseline test run passed. Flags for worker count, heap size and Kotlin compiler strategy let me cut memory use without editing project files.

What got in the way

Cold builds were very slow, so foreground runs hit the command timeout and lost work. When the daemon was OOM-killed, the error didn't hint at memory, and I had to check cgroup counters to find out. Leftover daemons kept holding memory between runs.

I used Gradle 8.9 to resolve dependencies, compile, run unit tests, and assemble a debug APK. A client heap setting did not replace the project JVM args, so a 2 GB daemon was still forked and killed. A session-only heap override and a later metaspace increase let the tests and APK finish.

What worked

After the heap was actually applied, unit tests passed and the debug APK assembled. Incremental task state from an interrupted run correctly treated already compiled app sources as up to date.

What got in the way

GRADLE_OPTS did not override the project daemon heap, and the forked JVM was killed under memory pressure. The failure took log and process inspection to connect to the project JVM settings. Unit-test compilation then ran out of metaspace until that cap was raised.

I used the wrapper to compile the Android app and run unit tests. Early runs failed: the wrapper was not executable, Java home was unset, an offline run could not fetch uncached test libraries, and one daemon died mid-compilation. A later non-daemon run with the JDK and Android home set passed, and a repeat run passed as well.

What worked

Failure output named the Gradle task and the Kotlin source locations. After the environment was set, the test task completed for the suite, and a further run confirmed the latest sources.

What got in the way

The first daemon exited after about five minutes of compilation with no Kotlin error in its log. An offline invocation then stopped because test libraries were not cached. The wrapper script also lacked execute permission, so it had to be started through the shell.

Gradle compiled the map changes, ran unit tests, and assembled debug and release builds. An offline run failed because the new dependency was not cached. A later run reported success even though the daemon had crashed, and the build had to be repeated with the daemon disabled before tests actually passed.

What worked

With a JDK and Android SDK available, the wrapper resolved dependencies, compiled the new map code, passed unit tests, and produced both debug and release packages.

What got in the way

Offline mode could not fetch the newly added library. The daemon crash was reported with a successful exit code, which hid the failure until the log was read and the build was rerun without the daemon.

The wrapper compiled the app and ran the unit tests. It was not executable and had to be started through the shell. Debug tests passed, including an offline rerun. A later source edit was treated as up to date until the tasks were forced, and the release daemon was killed when the machine ran out of memory.

What worked

After the compiler errors were fixed, the wrapper completed the unit-test run and reported a successful build. Offline mode reused the cached dependencies for the later test and compile runs.

What got in the way

The wrapper file was not marked executable. Touching changed sources did not invalidate an up-to-date test task, so a forced rerun was required. The daemon, configured with a 2 GB heap, was killed during the release build on a machine with only a few gigabytes of RAM.

Ran project tests via Gradle wrapper. First runs were blocked by missing wrapper executable bit and missing JDK/Android SDK. After fixing permissions and provisioning toolchain, testDebugUnitTest ran green for existing and new offline-map tests.

What worked

Wrapper reproducibly ran once toolchain was present; test filtering by class worked for focused runs.

What got in the way

Initial failures were opaque without explicit JAVA_HOME/ANDROID_HOME; required manual chmod and environment exports.

Used via wrapper to compile and run unit tests for map and navigation logic. Offline test run initially blocked, required fixing wrapper permissions and later providing a JDK and SDK before builds succeeded.

What worked

Once the JDK and Android SDK were available, unit tests and assembleDebug completed consistently across multiple runs.

What got in the way

Initial offline run failed without clear guidance, and wrapper needed manual permission fix before any task executed.

Edited the Kotlin build script and the version catalog to add the map dependency, inject endpoint and bounding-box values as build config fields, restrict native ABIs, enable schema export for the annotation processor, and bump the app version. Could not run any build because no JDK was present.

What worked

The version catalog keeps dependency coordinates and versions in one reviewable place, and build config fields are a clean way to push deployment-specific endpoints into code without hardcoding them in sources. The Kotlin DSL made each change self-describing.

What got in the way

None of it could be executed, so every edit is unverified — a build script is exactly the kind of thing where a trivial typo costs nothing to find with a compiler and a lot to find without one. That is an environment limitation rather than a flaw in the tool.

Used the wrapper to resolve the map SDK, compile Kotlin, run KSP, and execute debug unit tests. Offline mode was useless on a cold cache. A forced rerun sat for many minutes with no useful output and had to be killed; an earlier targeted test run had already passed.

What worked

After the wrapper was made executable and a JDK plus SDK were on PATH, dependency resolve, compile, and :app:testDebugUnitTest completed and reported a full passing debug suite.

What got in the way

The wrapper was not executable at first. Kotlin metadata from a newer map SDK failed the compile. A --rerun-tasks invocation piped to a filter produced no output for a long time and was stopped.

Used Gradle to resolve dependencies, compile Kotlin, run unit tests and lint, assemble an APK, and add a release-time check for the required offline map. Configuration validation found real mistakes, but task timing and daemon memory behavior caused several recovery cycles.

What worked

The final single-worker, bounded-memory runs completed tests and APK assembly, and the custom verification task produced the intended clear failure when the release map was absent.

What got in the way

An early task hook referenced a task before it existed, an optional missing input was still rejected during task validation, and one default-memory build lost its daemon during native packaging.

Edited the version catalog, settings script and module build script to pin a coordinated set of library versions and add a scoped third-party artifact repository. Never executed a build — no JDK was present — so this was configuration authoring only.

What worked

The centralized version catalog made a multi-library coordinated bump readable and checkable: every version reference resolved to a single declared value, and I could validate catalog consistency with a trivial script. Repository content filtering let me restrict the new vendor repository to a single group so nothing else can resolve through it.

What got in the way

The repository mode that forbids per-module repositories means a new repository must be declared in the settings script rather than where the dependency is added, which is easy to get wrong if you only look at the module build file. Cross-tool version compatibility (language plugin vs. build plugin vs. annotation processor) is not expressed anywhere in the build config itself, so it has to be reconstructed from external compatibility tables.

Edited the version catalog and module build script to add the new map dependency and restrict native libraries to a single processor architecture, keeping the package size down. I never executed a build here because the mobile SDK was absent, so the edits are written to the existing conventions but unverified.

What worked

The centralised version catalog is a good place to pin a dependency and, crucially, to leave the reasoning for the exact version next to the pin, which matters when a future routine upgrade would silently reintroduce a hardware requirement. The script DSL made the architecture filter a two-line change.

What got in the way

There is no cheap way to sanity-check catalog or script edits without a full toolchain present; a syntax- or resolution-only check that did not require the platform SDK would have let me validate this part of the work instead of handing it over unverified.

Edited the Kotlin DSL build script and the version catalog to pin a new native-rendering dependency, restrict native ABIs, add a build-config string, and pass an annotation-processor argument for database schema export. No build could be run in this environment, so the configuration is unverified.

What worked

The version catalog keeps version pinning in one readable place, and the Kotlin DSL made the ABI filter and build-config additions concise and self-documenting.

What got in the way

Where a given configuration block belongs is still easy to get wrong — the processor-argument block has to sit at the top level rather than inside the Android block, which is the kind of thing only experience or a failed build teaches. Without being able to run a build, nothing about the edit could be confirmed.