Un profilo Android gira su un normale computer e riceve il verdetto Trustworthy di iphey. La lezione, imparata a caro prezzo, è non assegnare manualmente l'hardware del telefono. Resta un limite della finestra desktop, mostrato apertamente.
Crea un profilo mobile con l'opzione:
Il motore seleziona un'identità mobile coerente, con modello, chipset, schermo e memoria. Il modello viene dichiarato in uaData.model, che è anche il valore letto dagli strumenti di controllo. La suite ottiene 100 su 100 e iphey restituisce Trustworthy; non serve un telefono fisico.
La prima versione assegnava l'hardware del telefono dalla nostra lista di modelli. La lista abbinò un Pixel 7 a un chipset Redmi. Un solo chipset errato bastò perché iphey restituisse Unreliable: gli strumenti conoscono le combinazioni reali di modello e chipset meglio di qualsiasi elenco mantenuto a mano.
Tre profili mobili creati di seguito su una macchina pulita:
| Superficie | Risultato |
|---|---|
| Font disponibili solo su Windows | nessuno esposto; tutti i tredici controlli superati |
| Scheda video | diversa in ogni profilo |
| Schermo dichiarato | diverso in ogni profilo |
| Canvas | diverso in ogni profilo |
| Numero di processori logici | otto in ogni profilo, come sui telefoni di riferimento |
I font sono il controllo più chiaro. Se un profilo che si presenta come Pixel mostrasse Calibri o Segoe UI, la contraddizione sarebbe immediata: Android non include quei font. Ne abbiamo testati tredici, installati solo con Windows o Microsoft Office, e il profilo non ne ha esposto nessuno.
Il viewport di layout del profilo mobile è più largo dello schermo dichiarato. Il motore modifica screen e outerWidth, ma il browser continua a funzionare in una vera finestra desktop. Il profilo dichiara 360×800, mentre il viewport di layout misura 500×731. Abbiamo provato queste alternative:
| Alternativa | Larghezza del viewport di layout |
|---|---|
| senza modifiche | 500 |
| finestra 412×915 | 500 |
| finestra 300×600 | 500 |
| scala di rendering 1,27 | 510 |
| modalità headless | 478 |
Il limite deriva dalla larghezza minima della finestra Chrome su desktop, circa 500 pixel CSS. I telefoni non usano un viewport così largo, quindi lo scarto non può essere eliminato finché il browser gira in una finestra desktop. Alterare innerWidth senza cambiare il layout reale non funziona. La prima media query rivelerebbe la larghezza effettiva e creerebbe due valori contraddittori anziché uno.
Cosa è stato possibile migliorare: dopo l'apertura, NimbusX adatta la finestra all'altezza dichiarata dalla pagina e CreepJS non segnala più la sezione Screen. La differenza di larghezza rimasta è visibile nella dashboard: la cella WIN è attenuata e la spiegazione compare sotto la tabella. Nasconderla non avrebbe senso, perché il sito vede lo scarto prima dell'utente.
La coerenza conta più della quantità · Come i rilevatori collegano i profili