A profile a site reads as a phone

A phone profile is an ordinary ARMANOS profile on the Android template: same cookies, proxy and schedule as any other. It is not an emulator and not a phone in a rack.

On the desktop templates the generator may mix parts, because such machines are really sold. A phone is not built that way, so the model arrives whole and stays with the profile.

• Screen and pixel ratio

  Both come from the model, and available height equals screen height.

• GPU pair

  Vendor and renderer as ANGLE reports them on Android.

• Cores and memory

  From the handset row, in steps a browser really reports.

• Model

  Chrome froze it out of the User agent; client hints carry it.

• Android version

  Never older than the handset's own launch version.

• Vendor fonts

  The Android core set plus the shell's own families.

The seed reaches the engine on the command line and is applied inside it, before any page script. These are the engine's own answers, not values written over real ones.

Ask a desktop Chromium for a window 360 points wide and you get 500, measured on the built engine. So it is brought to the handset size over the debugging protocol.

• Window size

  A launch key for the first window, then an override for every page and new tab.

• Touch

  The touch events launch key, plus the points from the seed.

• Coarse pointer and no hover

  Settings naming the finger and the absence of a mouse.

• Screen orientation

  Derived from the dimensions, so it cannot argue with them.

• Mouse becomes touch

  A live handset sends no mouse events, so clicks become touches.

It is one field in the profile form; everything else works as on a desktop profile. Under the picker stands an honest note about what this computer cannot do.

1. 1

   New profile, then the template

   Pick Android · Chrome (phone), or the tablet one.

2. 2

   Read the note under the picker

   It names what this machine cannot do for a phone.

3. 3

   Attach a proxy as usual

   The template describes the device, not the route.

4. 4

   Pick the device after creating it

   Fingerprint > Change values > Device. Screen, ratio, GPU, cores, memory and fonts come with it.

5. 5

   Launch

   The start page opens first, the window comes down, then the site.

A phone whose network numbers match a laptop disagrees with itself. The numbers follow the browser's own rules: latency in steps of 50 ms, throughput stopping at 10 Mbps.

• downlink

  Phone 1.5 to 8 Mbps, desktop 5 to 10: identical numbers would be the mismatch.

• rtt

  Phone 100 to 300 ms, desktop 50 to 200.

• effectiveType

  From latency, against the same thresholds the engine itself uses.

• type

  Cellular or wifi, on a phone profile only: desktop Chrome has no such field.

• downlinkMax

  From the engine's own table, never below downlink and matching the subtype.

Use it where the site behaves differently for a phone, or where the account's history is a phone's. Not where the work needs the device.

A real device has hardware, and nothing here adds hardware: counts are stated, capture is not. A cloud phone service rents a real handset instead, one session at a time.

• No camera or microphone of a phone

  The counts are stated, the capture is not.

• No sensors

  No accelerometer, no gyroscope, no ambient light.

• No SMS and no phone number

  A code sent to a handset never arrives here.

• No application store

  Anything installed from a store stays outside the browser.

• No phone fonts on your computer

  Roboto and Noto are not there, and the app says so.