Emulation de navigateur Android : executer des profils mobiles sur ordinateur

Introduction

Le trafic mobile represente plus de la moitie du trafic web mondial, et Android est le systeme d'exploitation mobile dominant de loin. Pour la recherche sur la vie privee, le web scraping, les tests d'applications mobiles et la gestion multi-comptes, la capacite a presenter une identite de navigateur Android authentique depuis une machine de bureau est essentielle. Les vrais appareils Android sont difficiles a faire evoluer, couteux a maintenir et limites en capacites d'automatisation par rapport aux environnements de bureau.

BotBrowser prend en charge les profils de navigateur Android qui, une fois charges sur n'importe quel OS de bureau, produisent une identite de navigateur mobile complete. Le support tactile, les metriques d'ecran, le ratio de pixels de l'appareil, le User-Agent mobile, les chaines GPU et tous les autres signaux specifiques au mobile sont controles au niveau du moteur. Le resultat est indiscernable d'un veritable appareil Android executant Chrome ou WebView, le tout depuis un environnement de bureau ou serveur standard.

Impact sur la vie privee : pourquoi l'emulation Android est importante

De nombreux sites web servent un contenu, des prix et des experiences differents aux utilisateurs mobiles par rapport aux utilisateurs de bureau. Les compagnies aeriennes, les hotels et les plateformes e-commerce affichent souvent des prix differents en fonction du type d'appareil detecte. Les chercheurs en vie privee etudiant ces pratiques doivent presenter des identites mobiles pour comparer les experiences mobiles et de bureau dans des conditions controlees.

Pour la gestion multi-comptes, la diversite des types d'appareils rend chaque identite plus distinctive. Avoir certaines identites sur Windows, d'autres sur macOS et d'autres sur mobile Android cree une variation naturelle qui correspond aux distributions reelles de la population des navigateurs.

L'emulation Android est egalement importante pour tester les fonctionnalites web specifiques au mobile : les mises en page responsives, les interactions tactiles, les flux de paiement mobile, les liens profonds application-vers-web et les installations PWA (Progressive Web App). Tester ces fonctionnalites avec une veritable identite mobile garantit un comportement precis sans la charge de gestion d'appareils physiques ou d'emulateurs Android.

Contexte technique

Ce qui definit une identite de navigateur mobile

Une session de navigateur mobile differe d'une session de bureau sur des dizaines de signaux :

Capacites tactiles : les navigateurs mobiles rapportent navigator.maxTouchPoints (generalement 5 ou 10), ont ontouchstart disponible sur l'objet window, et repondent aux requetes media CSS (pointer: coarse) et (hover: none) indiquant une saisie principalement tactile.

Ecran et viewport : les appareils mobiles ont des dimensions d'ecran plus petites (par exemple, 412x915 pour un Pixel 7) mais des valeurs devicePixelRatio plus elevees (2.625 pour de nombreux telephones modernes). La relation entre screen.width, screen.height, innerWidth, innerHeight et devicePixelRatio suit des schemas specifiques au mobile.

Proprietes du Navigator : navigator.platform rapporte des variantes ARM comme "Linux armv8l" ou "Linux aarch64". La chaine User-Agent contient "Android" et le modele de l'appareil. navigator.userAgentData rapporte mobile: true et la plateforme Android avec sa version.

GPU et rendu : les appareils mobiles utilisent des GPU bases sur ARM (Adreno, Mali, PowerVR) plutot que des GPU de bureau (NVIDIA, AMD, Intel). Les chaines de rendu WebGL refletent ces GPU mobiles, et les caracteristiques de rendu correspondent au comportement du GPU mobile.

Memoire de l'appareil et connexion : navigator.deviceMemory rapporte generalement des valeurs plus basses (4 ou 6 Go) par rapport au bureau (8 ou 16 Go). navigator.connection rapporte des caracteristiques reseau typiques du mobile.

Capteurs et API : les navigateurs mobiles peuvent rapporter des capacites differentes pour des API telles que Battery Status, Vibration, DeviceOrientation et Screen Orientation.

Chrome vs. WebView sur Android

Android dispose de deux moteurs de navigateur de Google :

Chrome pour Android est l'application de navigateur autonome. Il rapporte "Chrome" dans les marques User-Agent et les Client Hints.

Android WebView est le composant de navigateur integre dans les applications Android natives. Il rapporte des jetons de marque differents dans navigator.userAgentData (specifiquement "Android WebView" au lieu de "Chrome") et peut avoir des capacites de fonctionnalites differentes. Des applications comme Facebook, Instagram et TikTok utilisent WebView pour afficher du contenu web.

BotBrowser prend en charge les deux variantes via le flag --bot-config-browser-brand.

Approches courantes et leurs limites

Emulation d'appareil DevTools

Chrome DevTools et Playwright offrent tous deux une emulation d'appareil qui definit la taille du viewport, le User-Agent et les capacites tactiles. Elle est concue pour les tests de conception responsive et ne couvre que les signaux de surface :

• Elle change le viewport et le User-Agent mais pas navigator.platform
• Les evenements tactiles sont simules au niveau de l'API, pas au niveau du moteur
• devicePixelRatio peut etre defini mais ne correspond pas au comportement complet du pipeline de rendu
• Les chaines de rendu WebGL rapportent toujours le GPU de bureau
• La disponibilite des polices reste specifique au bureau
• Les requetes media CSS peuvent ne pas s'aligner completement avec la classe d'appareil emulee

Fermes d'appareils physiques

Executer des tests sur de vrais appareils Android via des services comme BrowserStack ou Sauce Labs fournit des signaux mobiles authentiques. Cependant, ces services sont couteux a grande echelle, ont une capacite de sessions simultanees limitee et restreignent le niveau de controle d'automatisation disponible. Ils ne permettent pas non plus les profils d'empreintes personnalises ou l'isolation d'identite.

Emulateurs Android

Le SDK Android comprend un emulateur qui execute des instances Android completes. Bien qu'il fournisse des signaux mobiles authentiques, chaque instance d'emulateur necessite d'importantes ressources CPU et RAM. L'emulateur est egalement lent a demarrer, difficile a automatiser a grande echelle et ne prend pas en charge le meme niveau de controle d'empreintes que BotBrowser.

Usurpation du User-Agent

Definir une chaine User-Agent mobile sur un navigateur de bureau est l'approche la plus simple mais aussi la plus incomplete. Cela change l'en-tete User-Agent et navigator.userAgent mais laisse tous les autres signaux (support tactile, metriques d'ecran, GPU, plateforme) rapporter des valeurs de bureau.

L'approche de BotBrowser

Les profils Android de BotBrowser sont captures a partir de vrais appareils Android. Chaque profil contient l'ensemble complet des signaux mobiles de l'appareil source. Une fois charges sur n'importe quel OS de bureau, ces signaux sont appliques au niveau du moteur.

Couverture complete des signaux mobiles

Un profil Android charge sur un systeme de bureau produit :

• Support tactile avec les bons maxTouchPoints, ontouchstart et requetes media CSS
• Dimensions d'ecran mobiles et devicePixelRatio de l'appareil source
• Chaines de plateforme ARM dans navigator.platform
• User-Agent mobile avec la bonne version Android et le modele d'appareil
• Chaines GPU mobiles dans le rendu WebGL
• deviceMemory et caracteristiques de connexion appropriees
• navigator.userAgentData correct pour mobile avec mobile: true

Variantes Chrome et WebView

# Lancer en tant que Chrome Android
chrome --bot-profile="/profiles/android-pixel7-chrome.enc" \
       --bot-config-browser-brand=chrome

# Lancer en tant que WebView Android
chrome --bot-profile="/profiles/android-pixel7-chrome.enc" \
       --bot-config-browser-brand=webview

WebView modifie les jetons de marque dans les Client Hints et navigator.userAgentData pour correspondre a ce que des applications comme Facebook ou TikTok presentent lors de l'affichage du contenu web.

Support tactile au niveau du moteur

Contrairement a l'emulation DevTools qui simule le tactile au niveau de l'API, BotBrowser active le support tactile au niveau du moteur. Cela signifie :

• navigator.maxTouchPoints rapporte la valeur correcte de l'appareil source
• ontouchstart est disponible nativement sur l'objet window
• Les requetes media CSS (pointer: coarse) et (hover: none) s'evaluent correctement
• Les constructeurs et proprietes des evenements tactiles se comportent comme sur de vrais appareils mobiles

Configuration et utilisation

Profil Android de base

chrome --bot-profile="/profiles/android-pixel7-chrome.enc" \
       --user-data-dir="$(mktemp -d)"

Integration Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/profiles/android-pixel7-chrome.enc',
      '--bot-config-browser-brand=chrome',
      '--bot-config-timezone=Asia/Tokyo',
      '--bot-config-locale=ja-JP',
      '--bot-config-languages=ja,en',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');

  const mobile = await page.evaluate(() => ({
    touchPoints: navigator.maxTouchPoints,
    platform: navigator.platform,
    screenW: screen.width,
    screenH: screen.height,
    dpr: devicePixelRatio,
    mobile: navigator.userAgentData?.mobile,
  }));
  console.log('Mobile signals:', mobile);
  await browser.close();
})();

WebView avec en-tetes de type application

chrome --bot-profile="/profiles/android-pixel7-chrome.enc" \
       --bot-config-browser-brand=webview \
       --bot-custom-headers='{"x-requested-with":"com.example.app"}' \
       --proxy-server=socks5://user:pass@mobile-proxy:1080

Identite mobile regionale

chrome --bot-profile="/profiles/android-pixel7-chrome.enc" \
       --bot-config-browser-brand=chrome \
       --proxy-server=socks5://user:pass@br-proxy:1080 \
       --bot-config-timezone=America/Sao_Paulo \
       --bot-config-locale=pt-BR \
       --bot-config-languages=pt-BR,pt,en

Verification

Verifiez le profil Android en controlant les signaux specifiques au mobile :

const page = await context.newPage();
await page.goto('https://example.com');

const mobileCheck = await page.evaluate(async () => {
  const result = {
    platform: navigator.platform,
    touchPoints: navigator.maxTouchPoints,
    touchStart: 'ontouchstart' in window,
    screenWidth: screen.width,
    screenHeight: screen.height,
    dpr: devicePixelRatio,
    deviceMemory: navigator.deviceMemory,
  };

  if (navigator.userAgentData) {
    result.mobile = navigator.userAgentData.mobile;
    result.platform = navigator.userAgentData.platform;
    const brands = navigator.userAgentData.brands.map(b => b.brand);
    result.brands = brands;
  }

  // Verifier la requete media CSS
  result.coarsePointer = matchMedia('(pointer: coarse)').matches;
  result.noHover = matchMedia('(hover: none)').matches;

  return result;
});

console.log('Android verification:', mobileCheck);

Bonnes pratiques

• Utilisez defaultViewport: null dans Playwright et Puppeteer pour laisser le profil mobile controler les dimensions du viewport. Les remplacements de viewport du framework entreront en conflit avec les metriques d'ecran du profil.
• Choisissez des profils d'appareils appropries. Faites correspondre l'appareil au marche cible. Les appareils Pixel sont populaires aux Etats-Unis. Les appareils Samsung Galaxy dominent a l'echelle mondiale. Les fabricants chinois (Xiaomi, OPPO) sont courants en Asie.
• Associez avec des proxies mobiles. Pour l'identite mobile la plus coherente, utilisez des proxies mobiles ou residentiels plutot que des proxies de datacenter.
• Utilisez la marque WebView pour les scenarios in-app. Lorsque vous simulez du trafic depuis une application mobile, utilisez --bot-config-browser-brand=webview et ajoutez les en-tetes x-requested-with appropries.
• Faites correspondre la locale au proxy. Definissez --bot-config-timezone, --bot-config-locale et --bot-config-languages pour correspondre a l'emplacement du proxy.
• Definissez DISPLAY sur les serveurs Linux. Utilisez DISPLAY=:10.0 meme en mode headless lors de l'execution sur Linux.

Questions frequemment posees

Puis-je executer un profil Android sur un hote macOS ?

Oui. Les profils Android fonctionnent sur n'importe quel OS hote. Le binaire BotBrowser sur macOS, Linux ou Windows peut charger des profils Android et presenter une identite mobile complete.

Quelle est la difference entre les modes Chrome et WebView ?

Le mode Chrome se presente comme le navigateur Chrome autonome pour Android. Le mode WebView se presente comme le composant de navigateur integre utilise par les applications natives. Les principales differences se situent dans les marques User-Agent rapportees via les Client Hints. Utilisez Chrome pour les scenarios de navigation autonome et WebView pour les scenarios in-app.

BotBrowser emule-t-il le comportement des evenements tactiles ?

BotBrowser active le support tactile au niveau du moteur, ce qui signifie que maxTouchPoints, ontouchstart et les requetes media CSS rapportent toutes des valeurs correctes pour mobile. La generation de sequences d'evenements tactiles reelles (tap, swipe, pinch) necessite votre framework d'automatisation. Playwright et Puppeteer prennent tous deux en charge les methodes de saisie tactile.

Comment fonctionne l'orientation de l'ecran ?

Les profils mobiles incluent les donnees d'orientation de l'appareil source. L'API screen.orientation rapporte le type et l'angle corrects.

Puis-je simuler differentes versions d'Android ?

Oui. Les profils captures a partir de differentes versions d'Android contiennent les informations de version correspondantes dans le User-Agent, la version de la plateforme et l'ensemble de fonctionnalites.

Qu'en est-il des polices specifiques au mobile ?

Les profils Android incluent l'environnement de polices Android (Roboto, Noto, DroidSans). Les requetes de disponibilite des polices retournent l'ensemble de polices Android plutot que les polices de bureau.

Ai-je besoin de materiel specifique pour executer des profils Android ?

Non. Les profils Android s'executent sur n'importe quel materiel standard. Le profil controle les signaux que le navigateur rapporte, pas la facon dont le calcul est effectue. Toute machine capable d'executer le binaire BotBrowser peut charger un profil Android.

Resume

L'emulation Android via les profils BotBrowser permet des identites de navigateur mobile completes sur n'importe quel systeme de bureau. Le support tactile, les metriques d'ecran, les chaines GPU et tous les autres signaux mobiles sont controles au niveau du moteur, produisant une sortie qui correspond aux vrais appareils Android sans la charge des appareils physiques ou des emulateurs.

Pour des sujets connexes, consultez Emulation d'appareil pour le guide general d'emulation d'appareil, Profils multi-plateformes pour l'apercu general multi-plateforme, et Changement de marque de navigateur pour la configuration Chrome vs. WebView.