DeviceMotion, DeviceOrientation y Vibration son de primera clase en la web móvil — hasta que se ejecutan dentro de un WebView. Android System WebView dejó la API de orientación desactivada hasta v55 y en muchas compilaciones sigue devolviendo aceleración en cero a menos que se configuren las banderas y permisos correctos; Vibration necesita un permiso VIBRATE explícito. En iOS, WKWebView ni siquiera expone requestPermission(), así que el flujo de iOS 13+ bloqueado por gesto nunca arranca. Un runtime propio del host puentea la capa de sensores: una API que lee el hardware real en cada motor.
Android: desactivado por defecto, silencioso cuando «activo»
La documentación de Chromium es clara: entre las APIs de sensores de hardware, la API de orientación estuvo desactivada en WebView v33 y solo se habilitó desde v55. Geolocalización, captura de medios y Vibration también están parcialmente condicionadas. Y «habilitado» no es «funciona» — muchas compilaciones de WebView devuelven acceleration en cero o nunca disparan el evento a menos que la página se sirva por https y la app conceda el permiso en tiempo de ejecución. Una falla común es una función «sacudir para acción» que simplemente no se activa porque el contenedor no reenvió el sensor. Vibration (navigator.vibrate) necesita android.permission.VIBRATE; sin él la llamada es una no-operación silenciosa.
iOS: la API de permiso falta por completo
Desde iOS 13, Safari requiere DeviceMotionEvent.requestPermission() / DeviceOrientationEvent.requestPermission() — un diálogo disparado por un gesto del usuario — antes de que se dispare cualquier evento de movimiento u orientación. Pero esa API no se expone en WKWebView. El propio rastreador de errores de WebKit (bug 203287) lo registra: «La API requestPermission() solo se expone en MobileSafari, no en WKWebView». Así que dentro del WebView de una app el flujo bloqueado por gesto ni siquiera puede comenzar; la página debe depender de que el WebView tenga acceso directo, lo cual depende totalmente de cómo lo configuró el host. Suma el requisito de contexto seguro (sin http://) y la política de iframe allow="gyroscope; accelerometer", y la mayoría de las páginas integradas no recibe nada.
Qué se rompe cuando los sensores se silencian
- Mueren las funciones de sacudir, inclinar y contar pasos. Sin eventos
devicemotion, no hay UX basada en gestos. - Las herramientas 360° / AR / nivel no devuelven nada.
deviceorientationestá ausente o en cero. - Las vibraciones están silenciosas.
navigator.vibratees una no-operación sin el permiso VIBRATE. - Doble trampa en iOS 13+. Sin
requestPermission()en WKWebView, la ruta de Safari no puede ejecutarse; el host debe conceder nativamente. - Los navegadores integrados divergen. Los contenedores de WeChat/Weibo a menudo no exponen ni la API ni forma de solicitarla, así que probar en Safari oculta la falla.
La solución del runtime
Un runtime propio del host puentea la capa de sensores. El host lee el hardware real — SensorManager en Android, Core Motion en iOS — y expone una API uniforme a la página: movimiento, orientación y retroalimentación háptica que funcionan en cada motor y navegador integrado. El permiso se solicita una vez, nativamente, y los valores fluyen a la página sin la compuerta por motor. Una superficie de sensores, hardware real, en todas partes.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Orientación en Android | Desactivada < v55, a menudo en cero | Hardware real |
| requestPermission iOS | No expuesto en WKWebView | Concesión nativa |
| Vibration | Necesita permiso VIBRATE | Háptica nativa |
| Compuerta de contexto seguro | Fácil de errar | Manejado nativamente |
| Navegadores integrados | Sin API, sin diálogo | API uniforme |
| Consistencia | Por motor | Uniforme |
Una app nativa lee el giroscopio en cada teléfono. Un WebView común en casi ninguno. Un runtime le da a la página una capa de sensores — y el hardware real detrás de ella.
Fuentes
- Chrome for Developers — Descripción de WebView (soporte de sensores) — la tabla que muestra orientación desactivada en WebView v33 y habilitada desde v55, y Vibration condicionada por permiso.
- WebKit Bug 203287 — «requestPermission() solo se expone en MobileSafari, no en WKWebView», con confirmación de un ingeniero de WebKit.
- MDN — DeviceMotionEvent — el requisito de gesto
requestPermission()de iOS 13+ y la restricción de contexto seguro. - MDN — DeviceOrientationEvent — las mismas reglas de permiso y contexto para datos de orientación.
- MDN — Vibration API — soporte de
navigator.vibratey el requisito de permiso VIBRATE en Android.
