Docs

Android's System EyeDropper: Tracking the Funnel Shift

Android 17's ACTION_OPEN_EYE_DROPPER replaces custom colour pickers with a system flow — here's what to track when you switch.

Engagement

Android 17 ships a system-level eyedropper: apps call ACTION_OPEN_EYE_DROPPER and let the OS hand back a colour sampled from anywhere on screen, instead of shipping a custom colour-picker UI or requesting broad screen-capture and media-projection permissions to build one. For design tools, note-taking apps, and anything with a “match this colour” feature, that’s a meaningful permission simplification — no more asking users to grant screen recording just to sample a pixel. But swapping a bespoke, in-app control for a system sheet changes the interaction, and teams that migrate without instrumenting the switch lose visibility into whether the new flow actually converts as well as the old one.

The risk isn’t the API itself — it’s the blind spot. A custom colour picker lives inside your view hierarchy, so every tap, drag, and selection was already flowing through your existing analytics. The system eyedropper hands control to the OS for the duration of the picker, and unless you explicitly log entry and exit around that call, you get a gap: users who opened the picker and never returned with a colour look identical to users who never opened it at all. That distinction matters when you’re trying to work out whether the system flow is genuinely easier, or just quietly leaking users at a step you can no longer see.

Data Points to Track

  • Eyedropper invocation events, tagged with the feature or screen that triggered it, so you can compare adoption of the system picker against any legacy custom picker still running behind a flag
  • Completion vs. cancellation outcomes, distinguishing a colour successfully returned from a user backing out of the system sheet without picking anything
  • Time-in-picker, from invocation to the app regaining foreground, as a proxy for friction or hesitation in the new flow
  • Fallback path usage, for any devices or OS versions below API 37 still routed to your legacy in-app picker
  • Downstream action after selection, confirming the sampled colour was actually applied rather than the flow silently dead-ending after return

Setup Steps

  1. Log an event immediately before calling ACTION_OPEN_EYE_DROPPER, capturing the triggering screen and feature context.
  2. Log the result callback separately, recording whether a colour was returned or the intent was cancelled, keyed to the same session so the two events can be joined.
  3. Instrument the fallback branch for pre-API-37 devices so custom-picker and system-picker cohorts are tagged distinctly rather than merged into one generic “colour picked” event.
  4. Add a foreground-return timer started at invocation and stopped when the activity resumes, to catch abnormally long picker sessions.
  5. Confirm the applied-colour event fires downstream of a successful pick, so a silent drop-off between selection and application is visible rather than assumed away.

Actionable Insights

Compare completion rate on the system eyedropper against your historical custom-picker completion rate for the same feature. A meaningfully lower rate suggests users are finding the system sheet less discoverable or more disruptive than the in-app control it replaced, which is worth raising even though the permission story is objectively better. A gap between invocation and applied-colour events, on the other hand, usually points to a UI issue on your side of the handoff — the picker worked, but the app didn’t do anything useful with the result. Either way, treat the migration as a funnel change worth measuring on its own terms, not just a permissions cleanup to ship and forget.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert