Android App & AOSP Embedded Development
Native Android apps, custom AOSP builds, and Android Things-generation embedded Android solutions — from Play Store consumer apps to kiosk-mode dedicated devices and custom launcher replacements.
What We Build on This Platform
Native Android Apps
Production Kotlin apps using Jetpack Compose for modern declarative UI, Android Architecture Components for lifecycle-safe state management, and Material Design 3 for consumer-facing Play Store distribution. Architecture is validated against the Android App Architecture guide with dependency injection via Hilt and background work via WorkManager.
AOSP Custom Builds
Full AOSP source tree builds with custom device trees, BSP integration for non-reference hardware, and proprietary driver integration from chipset vendors. Device tree configuration, kernel config adjustments, and vendor blob staging are performed for SBCs and custom SoCs where generic AOSP manifests do not produce a bootable image.
Kiosk & Dedicated Device
Android Device Owner mode configuration, custom launcher implementations, kiosk mode task locking, remote MDM policy management, and silent OTA update for commercial kiosk and point-of-sale deployments. Device Owner provisioning via QR code, NFC bump, or Zero-touch enrollment depending on the fleet deployment scale.
BLE & USB Host
Android BLE Central and Peripheral APIs for hardware accessory connectivity, USB Host API for direct peripheral communication via HID, CDC, and vendor-class descriptors, and AOA (Android Open Accessory) protocol for accessories that must power from the Android device USB port.
Android NDK & JNI
Native C/C++ code via NDK for DSP, image processing, cryptography, and hardware-specific operations that exceed what the ART JVM can provide within the latency and throughput budget. JNI bridging is designed with explicit ownership semantics to prevent the local/global reference leaks that are the dominant source of NDK memory defects.
Wear OS Apps
Wear OS companion apps and standalone Wear apps using Compose for Wear OS, Health Services API for sensor and activity data, and Horologist for watch face and complication development. Tile and complication surfaces are implemented alongside the main app interface for at-a-glance hardware data access.
Android Automotive OS
Android Automotive OS application development for in-vehicle infotainment systems, AAOS app store distribution, and Android Automotive Service integration for vehicle data access. Car App Library is used for phone-side apps that project to AAOS head units without a full AAOS port.
Remote OTA & Device Management
Custom OTA update infrastructure for non-GMS Android deployments, Android Enterprise MDM enrollment with Managed Google Play, Zero-touch enrollment configuration for large fleet deployments, and A/B partition update support for AOSP builds where recovery-mode OTA is not acceptable for field uptime requirements.
How Ankh Uses This Platform
Target Platform Decision: GMS vs. AOSP vs. Dedicated Device
GMS Android is chosen for Play Store distribution where Google services are required (Firebase, Maps, Push Notifications via FCM). AOSP is selected for kiosk and dedicated devices where Google services are not required or cannot be licensed — MADA licensing restrictions prevent AOSP manufacturers from bundling GMS without a signed agreement, which most custom hardware manufacturers cannot obtain. Custom AOSP BSP is required when the chipset is not a GMS-certified reference platform: Rockchip RK3588, Allwinner, and NXP i.MX series are common in custom hardware but require device-specific BSP work that generic AOSP build documentation does not cover. CTS/GTS certification scope is defined early to determine whether the product's hardware configuration can achieve certification or whether a certification exclusion is needed.
Architecture & Jetpack Stack
Architecture pattern is selected from MVVM with Jetpack ViewModel and StateFlow for most apps, or MVI for products with complex multi-step state machines where unidirectional data flow is worth the added boilerplate. Room database schema is designed for the data model, with explicit migration strategies defined before the first migration is needed — undocumented Room migrations are the leading cause of data loss in Android app updates. Navigation Component vs. Compose Navigation decision is made based on whether the app targets a minimum SDK below API 21 or requires custom animated transitions that Compose Navigation handles more cleanly. WorkManager is used for all deferrable background work without exception, as AsyncTask, plain Thread, and JobScheduler are each deprecated or unreliable across Android's battery optimization policies.
Hardware Interface Layer
BLE GATT client implementation includes connection retry logic with exponential backoff, GATT cache invalidation on reconnect to prevent stale characteristic reads after firmware updates, and explicit connection parameter request negotiation for high-throughput data transfer. USB Host API integration uses UsbManager.requestPermission for user-facing apps and Device Owner USB permission bypass for kiosk applications. Serial communication over USB CDC uses UsbManager with a CDC driver implementation, as Android does not expose a serial port abstraction at the SDK level. Audio HAL integration for custom audio hardware on AOSP builds requires modifying the audio policy configuration XML and implementing an audio HAL module if the hardware is not supported by an existing AOSP HAL.
AOSP Build & BSP Integration
Android repo manifest is configured to reference the chipset vendor's device tree repository alongside the AOSP platform source. Kernel configuration is adjusted from the reference BSP for the product hardware — unused drivers disabled to reduce image size and attack surface, GPIO assignments updated for the product PCB layout, and device tree source (DTS) modified for display, touch, and peripheral connections. init.rc service entries and device makefiles are configured for product-specific services. Proprietary blobs are staged from the vendor image using extract-files.sh patterns. AOSP build times of 40–90 minutes on a reference build server are reduced with ccache configuration and distributed build via distcc or a remote Gradle build cache.
Play Store & Enterprise Distribution
Play Store release track management follows a staged rollout: internal track for QA, closed alpha for beta hardware partners, open beta for early adopters, and production rollout at 1% → 10% → 50% → 100% with automated rollback triggers on crash rate thresholds from Firebase Crashlytics. Android App Bundle reduces APK size by delivering only the ABI, language, and density splits applicable to each device. Enterprise distribution via Managed Google Play supports Device Owner silent installation without user interaction. For AOSP kiosk deployments, a custom update server serves OTA packages verified against the device's signing key, with the update client polling on a configurable schedule and applying updates during the device's defined maintenance window.
Deep Technical Capability
AOSP BSP Development for Non-Reference Android Hardware
AOSP's published build instructions target a small set of Google-reference Pixel devices. Building for custom SoC hardware — Rockchip RK3588, NXP i.MX8, Allwinner T527 — requires a complete device tree: device-specific Makefile, BoardConfig.mk with partition layout and bootloader parameters, init.rc overrides for hardware-specific services, and a kernel defconfig that differs significantly from the vendor BSP's default. The Treble interface requirement (mandatory since Android 8) separates the vendor partition from the system partition, but many chipset vendors ship BSPs that violate Treble compliance in ways that block clean AOSP integration — vendor init scripts that modify /system, proprietary daemons that are statically linked against platform libraries rather than using the VNDK. Proprietary blob extraction from a running reference image using extract-files.sh captures the required vendor libraries, but blobs built for one Android version typically do not work against a newer AOSP system image due to ABI changes in the VNDK. Resolving these incompatibilities requires either negotiating updated blobs from the chipset vendor or implementing HIDL/AIDL wrapper interfaces that insulate the blob's ABI expectations from the updated system libraries.
Android BLE Reliability on Fragmented Hardware
Android BLE reliability is the most severe platform fragmentation problem in mobile hardware development. Samsung devices running One UI implement connection parameter negotiation differently from Pixel devices running stock Android; Qualcomm-based devices handle GATT cache expiry differently from MediaTek-based devices. The most common failure modes are stale GATT cache reads after device firmware updates (fixed by calling BluetoothGatt.refresh() via reflection on pre-API-33 devices or requestConnectionPriority to force re-discovery), MTU negotiation completing at 23 bytes on certain OEM devices even when the peripheral advertises 247-byte support, and connection interval negotiation being ignored on Exynos-based Samsung devices where the Broadcom BLE stack enforces its own minimum interval. A reliable BLE Android implementation requires a test matrix spanning at minimum Samsung Galaxy (Exynos and Qualcomm variants), Google Pixel, and one MediaTek-based device; emulators reproduce none of these OEM-specific failure modes. Connection retry logic must account for the GATT_ERROR status code (code 133) that Android returns for a broad class of connection failures unrelated to the error code's literal meaning.
Android Kiosk Mode and Device Owner Policy Enforcement
Android Device Owner (DO) mode grants the Device Policy Controller app a level of system control unavailable to normal applications. DO provisioning is initiated via QR code during device setup, NFC bump in the setup wizard, or Zero-touch enrollment for large fleets where per-device provisioning is impractical. Once provisioned, the DO app calls DevicePolicyManager.setLockTaskPackages() to restrict the device to a named app set — task locking is stricter than screen pinning and cannot be exited by the user. DISALLOW_FACTORY_RESET, DISALLOW_SAFE_BOOT, and DISALLOW_MOUNT_PHYSICAL_MEDIA prevent escape via hardware key combinations. Updating the Device Owner app on a locked fleet requires silent delivery via Managed Google Play or a package installer granted INSTALL_PACKAGES permission; the update must not change the signing key or package name, as Android will not silently replace a package with a different signer. A failed DO app update that crashes on launch can brick a kiosk with no physical access — a watchdog that rolls back to the previous APK on repeated crash is a production requirement, not an edge-case consideration.
Products Built on This Platform
POS & Kiosk Hardware
Custom Android launcher, Device Owner kiosk lockdown, and silent OTA for commercial kiosk deployments.
View ProductWearable Electronics
Wear OS companion apps and standalone Android wearable apps with Health Services integration.
View ProductFleet Telematics
Android-based in-vehicle telematics apps with BLE peripheral connectivity and background GPS logging.
View ProductPatient Safety
Android companion apps for clinical monitoring hardware with HealthConnect integration.
View ProductMedical Devices
AOSP-based Android builds for FDA-class medical hardware with controlled software environments.
View ProductGPS Tracking
Background location service Android apps with USB Host integration for vehicle tracking hardware.
View ProductAOSP builds for hardware that never ships with stock Android
Most Android BSP documentation assumes the developer is targeting a Pixel device or a certified GMS reference platform. Ankh's engineers have built AOSP images for custom hardware that starts with nothing more than a chipset vendor's SDK tarball, an incomplete device tree, and a kernel with several missing drivers. We know how to extract proprietary blobs from reference images, how to write the BoardConfig.mk and init.rc entries a custom device needs, and how to resolve the VNDK incompatibilities that appear when chipset vendor blobs built for Android 12 are integrated into an AOSP 14 build.
BLE integration tested across real device fragmentation, not emulators
The Android BLE fragmentation problem is not visible in an emulator and is not reproducible with a single reference device. Ankh maintains a test device matrix that covers the Bluetooth stack variants present in shipped Android hardware — Qualcomm WCN series, MediaTek MT series, and Samsung Exynos-paired Broadcom stacks each exhibit distinct GATT cache, MTU negotiation, and connection parameter behaviors. We test BLE firmware update sequences, high-throughput data transfer, and background reconnection on every device in the matrix before each release. When an OEM-specific failure mode appears in the field, we already know the diagnosis because we have seen it in the lab.
Kiosk deployments that stay locked down through OTA updates
The most dangerous moment in a kiosk Android deployment is the OTA update. An update that successfully locks down a new device provisioned from scratch can fail silently on an existing fleet device with a different OS build, leaving the device in a partially-configured state that presents a maintenance window to users. Ankh builds kiosk OTA pipelines with staged rollout, post-update attestation that verifies Device Owner policy enforcement is intact, and automatic rollback on failed attestation. We have deployed Android kiosk updates to fleets of thousands of devices in geographically distributed locations where physical remediation of a failed update is prohibitively expensive.