How to Inspect System Search Providers and UI Target Sessions on Android Using ADB dumpsys search_ui

Modern Android home screens, system launchers, and global device search surfaces (such as the Google Pixel Launcher’s unified search bar, Samsung One UI Finder, or third-party launchers) offer real-time search across local applications, device settings, web suggestions, in-app shortcuts, and personal contacts. Rather than having every search surface directly query separate system services, Android 11 and later utilise the Search UI Framework, managed system-wide by the SearchUiManagerService.

The Search UI subsystem manages active search sessions, synchronises user query contexts with registered system search providers, tracks search result impressions, and coordinates target predictions. For Android system developers, ROM engineers, and security analysts, the Android Debug Bridge (ADB) command dumpsys search_ui provides direct diagnostic insight into active search sessions, provider package bindings, predictive search tokens, and user session lifecycles. This guide explains how the Search UI architecture operates and details how to extract, filter, and analyse search session data using ADB.

Understanding Android SearchUiManagerService Architecture

The Search UI framework provides an abstraction layer between client applications (the “consumer” surface, typically the default system launcher or system search interface) and prediction/search backends (the “search provider”). The architecture relies on three primary components:

• SearchUiManagerService: A system service running inside the system_server process that brokers communication between search clients and registered provider implementations. It enforces Android multi-user isolation and validates package permissions.
• SearchSessionId: A unique cryptographic or sequential token generated whenever a user opens a search surface or begins typing a query. All query updates, result clicks, impression logs, and dismissal actions correlate back to this session identifier.
• SearchContext: Metadata describing where search is being executed (e.g. surface=launcher, display_id=0, result_types=apps|shortcuts|settings) and maximum result quotas.
• SearchTarget: Individual structured items returned by the search provider, including application packages, deep links, sliced remote views, and action intents.

When a user taps the home screen search widget, the launcher binds to the search_ui service, instantiating a session. Diagnostics collected via ADB allow developers to verify whether their application’s published shortcuts or deep-search intents are properly surfaced and indexed by the system launcher.

Verifying ADB Connectivity and Search Service Availability

Connect your Android test device or emulator via USB or wireless ADB. Ensure USB Debugging is authorised in Developer Options, then verify device detection:

adb devices -l

Next, confirm that the search_ui service is registered and responding within the Android system server:

adb shell service list | grep -i search_ui

The output should return the registered Binder service:

142	search_ui: [android.app.search.ISearchUiManager]

If the service is absent, your Android build or OEM skin may not implement the standard Android Open Source Project (AOSP) Search UI framework, relying instead on proprietary standalone search engines.

Dumping Global Search UI Service State

To inspect the entire diagnostic state of the Search UI subsystem across all user profiles, execute the basic dumpsys command:

adb shell dumpsys search_ui

The output provides an overview of registered providers, active sessions, and multi-user configurations:

SEARCH UI MANAGER SERVICE (dumpsys search_ui)
========================================================
User 0:
  Default service name: com.google.android.as/com.google.android.apps.miphone.aiai.search.service.SearchUiService
  Is temporary service: false
  Service bound: true
  Bound component: ComponentInfo{com.google.android.as/com.google.android.apps.miphone.aiai.search.service.SearchUiService}
  Active sessions count: 1
    Session: SearchSessionId{id=c7a810f4-52d1-419b-a01b-5e6f30d074e2}
      Client package: com.google.android.apps.nexuslauncher
      Client UID: 10182
      Surface: 1 (LAUNCHER_SEARCH)
      Result types: 31 (APPS | SHORTCUTS | SETTINGS | PEOPLE | WEB)
      Created at: 2026-11-08 02:05:14
      Last interaction: 2026-11-08 02:18:22
      Registered callbacks: 1

This dump identifies several critical runtime details:

• Bound Component: Shows the active on-device intelligence package handling search parsing (in the example above, Android System Intelligence / Private Compute Core under com.google.android.as).
• Client Package: Identifies which application initiated the search session (e.g. com.google.android.apps.nexuslauncher).
• Result Types: A bitmask indicating what categories of content the consumer requested from the provider.

Inspecting Active Search Sessions and Client Bindings

When debugging why search suggestions fail to appear or update sluggishly, examine the active session parameters and callback registrations.

Filtering Active Sessions for the Primary User

On devices with multiple profiles (e.g. Work Profile / Managed Profile), filter dumpsys to inspect only user 0 (personal) or user 10 (work):

# Extract active session details for primary user (User 0)
adb shell dumpsys search_ui --user 0

To isolate session IDs and associated client packages in automated test scripts, pipe the output through grep:

adb shell dumpsys search_ui | grep -E "(Session:|Client package:|Surface:)"

Simulating Search Interactions to Observe State Transitions

To observe how dumpsys search_ui updates during user activity:

1. Unlock the Android device and tap the home screen search bar.
2. Type a test query (e.g. “Camera”).
3. Immediately capture the dumpsys state via ADB:

adb shell dumpsys search_ui > search_ui_active.txt

Inspect search_ui_active.txt to verify whether the session logged the query string, updated target scores, or received candidate result bundles from the intelligence provider.

Tracing Search Target Delivery and Impression Logs

The Search UI framework does not merely pass search results to the launcher; it also tracks user engagement (impressions, clicks, and dismissals) so ranking algorithms can prioritise frequently launched targets.

Search target diagnostic dumps capture events formatted under SearchTargetEvent:

adb shell dumpsys search_ui | grep -A 10 "SearchTargetEvent"

Output illustrates how interactions are logged:

Last Target Events:
  [2026-11-08 02:18:25] EventType: 1 (TARGET_CLICK)
    Target ID: app:com.google.android.GoogleCamera/.CameraActivity
    Session ID: c7a810f4-52d1-419b-a01b-5e6f30d074e2
    Action: launch
  [2026-11-08 02:18:22] EventType: 4 (IMPRESSION)
    Target ID: shortcut:com.android.chrome/incognito
    Session ID: c7a810f4-52d1-419b-a01b-5e6f30d074e2

By reviewing these timestamps and event types, developers can confirm whether system telemetry correctly registers target selections or if event dispatching is dropped due to lifecycle race conditions.

Temporarily Overriding the Search UI Provider for Testing

Android allows developers to override the default system search provider with a custom debug provider service using cmd search_ui. This allows validating custom search algorithms without building a custom operating system image.

Setting a Temporary Search UI Service

To redirect search queries to a custom test package implementing SearchUiService, set a temporary service override:

# Syntax: cmd search_ui set-temporary-service <USER_ID> <COMPONENT_NAME> <DURATION_MS>
adb shell cmd search_ui set-temporary-service 0 com.example.customsearch/.MySearchUiService 600000

This command binds the Search UI framework to com.example.customsearch for 600,000 milliseconds (10 minutes). Once set, verify the binding with dumpsys:

adb shell dumpsys search_ui | grep -i "temporary"

The output will show Is temporary service: true along with your test package component name.

Clearing the Temporary Service Override

To immediately revert the Search UI subsystem back to the manufacturer’s default on-device intelligence provider, clear the temporary service assignment:

adb shell cmd search_ui set-temporary-service 0

Verify that the default system search provider is restored:

adb shell dumpsys search_ui | grep "Default service name"

Troubleshooting Common Search UI Issues

When debugging empty search results or launcher crashes during search typing, check the following diagnostic indicators:

• Service Unbound (Service bound: false): Indicates the underlying intelligence package (e.g. com.google.android.as) crashed or was disabled via package manager. Check logcat for system server exceptions using:

  adb logcat -d -s SearchUiManagerService:V AndroidRuntime:E

• Permission Denied on Session Creation: Consumer applications attempting to bind to SearchUiManagerService must hold the android.permission.MANAGE_SEARCH_UI signature permission. Non-system third-party launchers cannot directly bind to this service unless granted privileged platform status.
• Work Profile Leakage: Verify that search sessions initiated under User 0 do not receive search targets from User 10 without proper user cross-profile badges by inspecting the Target ID prefixes in the session dump.