Bluetooth, Sensors & Auto Interview Questions
ADVANCED › Emerging
Walk me through the lifecycle of a BLE connection in a real app, from scanning through disconnection, and where things typically go wrong in production.
What a strong answer covers: A strong answer covers that BluetoothGattCallback methods land on a binder thread rather than the main thread, that gatt.close() must always be called on disconnect or the app leaks a system GATT client slot (the classic exhaustion bug after repeated connect attempts without cleanup), and that Android's BLE stack does not queue concurrent operations, so reads and writes must be serialized, waiting for each callback before issuing the next. It should also mention requesting a larger MTU for bigger payloads. The trap is treating GATT calls like fire-and-forget async network calls the way you would with Retrofit.
Why does battery life so often become a problem in apps using continuous sensors, like accelerometer-based motion detection, and what design choices actually move the needle?
What a strong answer covers: A strong answer names batching via registerListener's maxReportLatencyUs so the hardware FIFO buffer holds samples and wakes the CPU less often, preferring a low-power composite or hardware trigger sensor such as the step detector or significant motion sensor over raw accelerometer plus a custom algorithm, and unregistering promptly in onPause. It should also mention that Doze and background sensor restrictions on newer Android versions change what's even possible off-screen. The nuance a weak answer misses is that lowering the sample rate alone barely helps; the real lever is how often the CPU actually wakes up.
A product wants one app that runs both as a phone-projected Android Auto experience and natively on an Android Automotive OS head unit. What are the real architectural constraints, beyond just using the Car App Library?
What a strong answer covers: A strong answer explains that AAOS is a full standalone Android OS running directly on car hardware with no phone required, while Android Auto only projects UI from a connected phone, so an AAOS build must work without assuming a phone's auth session, connectivity, or data layer is present. The Car App Library templates handle the driver-distraction UI constraint, but the deeper design work is making the data and auth layers phone-independent, and testing across OEM head unit implementations that vary in behavior. The trap is treating AAOS as 'Android Auto but native' instead of a genuinely separate deployment target.