Intents & Deep Linking Interview Questions
ANDROID › Components
Walk me through why Android makes a hard distinction between explicit and implicit intents, rather than just always resolving by action and data like a URL router. What's the security reasoning?
What a strong answer covers: Implicit intents let the OS or other apps resolve 'any app that can handle sharing text' without your app knowing who will handle it, which is powerful for interop but dangerous for intra-app or sensitive navigation, since another app could register a matching intent-filter and intercept the intent. Explicit intents pin the exact component so there's no ambiguity or interception risk, which is why Android requires them to start your own bound Service and recommends them inside a PendingIntent; the reasoning is implicit means 'I don't know or care who handles this, and that's the point', explicit means 'this must go to exactly this component, full stop'.
You're implementing deep linking for a checkout flow that needs to be secure, like a payment confirmation link sent by email. Would you use a plain intent-filter deep link or Android App Links, and why does that choice matter here specifically?
What a strong answer covers: A plain, unverified deep link via a custom scheme or an unverified http/https intent-filter can be claimed by any app declaring a matching filter, leading to a disambiguation dialog or, worse, a malicious app silently registering the same scheme to intercept the flow. For a payment confirmation link you want Android App Links with autoVerify and a correctly served assetlinks.json on the domain, because that cryptographically ties the link to a domain you actually control via Digital Asset Links, so Android skips the disambiguator and only your verified app can handle it, and an attacker can't claim it without controlling your DNS or hosting.
A PendingIntent handed to a notification, widget, or AlarmManager ends up being triggered by a completely different process, not your own app's code. Walk me through the security implications, and what mistakes commonly leave a PendingIntent exploitable.
What a strong answer covers: A PendingIntent lets another process, system UI for notifications, a launcher for widgets, AlarmManager, execute your intent later effectively as your app, at whatever privilege the wrapped intent carries; if it wraps an implicit intent without FLAG_IMMUTABLE, a malicious holder can call fillIn to mutate the extras, action, or data before it fires, redirecting a confirm action or exfiltrating data through crafted extras. The common mistakes are forgetting FLAG_IMMUTABLE, still a real bug below API 31 where it isn't enforced, using an implicit inner intent instead of an explicit one, and putting sensitive data directly in extras rather than looking it up server-side or by id when the PendingIntent actually fires.