Por qué me importa este tema ahora
Sin un teléfono vivo, el laboratorio empieza rápido a comparar fantasía con fantasía. El emulador es útil. No es un etalon de la vida cotidiana. Necesito un baseline que pueda cansarse, perder la red y pedir permiso de sensor.
Sin un teléfono vivo discute con la fantasía. El baseline del dispositivo sobria tanto al detect como al build.
Marco público (enlaces)
Las expectativas de una superficie móvil se leen al menos a través de APIs públicas como DeviceMotion y a través de la honestidad de checkers abiertos como x-bot: clasifican la superficie, no emiten un pasaporte del dispositivo. Mi etalon es la vida cotidiana real, no un «JSON ideal del teléfono».
Lo que observo en el lab, en palabras sencillas
Qué comparo a nivel de ideas
Superficie, comportamiento en el tiempo, red como contexto. No nombres internos de señales — clases de preguntas. Junto al teléfono se ve de inmediato dónde el laboratorio dibujó una línea recta ideal.
Por qué el emulador no es un sustituto
Porque es demasiado controlable y demasiado limpio. Es bueno para la reproducibilidad y malo como única norma de «cómo viven las personas». La reproducibilidad hace falta. La norma de la vida cotidiana hace falta por separado.
Cómo describir las discrepancias
«En el etalon el permiso del sensor es otro», «la escena es más viva», «la red es más cotidiana». Sin un catálogo de flags internos y sin números de serie del dispositivo.
Qué cambia en el detect y/o en el build (sin detalles)
El detect se calibra con el ruido de la vida. El build se comprueba no solo contra un checker público, sino también con la pregunta: ¿da vergüenza junto a un teléfono real?
Qué no diré y por qué
Sin dumps del etalon como guía de ajuste y sin números de serie/huellas de dispositivos.
Conclusión breve en primera persona
Un teléfono vivo te sobria. Devuelve el laboratorio del teatro de campos ideales a una habitación donde hay LTE malo y un gesto al azar.
