Content Providers & Broadcasts Interview Questions
ANDROID › Components
In your own words, walk me through when you'd actually reach for a ContentProvider versus just exposing a Room database or a repository class directly. What's the real reason ContentProvider still exists?
What a strong answer covers: ContentProvider exists specifically for cross-process or cross-app data sharing, it's the only first-class IPC-safe way to expose structured data via a stable content:// URI contract, support cursor-based paging, participate in the per-URI permission model, and back things like search suggestions, widgets, or sync adapters without either side depending on the other's concrete classes. If the data never leaves your own process, a Room database or repository behind a ViewModel is simpler and avoids the IPC and serialization overhead a ContentProvider always pays; a strong answer explicitly says the only real reason to reach for it today is cross-app sharing, not general data access.
Ordered broadcasts let a receiver call abortBroadcast() to stop propagation. What's a legitimate use case for that, and why is it risky to depend on broadcast ordering or priority in production code?
What a strong answer covers: A legitimate use is a chain of receivers cooperatively deciding whether an event should proceed, like a security or parental-control receiver inspecting an incoming SMS and aborting further delivery, or a receiver modifying result data before a lower-priority receiver sees it. It's risky in production because priority ordering between receivers declared by different apps is effectively unenforceable and unpredictable at scale, you don't control what other apps declare, and Android has steadily restricted implicit broadcasts anyway; ordered broadcasts are really only safe to rely on within your own app's receivers where you control both ends.
You're reviewing a PR where a BroadcastReceiver does a network call directly inside onReceive(). What's wrong with this, and what would you tell them to do instead, given the constraints on receivers?
What a strong answer covers: onReceive() runs on the main thread with a strict lifetime, the system can kill the receiver and there's no guarantee of more than a few seconds before it's treated like an ANR, so a synchronous network call blocks the main thread and will very likely ANR or get killed mid-request before it returns. The fix is to keep onReceive() itself tiny: enqueue the real work to WorkManager if it can be deferred, or call goAsync() to get a PendingResult with roughly 10 extra seconds if the work is short enough to finish inline, handing off to a coroutine or thread from there and explicitly calling PendingResult.finish() when done.