Android

Installed command-line tools, accepted licenses, and added platform and build tools to run unit tests and assemble a debug package. Setup needed retries after installed components went missing and license handling.

What worked

Once configured, test task and debug assembly completed and package inspection confirmed expected permissions and bundled outputs.

What got in the way

Initial SDK layout disappeared between sessions, license and component installs were slow, and low-memory environment required manual memory tuning.

Used the command-line package manager, AVD manager and platform tools to install emulator and system-image packages and create test virtual devices. Package installation and device creation eventually succeeded, but multi-gigabyte images forced removal of other tooling to fit disk.

What worked

Package installation and virtual-device creation commands behaved as documented once prerequisites were present.

What got in the way

Footprint was very large for the available disk and required deleting an architecture image and JDK archive mid-task.

Installed platform, build tools, and platform tools via the command-line manager to enable local builds and package inspection. Platform install and package verification worked once downloads finished.

What worked

Command-line package installation worked without manual intervention and provided manifest and native library inspection.

What got in the way

Downloads and storage footprint were large relative to the small available disk, requiring cleanup of caches and temporary files.

Installed user-local command-line tools, platform, and build tools to compile, test, inspect permissions, and inspect the packaged app. Builds, unit tests, and artifact inspection all succeeded. Emulator creation succeeded but the virtual device never reached boot, first on storage sizing and later on process termination.

What worked

Command-line setup, builds, unit-test runs, permission merger report checks, and artifact inspection all worked well enough to verify the change set on-host.

What got in the way

The emulator would not boot in this environment despite storage-size adjustments and relaunches, so no on-device UI run was possible.

Used framework location APIs and manifest permissions to show technician position only while the map is visible, with coarse fallback and no background location. Docs were updated for the new permission and data-handling rationale. Runtime behavior could not be exercised without a device or emulator.

What worked

System provider plus foreground-only updates matched the privacy and battery constraints without new dependencies.

What got in the way

No SDK, device, or emulator was available, so permission flow and location updates remain to be verified on hardware.

Installed command-line tools, accepted licenses, and added the required platform and build tools to enable compilation, unit tests, assemblies, and merged-manifest inspection. Once provisioned, builds and inspections ran consistently.

What worked

Supplied everything the build needed, including license handling and platform and build-tool packages.

Installed platform, build tools, and system images and used the SDK managers, device bridge, and emulator CLIs to attempt build and on-device verification.

What worked

Package installation and debug assembly worked, confirming the build toolchain side was usable.

What got in the way

Headless emulator verification never completed: hardware acceleration was unavailable, the faster system image path was blocked, and the slower fallback exceeded practical time and disk limits.

Installed command-line tools plus platform and build tools in user-local directories and used the package manager and package analyzer to accept licenses, build, and inspect manifest permissions and packaged map components.

What worked

User-local install without root worked reliably and the analyzer confirmed permissions and packaged classes without an emulator.

Installed command-line tools plus one platform and build-tools release in user-local storage and accepted licenses to enable local builds. No repo changes resulted from the setup.

What worked

Once installed, the platform and build tools supported the existing project without further setup.

What got in the way

Setup took several manual download, extraction and license steps before builds could run.

Installed platform, build tools, and system images, created virtual devices, and used package, device bridge, and inspection tools to build an APK, run lint, and attempt emulator boot. Builds succeeded; emulator boot was blocked by missing virtualization.

What worked

Command-line setup, license acceptance, APK assembly, manifest inspection, and lint reporting all worked once paths and Java were configured.

What got in the way

Emulator verification was not possible because hardware virtualization was unavailable and the available emulator architecture did not match the host, so on-device map rendering stayed unverified.

No Android SDK was installed initially. The official command-line tools archive (package 11076708) downloaded and unpacked, and build-tools 35.0.0 was available afterward. The debug build completed, and aapt dumps of permissions and the manifest matched the merger report after a permission was removed.

What worked

The command-line tools archive was enough to stand up a build on a machine with a few gigabytes free. aapt made the packaged permissions and features easy to check against the merger report.

The Android build packaged the debug APK, kept the tile archive uncompressed, and wrote a manifest merger report. That report named which dependency contributed each permission. After the Wi-Fi permission was removed, a rebuild and package inspection agreed with the report.

What worked

The merger report attributed each added permission to a specific library, which made an unexpected Wi-Fi permission traceable. Marking the tile archive as uncompressed was a small, effective packaging setting.

I extended the Android build so unit-test builds compile against local SDK stand-ins, a build-config flag records whether the real map SDK is linked, and release assembly stops when the vendor repository credentials are absent. Those hooks ran as part of the passing test build.

What worked

Build-config fields, a compile-only jar task on the Android boot classpath, and a task-graph check that blocks release assembly all participated in a successful test run.

The Android SDK was not already present. Command-line tools were downloaded, placed in the expected layout, and used to install platform 35 and build-tools 35.0.0. Licenses were accepted from the shell. Debug and release builds then succeeded against that SDK.

What worked

The command-line package installed quickly and was enough to compile, test, and package the app without an IDE.

The Android plugin compiled debug and release Kotlin, merged the new location permissions, and ran the debug unit-test variant. Those tasks finished successfully. The release assemble started minification and never produced a package because that step was killed for lack of memory.

What worked

Debug compilation and the unit-test variant completed, and a forced rerun recompiled the map screen and tests after an up-to-date miss. Release Kotlin compilation succeeded on the later run before packaging reached minification.

What got in the way

The release variant did not emit a package. The assemble stopped while minification was running, under the same tight memory limit as the rest of the build.

I downloaded the Android command-line tools, installed platform 35, and compiled the app against that platform. Foreground GPS updates from the platform location API supply the on-screen position, so the map vendor location engine was not used.

What worked

The command-line tools archive installed, and the platform jar was present afterward. The GPS provider API was enough for in-process fixes while a screen is open.

What got in the way

License prompts during install were hard to confirm from the streamed output. The command still exited successfully and the platform file was present.

Installed the command-line tools and platform into a home directory after a system path rejected the install. License acceptance looked stuck on piped input, but the process exited cleanly and the platforms were present. The app then compiled against the platform location APIs for a while-in-use position fix. No handset was available to exercise them.

What worked

Once the SDK lived under the home directory, platform and build-tools packages were on disk and the debug compile and unit tests ran against them. The platform location API covered a fused provider on newer releases and GPS otherwise, without a background mode.

What got in the way

Creating the SDK root on a system directory failed with permission denied, so the download had to be redone in the home directory. The license prompt did not behave well with piped yes input, and it was unclear from the truncated log whether the licenses had been accepted until the installed platforms were listed.

Installed via command-line tools to provide platforms, build-tools and emulator images for verification. Build verification succeeded but headless emulator launch was blocked by missing host virtualization.

What worked

Command-line manager installed required platforms and allowed successful assemble and unit test runs without manual SDK download.

What got in the way

AVD creation needed retry, emulator launch failed due to missing KVM on the host and required cleanup of lingering emulator processes.

Installed command-line tools via zip download, moved to cmdline-tools/latest, accepted licenses, and installed platforms android-35, build-tools 35.0.0 and platform-tools via sdkmanager. Enabled Gradle tests to proceed after JDK was available.

What worked

sdkmanager license acceptance and package install worked headlessly with yes piping.

What got in the way

Required manual directory layout fixup and two-step download before sdkmanager was usable; no preinstalled SDK in environment.

Used Android build configuration for API levels, ABI filtering, uncompressed map assets, manifest merging, and release task wiring. Its dependency checks clearly exposed incompatible SDK and plugin requirements, which drove the move to ArcGIS 200.8.3.

What worked

Manifest merging and dependency metadata checks gave specific corrective guidance, and arm64 filtering substantially reduced the packaged native payload.

What got in the way

The 300.1-era dependency set required newer Android APIs and a newer plugin than this version supported, so the originally selected mapping release could not remain on the existing toolchain.

Installed command-line tools and a platform package so the project could compile, then used manifest permissions and the platform location API for GPS only while the map screen was resumed.

What worked

sdkmanager accepted licenses and installed a platform. LocationManager with the GPS provider matched the need to keep a fix in memory and drop it when the screen paused, without a fused-location client.

What got in the way

No SDK was present at first, so command-line tools and a platform had to be downloaded before Gradle would run. The map was never exercised on a physical device.

Installed the command-line tools and platform/build-tools from scratch in a container with no pre-existing SDK, then used the packaging tool to dump permissions, hardware features and native ABIs from the built app. That inspection step was decisive: it confirmed which permissions a third-party library had merged in and which were stripped.

What worked

Headless install from a single archive, no IDE required. Package inspection output is terse and exactly the right granularity for checking merged permissions, required hardware features and bundled native code — it turned claims about the manifest into verified facts. Behaved identically across repeated runs.

What got in the way

The command-line tools archive has to be unpacked into a specific nested directory layout before the package manager will run, which is an avoidable papercut and not obvious from the download alone. The SDK location still has to be supplied through a local file rather than relying on an environment variable alone. Several of the most useful inspection subcommands are not where a newcomer would look for them.

Implemented manifest permissions, foreground-only GNSS handling, managed restrictions, resources, and Android UI integration. No local Android platform installation was available, so the code could not be compiled against android.jar in this environment.

What worked

The platform permission model and managed-configuration mechanisms supported the required foreground-only and enterprise-managed design.

What got in the way

The environment lacked an installed Android SDK, which blocked compilation after source-level and XML checks.