Un perfil Android se ejecuta en un ordenador normal y recibe un veredicto Trustworthy de iphey. La lección, aprendida a un coste alto, fue no asignar manualmente el hardware del teléfono. Queda una limitación de la ventana de escritorio y el producto la muestra abiertamente.
Crea un perfil móvil con la opción:
El motor selecciona una identidad móvil coherente, con modelo, chipset, pantalla y memoria. El modelo se declara en uaData.model, que es el dato que leen los detectores. La batería obtiene 100 de 100 e iphey devuelve Trustworthy; no hace falta un teléfono físico.
La primera versión asignaba el hardware del teléfono desde nuestra propia lista de modelos. La lista emparejó un Pixel 7 con un chipset de Redmi. Un solo chipset incorrecto bastó para que iphey devolviera Unreliable: los detectores conocen las combinaciones reales de modelo y chipset mejor que cualquier catálogo mantenido a mano.
Tres perfiles móviles creados seguidos en un equipo limpio:
| Superficie | Resultado |
|---|---|
| Fuentes exclusivas de Windows | ninguna expuesta; las trece pruebas pasaron |
| tarjeta de video | distinta en cada perfil |
| Pantalla declarada | distinta en cada perfil |
| Canvas | distinta en cada perfil |
| Número de procesadores lógicos | ocho en todos los perfiles, como en los teléfonos de referencia |
Las fuentes son la comprobación más clara. Si una página recibiera Calibri o Segoe UI de un perfil que se presenta como Pixel, la contradicción sería inmediata: Android no incluye esas fuentes. Probamos trece fuentes que solo se instalan con Windows o Microsoft Office y el perfil no expuso ninguna.
El viewport de maquetación del perfil móvil es más ancho que la pantalla declarada. El motor modifica screen y outerWidth, pero el navegador sigue ejecutándose en una ventana real del sistema de escritorio. El perfil declara 360×800 y el viewport de maquetación mide 500×731. Probamos estas alternativas:
| Alternativa | Anchura del viewport de maquetación |
|---|---|
| sin ajustes | 500 |
| ventana 412×915 | 500 |
| ventana 300×600 | 500 |
| escala de renderizado 1,27 | 510 |
| modo headless | 478 |
El límite procede de la anchura mínima de la ventana de Chrome en sistemas de escritorio, unos 500 píxeles CSS. Los teléfonos no usan un viewport tan ancho, por lo que la diferencia no puede desaparecer mientras el navegador viva en una ventana de escritorio. Falsear innerWidth sin cambiar el diseño real no funciona. La primera media query revelaría la anchura verdadera y crearía dos valores contradictorios en lugar de uno.
Lo que sí pudimos mejorar: tras abrirse, NimbusX ajusta la ventana a la altura declarada por la propia página y CreepJS dejó de marcar la sección Screen. La diferencia de anchura restante se muestra en el panel: la celda WIN aparece atenuada y la explicación figura bajo la tabla. Ocultarla no tendría sentido, porque el sitio ve la diferencia antes que el usuario.
La coherencia importa más que la cantidad · Cómo relacionan perfiles los detectores