Chrome 158 brings the WebHID API to Chrome for Android, but only on devices running Android 17 (API level 37) or later, and it still does not work inside WebView.
The WebHID API has been a desktop-only convenience since Chrome 89, handy for firmware tools and gamepad calibrators but irrelevant to the phone in your pocket. The catch, now that it's shipping on Android: the API works in the Chrome app, not in WebView, the embeddable browser component that powers the login screens, help centers and hybrid flows inside most native Android apps. Teams planning hardware-adjacent features for an Android build, and weighing how much of that work belongs in a web view versus YuSMP Group's Android development team building it natively, need to know exactly where that line sits before they design around it.
The feature itself is unchanged from its desktop form. Chrome's own release notes describe it as bringing the existing WebHID API to Android "with no changes to the web-exposed API surface." A page calls navigator.hid.requestDevice(), the user picks a device from a system-drawn chooser, and the page gets a channel to send and receive raw HID input, output and feature reports over USB or Bluetooth, the same mechanism that lets desktop sites remap mechanical keyboards or flash gamepad firmware.
On Android, the practical use cases skew toward accessory configuration:
The gap is the chooser UI itself. Chrome's beta announcement and the detailed release notes are explicit that WebView is excluded "as it does not have a device chooser UI or permissions UX controls." WebView is a rendering engine embedded by a host app, not a standalone browser with its own permission dialogs. An API that fundamentally depends on the browser drawing a device-picker and an OS-level permission grant has nowhere to put that UI inside someone else's app chrome. This isn't an oversight that gets patched in 159; it's the same structural reason WebView has never supported several other permission-heavy APIs.
Feature-detect with 'hid' in navigator and degrade gracefully, rather than assuming the capability follows the OS version. If your Android strategy is "ship a WebView wrapper around our web app," WebHID won't surface a picker inside that shell, regardless of Android version — the same way camera/mic prompts, geolocation and other permission-gated APIs never have.
For a feature that genuinely needs device-chooser UI, OS-level permission scoping, or reliable Bluetooth HID access, the real decision is architectural, not a workaround:
That's the real architecture decision for a hardware-adjacent companion app, not the navigator.hid call itself.
Chrome 158 is in beta now and is scheduled for stable release on November 17, 2026, per chromestatus.com. The Android 17 (API level 37) requirement means rollout will trail actual device adoption of that OS version for a while. Plan for feature detection, not a hard cutover date, when you're deciding whether to rely on it in production.