Retour au Blog
Plateforme

Émulation Android : profils de navigateur mobile sur bureau

Exécutez des profils Android Chrome et WebView sur n'importe quel OS de bureau avec BotBrowser pour une identité mobile cohérente incluant les événements tactiles, les métriques d'écran et l'UA mobile.

Introduction

Le trafic mobile représente plus de la moitié du trafic web mondial, et Android est de loin le système d'exploitation mobile dominant. Pour la recherche en matière de confidentialité, le scraping web, les tests d'applications mobiles et la gestion multi‑comptes, la capacité à présenter une identité de navigateur Android réelle depuis une machine de bureau est essentielle. Les appareils Android réels sont difficiles à faire évoluer, coûteux à maintenir et limités en capacités d'automatisation par rapport aux environnements de bureau.

BotBrowser prend en charge des profils de navigateur Android qui, une fois chargés sur n'importe quel OS de bureau, génèrent une identité de navigateur mobile complète. Le support tactile, les métriques d'écran, le devicePixelRatio, le User‑Agent mobile, les chaînes GPU et tous les autres signaux spécifiques au mobile sont contrôlés au niveau du moteur. Le résultat est indiscernable d'un appareil Android réel exécutant Chrome ou WebView, depuis un environnement de bureau ou serveur standard.

Impact sur la confidentialité : pourquoi l'émulation Android importe

De nombreux sites servent des contenus, prix et expériences différents aux utilisateurs mobile vs desktop. Les compagnies aériennes, hôtels et plateformes e‑commerce affichent souvent des prix différents selon le type d'appareil détecté. Les chercheurs en confidentialité ont besoin de présenter des identités mobiles pour comparer les expériences mobile et desktop dans des conditions contrôlées.

Pour la gestion multi‑comptes, la diversité des types d'appareils rend chaque identité plus distinctive. Avoir des identités sous Windows, d'autres sous macOS et d'autres sur Android mobile crée une variation naturelle correspondant à la population réelle des navigateurs.

L'émulation Android est également utile pour tester des fonctionnalités web spécifiques au mobile : mises en page responsives, interactions tactiles, flux de paiement mobile, deep links app‑to‑web et installations PWA. Tester ces fonctionnalités avec une identité mobile réelle garantit un comportement précis sans la charge de gestion des appareils physiques ou des émulateurs.

Contexte technique

Qu'est‑ce qui fait une identité de navigateur mobile

Une session de navigateur mobile diffère d'une session desktop sur des dizaines de signaux :

Capacités tactiles : les navigateurs mobiles rapportent navigator.maxTouchPoints (typiquement 5 ou 10), disposent de ontouchstart sur l'objet window et répondent aux media queries CSS (pointer: coarse) et (hover: none) indiquant une entrée primaire tactile.

Écran et viewport : les appareils mobiles ont des dimensions d'écran plus petites (p. ex. 412x915 pour un Pixel 7) mais des devicePixelRatio plus élevés (2.625 pour de nombreux téléphones récents). La relation entre screen.width, screen.height, innerWidth, innerHeight et devicePixelRatio suit des schémas spécifiques au mobile.

Propriétés Navigator : navigator.platform renvoie des variantes ARM comme "Linux armv8l" ou "Linux aarch64". La chaîne User‑Agent contient "Android" et le modèle du dispositif. navigator.userAgentData rapporte mobile: true et la plateforme Android avec sa version.

GPU et rendu : les appareils mobiles utilisent des GPU ARM (Adreno, Mali, PowerVR) plutôt que des GPU desktop (NVIDIA, AMD, Intel). Les chaînes renderer WebGL reflètent ces GPU mobiles, et les caractéristiques de rendu correspondent au comportement de GPU mobile.

Mémoire et connexion : navigator.deviceMemory rapporte généralement des valeurs plus faibles (4 ou 6 GB) comparées au desktop (8 ou 16 GB). navigator.connection reflète des caractéristiques réseau typiques du mobile.

Capteurs et APIs : les navigateurs mobiles peuvent déclarer des capacités différentes pour des APIs comme Battery Status, Vibration, DeviceOrientation et Screen Orientation.

Chrome vs WebView sur Android

Android propose deux variantes de moteur de navigation par Google :

Chrome for Android est l'application de navigateur autonome. Elle se signale comme "Chrome" dans les marques User‑Agent et Client Hints.

Android WebView est le composant de navigateur intégré aux applications natives Android. Il signale des tokens de marque différents dans navigator.userAgentData (par ex. "Android WebView" au lieu de "Chrome") et peut exposer un ensemble de fonctionnalités légèrement différent. Des apps comme Facebook, Instagram ou 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

Émulation d'appareil via DevTools

Chrome DevTools et Playwright proposent une émulation d'appareil qui règle la taille du viewport, le User‑Agent et les capacités tactiles. C'est conçu pour les tests de responsive design et ne couvre que des signaux superficiels :

  • Il modifie le viewport et le User‑Agent mais pas navigator.platform
  • Les événements tactiles sont simulés au niveau de l'API, pas au niveau du moteur
  • devicePixelRatio peut être défini mais ne reproduit pas le comportement complet du pipeline de rendu
  • Les chaînes renderer WebGL continuent d'indiquer la GPU du desktop
  • La disponibilité des polices reste spécifique au desktop
  • Les media queries CSS peuvent ne pas s'aligner complètement avec la classe d'appareil émulée

Fermes de dispositifs physiques

Exécuter des tests sur dispositifs Android réels via BrowserStack ou Sauce Labs fournit des signaux mobiles authentiques. Toutefois, ces services sont coûteux à grande échelle, limités en sessions concurrentes et restreignent le niveau de contrôle d'automatisation. Ils ne permettent pas non plus des profils de fingerprint personnalisés ni l'isolation d'identité.

Émulateurs Android

Le SDK Android inclut un émulateur qui exécute des instances complètes d'Android. Bien que cela fournisse des signaux mobiles authentiques, chaque instance nécessite beaucoup de CPU et RAM. L'émulateur est lent à démarrer, difficile à automatiser à l'échelle et n'offre pas le même niveau de contrôle de fingerprint que BotBrowser.

Usurpation de User‑Agent

Définir une chaîne User‑Agent mobile dans un navigateur desktop est la solution la plus simple mais la plus incomplète. Cela modifie l'en‑tête User‑Agent et navigator.userAgent mais laisse toutes les autres signaux (support tactile, métriques d'écran, GPU, platform) en valeurs desktop.

Approche BotBrowser

Les profils Android de BotBrowser sont capturés depuis des appareils Android réels. Chaque profil contient l'ensemble complet des signaux mobiles du dispositif source. Lorsqu'ils sont chargés sur un OS de bureau, ces signaux sont appliqués au niveau du moteur.

Couverture complète des signaux mobiles

Un profil Android chargé sur un système desktop produit :

  • Support tactile avec maxTouchPoints, ontouchstart et les media queries CSS correctes
  • Dimensions d'écran et devicePixelRatio issues du dispositif source
  • Chaînes de platform ARM dans navigator.platform
  • User‑Agent mobile avec la version Android et le modèle corrects
  • Chaînes GPU mobiles dans le renderer WebGL
  • deviceMemory et caractéristiques de connexion appropriées
  • navigator.userAgentData avec mobile: true correct

Variantes Chrome et WebView

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

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

WebView modifie les tokens de marque dans les Client Hints et navigator.userAgentData pour correspondre à ce que présentent des apps comme Facebook ou TikTok.

Support tactile au niveau moteur

Contrairement à l'émulation 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 du dispositif source
  • ontouchstart est présent nativement sur window
  • Les media queries (pointer: coarse) et (hover: none) évaluent correctement
  • Les constructeurs et propriétés des événements tactiles se comportent comme sur des appareils mobiles réels

Configuration et utilisation

Profil Android de base

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

Intégration 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‑têtes de type app

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

Identidad móvil regional

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

Vérification

Vérifiez le profil Android en contrôlant des signaux spécifiques 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;
  }

  // Vérifier la media query CSS
  result.coarsePointer = matchMedia('(pointer: coarse)').matches;
  result.noHover = matchMedia('(hover: none)').matches;

  return result;
});

console.log('Android verification:', mobileCheck);
Android Profile Signals Touch maxTouchPoints: 5 pointer: coarse hover: none Screen 412 x 915 devicePixelRatio: 2.625 deviceMemory: 6 Navigator platform: Linux armv8l mobile: true Android 13 GPU Adreno (TM) 730 Qualcomm Mobile rendering

Bonnes pratiques

  • Utilisez defaultViewport: null dans Playwright et Puppeteer pour laisser le profil mobile contrôler les dimensions du viewport. Les surcharges de viewport du framework entreront en conflit avec les métriques d'écran du profil.
  • Choisissez des profils d'appareil appropriés. Faites correspondre l'appareil au marché cible. Les appareils Pixel sont populaires aux États‑Unis. Samsung Galaxy domine globalement. Les fabricants chinois (Xiaomi, OPPO) sont courants en Asie.
  • Associez des proxies mobiles. Pour une identité mobile la plus cohérente, utilisez des proxies mobiles ou résidentiels plutôt que des proxies de datacenter.
  • Utilisez la marque WebView pour les scénarios in‑app. Lors de la simulation de trafic depuis une application mobile, utilisez --bot-config-browser-brand=webview et ajoutez des en‑têtes x-requested-with appropriés.
  • Faites correspondre la locale au proxy. Réglez --bot-config-timezone, --bot-config-locale et --bot-config-languages pour correspondre à l'emplacement du proxy.
  • Définissez DISPLAY sur les serveurs Linux. Utilisez DISPLAY=:10.0 même en mode headless lors de l'exécution sur Linux.

FAQ

Puis‑je exécuter un profil Android sur un hôte macOS ?

Oui. Les profils Android fonctionnent sur n'importe quel OS hôte. Le binaire BotBrowser sur macOS, Linux ou Windows peut charger des profils Android et présenter une identité mobile complète.

Quelle est la différence entre les modes Chrome et WebView ?

Le mode Chrome se présente comme le navigateur Chrome autonome pour Android. Le mode WebView se présente comme le composant de navigateur embarqué utilisé par les apps natives. Les principales différences se situent au niveau des marques rapportées via Client Hints. Utilisez Chrome pour la navigation autonome et WebView pour les scénarios in‑app.

BotBrowser émule‑t‑il le comportement des événements tactiles ?

BotBrowser active le support tactile au niveau moteur, ce qui signifie que maxTouchPoints, ontouchstart et les media queries CSS rapportent des valeurs mobiles correctes. Générer des séquences réelles d'événements tactiles (tap, swipe, pinch) requiert votre framework d'automatisation. Playwright et Puppeteer prennent en charge les méthodes d'entrée tactile.

Comment fonctionne l'orientation d'écran ?

Les profils mobiles incluent les données d'orientation du dispositif source. L'API screen.orientation rapporte le type et l'angle corrects.

Puis‑je simuler différentes versions d'Android ?

Oui. Les profils capturés depuis différentes versions d'Android contiennent les informations de version correspondantes dans le User‑Agent, la version de plateforme et l'ensemble de fonctionnalités.

Qu'en est‑il des polices spécifiques au mobile ?

Les profils Android incluent l'environnement de polices Android (Roboto, Noto, DroidSans). Les requêtes de disponibilité des polices renverront l'ensemble de polices Android plutôt que des polices desktop.

Ai‑je besoin d'un matériel spécifique pour exécuter des profils Android ?

Non. Les profils Android s'exécutent sur tout matériel standard. Le profil contrôle les signaux que le navigateur rapporte, pas la manière dont le calcul est effectué. Toute machine pouvant exécuter le binaire BotBrowser peut charger un profil Android.

Résumé

L'émulation Android via les profils BotBrowser permet des identités complètes de navigateur mobile sur n'importe quel système desktop. Le support tactile, les métriques d'écran, les chaînes GPU et tous les autres signaux mobile sont contrôlés au niveau moteur, produisant une sortie qui correspond aux appareils Android réels sans la charge des appareils physiques ou des émulateurs.

Pour les sujets connexes, voir Device Emulation, Cross-Platform Profiles et Browser Brand Switching.

title: "Emulation Android : profils de navigateur mobile sur ordinateur" description: "Executez des profils Android Chrome et WebView sur n'importe quel OS de bureau avec BotBrowser pour une identite de navigateur mobile coherente." date: "2025-12-23" locale: fr category: platform tags: ["android", "emulation", "mobile", "platform", "webview"] published: true

Presentation

BotBrowser permet d'executer des profils de navigateur Android sur des systemes de bureau. Lorsqu'un profil mobile est charge, tous les signaux du navigateur se mettent a jour pour correspondre a un veritable appareil Android : dimensions d'ecran, support tactile, proprietes du navigator et plus.

Ce que BotBrowser controle

Ecran et viewport. Les profils mobiles incluent des dimensions d'ecran et des valeurs devicePixelRatio precises provenant de vrais appareils.

Evenements tactiles. Les profils mobiles activent de maniere coherente navigator.maxTouchPoints, ontouchstart et les media queries CSS (pointer: coarse) et (hover: none).

Navigator et plateforme. Les profils Android configurent navigator.platform avec la variante ARM appropriee, avec userAgent et userAgentData correspondants.

APIs mobiles. Les chaines du renderer WebGL signalent des GPUs mobiles, les listes de polices correspondent aux valeurs par defaut d'Android.

Android Chrome vs. WebView

# Lancer en Android Chrome
chrome --bot-profile="/path/to/android-profile.enc" \
       --bot-config-browser-brand=chrome

# Lancer en Android WebView
chrome --bot-profile="/path/to/android-profile.enc" \
       --bot-config-browser-brand=webview

WebView est le composant navigateur utilise par les apps Android pour afficher du contenu web, signalant des tokens de marque differents dans les Client Hints par rapport a Chrome autonome.

Exemple Puppeteer

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

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

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

Combinaison avec proxy et locale

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

Pour commencer

  1. Telechargez BotBrowser depuis GitHub
  2. Selectionnez un profil Android avec --bot-profile
  3. Optionnellement configurez la marque en webview avec --bot-config-browser-brand=webview
  4. Lancez et verifiez que les signaux mobiles sont coherents
#android#emulation#mobile#platform#webview