Android Automation Engineer

About the role
We operate a fleet of company-owned Android devices that run automated workflows: capturing notifications, reading on-screen state from apps and pushing structured events into our backend. We are looking for an engineer who lives inside the Android runtime rather than on top of it, and who can keep a large device fleet running reliably without babysitting. This is not a standard app development role. There is no design handoff and very little UI work. The job is making Android do things it was not really built to do, at scale, and keeping it stable across OEMs and OS versions. What you will own
- Build and maintain an AccessibilityService that traverses node trees across third-party apps and emits reliable, structured events
- Build and maintain a NotificationListenerService that captures, parses and deduplicates notifications across apps
- Write and maintain versioned selector maps so that a UI change in a target app degrades gracefully instead of breaking the fleet silently
- Manage a fleet of 50 to 200 physical devices over ADB: provisioning, health checks, remote restarts, log collection, session recovery
- Keep services alive under Doze, battery optimisation and aggressive OEM process killers (Xiaomi, Oppo, Vivo, Samsung)
- Build the on-device data pipeline: local buffering, dedupe, idempotent delivery, retry, backpressure when the network is unavailable
- Own observability: per-device heartbeats, capture success rates, alerting when a device silently stops reporting Desired Candidate Profile Must have ADB and fleet operations
- Deep command-line ADB: shell, uiautomator dump, input, dumpsys, logcat filtering, pm, am, ADB over TCP/IP
- Experience running an ADB server against many devices at once, including the failure modes: offline devices, unauthorised states, USB hub flakiness, server crashes
- scrcpy, Appium or UiAutomator2 in a real operational setting, not just a demo AccessibilityService
- Strong practical command of AccessibilityNodeInfo traversal, node recycling and stale-node handling
- Knows which event types to subscribe to and why: TYPE_WINDOW_CONTENT_CHANGED, TYPE_WINDOW_STATE_CHANGED, TYPE_VIEW_SCROLLED, and how to avoid drowning in event volume
- Has dealt with sparse or hostile node trees: Jetpack Compose semantics, WebView content, canvas-drawn UI, apps with FLAG_SECURE
- dispatchGesture, focus handling and the limits of programmatic interaction on modern Android NotificationListenerService
- StatusBarNotification extras parsing, MessagingStyle, grouped and bundled notifications, RemoteViews fallback when extras are empty
- Handling reposts, updates and cancellations without producing duplicate events Platform
- Kotlin, coroutines, foreground services, WorkManager, Room
- Concrete knowledge of what changed and broke across Android 11 through 16: package visibility, foreground service types, notification permission, restricted settings for sideloaded apps
- Comfortable with rooted and non-rooted device workflows, custom ROMs, and knowing when root is the wrong answer Nice to have
- Python or Node tooling around the ADB layer for orchestration
- Frida, Xposed or LSPosed familiarity
- Experience with MDM, kiosk mode or Android Enterprise device owner provisioning
- Prior work on a device farm, QA automation lab or RPA product