Эмуляция медленного интернета на Android: 5 методов (2026)

Почему Фора Софт написала этот плейбук

Мы в Фора Софт создаём Android-приложения с 2005 года, и общий мотив 625+ выпущенных продуктов — это медиа: видео в реальном времени, голос, потоки видеонаблюдения, телемедицинские визиты, виртуальные залы суда. Все они первыми ломаются на плохой сети. Поэтому эмуляция медленной сети — не галочка в нашем QA-процессе, а профиль по умолчанию, который наши Android-сборки обязаны пережить, прежде чем попасть в основную ветку.

Этот гайд — краткая версия инструкции, которую мы выдаём каждому новому Android-инженеру. В основе — проекты вроде Valt (платформа удалённых допросов для правоохранительных органов США), CirrusMED (телемедицина с видеоконсультациями) и BrainCert (живые e-learning классы для студентов с нестабильной мобильной связью). На этих проектах плохая сеть — не крайний случай, а боевая среда.

Если ваше Android-приложение делает что-то сложнее, чем загрузка JSON — видео, чат в реальном времени, загрузку файлов, платежи, фоновую синхронизацию — пять методов ниже должны быть встроены и в ваш цикл разработки, и в CI. Дальнейший текст — о том, как это делаем мы.

Что на самом деле означает «медленный» Android в 2026 году

«Медленный» — это три числа, а не одно: пропускная способность (кбит/с вверх и вниз), задержка (RTT в мс плюс джиттер) и потери пакетов (%). Любой инструмент, который позволяет крутить только полосу, прячет от вас самые интересные баги. В таблице ниже — короткий список профилей, на которых мы прогоняем каждую медийную сборку под Android. Они соответствуют тому, что Ookla в 2026 году показывает в Global Mobile Speed Index для «хвостовых» рынков, и тому, что мы видим на реальных устройствах в сельских развёртываниях.

Два неочевидных профиля — это «EDGE дно» и «Wi-Fi с потерями». EDGE по-прежнему представляет реальный сегмент пользователей на развивающихся рынках и в подземном транспорте. Wi-Fi с потерями — это случай переговорной и кофейни: высокая пропускная способность, дикий джиттер, рваные потери. Это главный источник тикетов «у меня за столом всё работает, а в переговорке видеозвонок отваливается».

Пять методов, которые реально сдвигают стрелку

За годы мы перепробовали десятки подходов. Выжили пять. Каждый из них бьёт по своему уровню стека — поэтому в итоге вы используете как минимум два параллельно.

Метод 1 — Android-эмулятор: netspeed и netdelay

Это самый быстрый способ увидеть, как приложение ведёт себя на радио 2G или 3G. Это же и самый недопонятый инструмент в списке, потому что названия предустановок обещают больше, чем дают.

Командная строка

Запустите эмулятор с предустановкой и задержкой:

emulator -avd Pixel_8_API_34 -netspeed edge -netdelay umts
# netspeed options: gsm hscsd gprs edge umts hsdpa lte evdo full
# netdelay options: gprs edge umts none (or a number in ms)

Менять профиль на лету

Подключитесь к консоли AVD и меняйте профиль на ходу — именно так мы тестируем переходы между радиосетями в видеоприложениях:

adb emu network speed edge
adb emu network delay 500
adb emu network speed full   # back to line rate

Шпаргалка по предустановкам (приблизительные up / down)

gsm 14,4 кбит/с симметрично. hscsd 14,4 / 57,6 кбит/с. gprs 28,8 / 57,6 кбит/с. edge 473 кбит/с симметрично. umts 384 кбит/с симметрично. hsdpa 5,76 / 13,98 Мбит/с. lte 58 / 173 Мбит/с. full без ограничений.

Чего он не делает

Throttling эмулятора — без потерь и без джиттера. Он не покажет шторм повторных отправок в WebRTC, потоп TCP-ретрансмитов или баги retry-бюджета. Он также с удовольствием пропустит приложение, которое «прошло» на профиле edge, но падает на реальной EDGE с потерями 3%. Относитесь к нему как к инструменту разработчика, а не как к QA-шлюзу.

Метод 2 — tc и netem: настоящая сетевая лаборатория

Если вы хотите нагрузить реальное Android-устройство, пустите его через Linux-машину (или Raspberry Pi в роли Wi-Fi-точки) и шейпите исходящий интерфейс с помощью tc. NetEm даёт задержку, распределения джиттера, лимиты полосы, потери пакетов (равномерные или всплесковые), дублирование, искажение и переупорядочивание — полное меню деградации.

Профиль «плохой 3G»

# on the router / hotspot, shape wlan0
sudo tc qdisc add dev wlan0 root handle 1: htb default 10
sudo tc class add dev wlan0 parent 1: classid 1:10 htb rate 780kbit ceil 780kbit
sudo tc qdisc add dev wlan0 parent 1:10 handle 10: \
  netem delay 300ms 100ms distribution normal loss 2% 25%

Профиль «хороший LTE»

sudo tc qdisc replace dev wlan0 root netem delay 50ms 10ms rate 25mbit

Профиль «Wi-Fi с потерями» (всплесковый)

sudo tc qdisc replace dev wlan0 root netem \
  delay 40ms 120ms distribution paretonormal loss 8% 30% reorder 25% 50%
# clean up
sudo tc qdisc del dev wlan0 root

Как превратить это в стадию CI

Заверните каждый tc-профиль в shell-скрипт, прогоните набор Espresso или Appium, затем разберите конфигурацию. В большинстве Android-репозиториев мы держим папку network-profiles/ с edge.sh, poor-3g.sh, lossy-wifi.sh и reset.sh. GitHub Actions с привилегированными контейнерами справляются с этим аккуратно; собственный раннер на Hetzner AX дешевле GitHub примерно после 100 минут в день.

Метод 3 — Charles Proxy и Proxyman: throttling на уровне HTTP

Для REST, GraphQL и любого HTTPS-трафика перехватывающий прокси даёт throttling по хосту, переписывание запросов и контроль задержки — без root. Укажите в Wi-Fi на Android прокси-адрес ноутбука, установите корневой сертификат Charles или Proxyman через исключение Network Security Config — и вы внутри.

Встроенные предустановки throttle

56k Modem 56 кбит/с. ISDN/DSL 512 кбит/с. ADSL 2 Мбит/с. ADSL2+ 16 Мбит/с. Fibre 32–100 Мбит/с. 3G HSPA 1,6 Мбит/с вниз / 768 кбит/с вверх, 150 мс задержки, 2% потерь. 4G настраивается. Это значения по умолчанию в Charles 5.x 2026 года и в Proxyman Network Conditioner.

Выборочный throttling по хосту

Ограничивайте только api.yourcompany.com, оставляя аналитику и отчёты о сбоях на полной скорости. Так вы изолируете, какой именно экран на самом деле тормозит из-за медленного API.

Метод 4 — удалённый Chrome DevTools для WebView и PWA

Если ваше Android-приложение использует WebView, Trusted Web Activity, PWA или Chrome Custom Tabs, chrome://inspect в десктопном Chrome даёт вам полную панель Network в DevTools для контента на устройстве. Предустановки: Slow 3G около 500 кбит/с вниз, 500 кбит/с вверх, задержка 2 000 мс. Fast 3G 1,5 Мбит/с вниз, 750 кбит/с вверх, задержка 562 мс. Slow 4G и Fast 4G добавлены в Chrome 115+. Кастомные профили позволяют выставить точные кбит/с и задержку.

DevTools throttling работает на стороне клиента, внутри рендерера. Он не влияет на нативный трафик OkHttp или Retrofit. Для гибридных приложений совмещайте его с Методом 3 (Charles на нативной стороне), чтобы увидеть полную картину.

Метод 5 — фермы устройств с сетевыми профилями

Ничего из того, что вы запускаете на ноутбуке, не поймает баги, рождающиеся из реальных радиомодулей на двухстах разных телефонах. Фермы устройств это делают. Три из них, на которые стоит смотреть для Android в 2026 году:

Три бонусных инструмента «про запас»

1. Toxiproxy. TCP-прокси от Shopify, принимающий «токсики»: задержку, полосу, таймауты, slow_close, slicer. Запускается в контейнере рядом с вашим API в CI. Если бэкенд у вас, Toxiproxy позволяет инъектировать сбои выше по стеку, а не шейпить клиентскую сеть.

2. Clumsy (Windows). Замена tc/netem, когда лабораторные машины на Windows. Под капотом использует WinDivert. Поддерживает lag, drop, throttle, перестановку пакетов, искажение.

3. Network Link Conditioner (macOS). Системный шейпер от Apple (часть Xcode Additional Tools). Полезен, когда ваш рабочий Mac играет роль Wi-Fi-моста для Android-устройства: переведите NLC в «3G» или «Edge» — и Android в этой Wi-Fi-сети унаследует профиль.

Набор ADB: скриптование режима «в самолёте» и Wi-Fi

Сам ADB не умеет throttling, но это правильный инструмент для второго класса багов медленной сети — переходов связности.

# toggle airplane mode (requires Android < 13 or system app on 13+)
adb shell settings put global airplane_mode_on 1
adb shell cmd connectivity airplane-mode enable   # API 30+

# only cellular in airplane mode, keep Wi-Fi and Bluetooth
adb shell settings put global airplane_mode_radios cell

# toggle Wi-Fi
adb shell svc wifi disable
adb shell svc wifi enable

# drop cellular data
adb shell svc data disable

Заверните это в @Rule в Espresso, чтобы проверять поведение на переходах. WorkManager-задача с повтором, которая молча теряет работу, когда Wi-Fi пропадает в середине загрузки, — это самый частый баг «у разработчика на столе всё работает, в проде падает», который мы исправляем.

WebRTC, HLS и видео на «больной» сети

Большинство интересных багов, которые мы чиним в Фора Софт, живут в медийных пайплайнах. Три эмпирических правила, которые экономят недели отладки:

1. Тестируйте WebRTC на 300, 150 и 80 кбит/с. По умолчанию в libwebrtc начальная оценка битрейта — 300 кбит/с; пробинг поднимает её до 900 и 1800. На 150 кбит/с вы в режиме выживания — отбрасываются simulcast-слои, VP9 уходит в нижнее пространственное разрешение. На 80 кбит/с вы должны быть только в аудио. Проверьте, что UI честно отражает этот переход, а не показывает замёрзшую видеоплитку.

2. Лестницы HLS должны начинаться с 480p / 800 кбит/с. Любая более высокая первая ступенька — и пользователи EDGE смотрят на спиннер 10+ секунд, прежде чем плеер опустится ниже. Держите сегменты по 2–6 с, буфер 30–60 с в установившемся режиме и агрессивно переключайтесь на ступень ниже при буфере менее 4 с.

3. Эмулируйте потери пакетов, а не только полосу. Видеокодеки терпят низкую полосу довольно изящно. 5% случайных потерь они не терпят. Берите Метод 2 (tc/netem), если ваше приложение работает с живым видео — наш гид по оптимизации Android-стриминга разбирает паттерны устойчивости к потерям, которые мы используем в продакшене.

Сначала offline-first, потом throttle-тесты

Эмуляция медленных сетей только показывает, где приложение ломается. Исправлять — структурно. Три паттерна, которые мы применяем в каждом Android-проекте, где сети нельзя доверять:

1. Room + StateFlow как источник истины. UI читает из Room, синхронизирующий слой пишет в Room. Сети приходят и уходят, UI — нет. Room 3.0 (2026) переехал на androidx.sqlite и стал coroutine-first, что убрало большую часть бойлерплейта, который раньше приходилось писать.

2. WorkManager с экспоненциальным откатом и ограничениями. Используйте BackoffPolicy.EXPONENTIAL (30 с → 60 с → 120 с), привязывайтесь к NetworkType.CONNECTED и уважайте заголовки Retry-After — возвращайте Result.retry() только после паузы, которую подсказал сервер.

3. Кэш OkHttp + Cache-Control как запасной вариант. Дисковый кэш 10 МБ с only-if-cached при офлайн-повторе превращает режим «в самолёте» из «пустого экрана» в «последнее известное состояние». Одно это изменение обычно вытаскивает приложение из категории «непригодно офлайн» в отзывах пользователей.

Мини-кейс — снижение потерь crash-free на 40% в Android-приложении телемедицины

Ситуация. Американская телемедицинская платформа (по объёму близкая к нашему проекту CirrusMED) выпускала видеоконсультации на Android поверх WebRTC. Пациенты в сельской местности на 3G жаловались на чёрный экран в звонках и зависания приложения. Crashlytics показывал ANR на уровне 1,2% и оценку crash-free-sessions 97,1% — заметно ниже порога Play vitals.

План на 12 недель. Мы подняли CI-стадию tc/netem с тремя профилями (EDGE «дно», плохой 3G, Wi-Fi с потерями), прогоняющую регрессионный набор Appium. Отдельно мы выборочно ограничили полосу сигнального хоста WebRTC через Charles, чтобы воспроизвести конкретный баг с чёрным экраном прямо за столом. Список фиксов: отключение simulcast ниже 200 кбит/с, добавление предварительного зондирования полосы перед звонком, прелоадинг сплэша WebView из кэша OkHttp, более агрессивный экспоненциальный откат WorkManager (15/30/60 с) для очереди консультаций.

Итог. Crash-free sessions поднялись с 97,1% до 99,6%. ANR упал с 1,2% до 0,18%, перешагнув порог Play vitals. Время до первого кадра в звонках снизилось с 6,4 с до 2,1 с на профиле «плохой 3G». Хотите такую же оценку для своего приложения? Мы можем спланировать аудит на один спринт для большинства Android-приложений.

Модель затрат: сколько на самом деле стоит настройка тестов на медленной сети

Ниже — порядковые цифры, которые мы видим на проектах с двумя-четырьмя Android-инженерами и средним CI. Мы строим процессы через Agent Engineering — наши пайплайны легче среднего по отрасли, так что цифры на нижней границе.

Фреймворк принятия решения — выберите стек за пять вопросов

1. Стримит ли ваше приложение аудио или видео? Если да, Метод 2 (tc/netem) — обязателен. Тестирование только полосы пропустит баги, связанные с потерями пакетов.

2. Целите ли вы в развивающиеся рынки или сельские регионы? Если да, профили «EDGE дно» и «плохой 3G» должны прогоняться в CI на каждом PR, а не только перед релизом.

3. Какое у вас приложение — нативное, гибридное или PWA? Нативное — Метод 3 (Charles). Гибридное — Метод 3 + Метод 4 (DevTools) в связке. PWA — Метод 4 плюс Lighthouse.

4. Сколько OEM показывает ваша аналитика? До 10: эмулятор + одно реальное устройство — хватит. 10–30: Firebase Test Lab ночью. 30+: BrowserStack или HeadSpin.

5. Какой тренд у вас в Play vitals? Если ANR выше 0,47% DAU или холодный старт выше 5 с на устройствах p50 — у вас проблема дистрибуции, а не отделки. Тестирование на медленной сети сейчас важнее новых функций.

Пять ловушек, которые мы видим на каждом аудите

1. Тестирование только на Wi-Fi. Полоса у Wi-Fi высокая, но и джиттер у него высокий. Это не замена 4G и тем более не замена EDGE. Каждый релиз должен пройти как минимум один профиль, сформированный под сотовую сеть.

2. Throttling только на скачивание. На реальной мобильной сети загрузка обычно в 3–10 раз медленнее скачивания. Если приложение грузит фото, видео или большие пакеты данных, тестируйте асимметрию.

3. Игнорирование переходов «офлайн → онлайн». Большинство Android-сбоев на плохой сети происходит не в момент медленного соединения, а на стыке, когда связь восстанавливается и приложение заливает сервер очередью из накопленных запросов.

4. Фиксированная задержка без джиттера. Реальные сети дрожат. Фиксированные 300 мс маскируют баги настройки таймаутов, которые нормальное распределение 300 мс ± 100 мс вскрывает уже на первом прогоне.

5. Измерение средних, а не процентилей. Пользователь, который жалуется на приложение, живёт в p95, а не в среднем. Снимайте p50, p95 и p99 времени загрузки в throttle-тестах и ставьте релизные шлюзы по p95.

KPI: что измерять в throttle-прогоне

KPI качества. Время до первого кадра — менее 2,5 с на «плохом 3G» для видеоэкранов. Холодный старт менее 5 с на «EDGE дне». Время от взаимодействия до ответа — менее 200 мс после того, как запрос покинул провод.

Бизнес-KPI. Crash-free sessions ≥ 99,5% по всем профилям. ANR менее 0,47% DAU (порог Play vitals). Доля завершённых критических флоу (регистрация, оплата, вход в звонок) ≥ 95% на «плохом 3G».

KPI надёжности. Доля успешных повторов более 90% по transient-ошибкам. Время «прокачки» очереди WorkManager — менее 60 с после возврата в онлайн. Никаких потерь данных в циклах «в самолёте» (round-trip-тест Room).

Когда не стоит переинвестировать в тесты на медленной сети

Если ваше приложение — внутренний B2B-инструмент, которым пользуются только в офисной Wi-Fi-сети, или планшетный киоск на проводном LAN, тратить инженеро-недели на EDGE-профили — не тот приоритет. То же самое, если аналитика показывает менее 0,5% сессий ниже 2 Мбит/с на скачивание, а Play vitals у вас чистые.

Планка не «эмулировать всё подряд». Планка — покрыть профили, на которых реально живут ваши пользователи, плюс один защитный уровень ниже. Для потребительского Android-приложения в 2026 году это почти всегда «EDGE дно» + «плохой 3G» + «хороший LTE» как минимум.

FAQ

Нужно ли получать root на Android-устройстве, чтобы эмулировать медленную сеть?

Нет. Все пять методов в этом гайде работают на устройствах без root. Метод 2 (tc/netem на хосте или роутере) — самый частый подход, когда root недоступен.

Не вредит ли эмуляция медленной сети устройству и не разряжает ли батарею?

Не вредит — throttling работает на уровне сетевого стека в ПО, а не на железе радиомодуля. Расход батареи во время тестов может слегка вырасти, потому что радиомодуль и логика повторов дольше остаются активными, но это неотличимо от обычного дня со слабым сигналом.

Как восстановить нормальную скорость сети после тестов?

Откатите ту настройку, которую меняли. Для эмулятора — adb emu network speed full. Для tc/netem — sudo tc qdisc del dev wlan0 root. В Charles или Proxyman — выключите Throttle. В DevTools — переключите профиль Network в «No throttling».

Можно ли ограничить полосу только для одного API-хоста, а не для всего приложения?

Да. И Charles Proxy, и Proxyman поддерживают throttling по хосту — добавьте имя хоста (например, api.example.com) в список «только эти хосты» в настройках Throttle. Toxiproxy делает то же самое на уровне TCP, если запустить его сайдкаром к вашему бэкенду.

Как лучше всего тестировать WebRTC под потерями пакетов?

Используйте Метод 2 (tc/netem) на Linux-машине, играющей роль Wi-Fi-точки для Android-устройства. Прогоните профили с потерями 1%, 3% и 8%, добавьте 100 мс джиттера и смотрите на getStats(). Charles и эмулятор не умеют нормально эмулировать потери.

Поддерживает ли Android-эмулятор потери пакетов?

Нет. Throttling эмулятора показывает только полосу и фиксированную задержку. Это и есть главная причина, по которой кроме него нужны Метод 2 (tc/netem) или Метод 5 (фермы устройств с кастомными профилями).

Как автоматизировать тесты медленной сети в CI?

Заверните профили tc/netem в shell-скрипты, вызывайте их из стадии GitHub Actions или Jenkins перед набором Espresso или Appium и разбирайте конфигурацию на teardown. В BrowserStack App Automate передавайте networkProfile в блоке capabilities (например, 3g-umts-good).

Найдёт ли тестирование медленной сети все сетевые баги?

Нет. Оно ловит основную массу багов в таймаутах, повторных запросах, UX и адаптации к полосе. Серверные регрессии, отказы DNS и специфичные для операторов middlebox-устройства оно не ловит. Для этого совмещайте его с канареечными выкатками на реальных устройствах и наблюдаемостью на бэкенде.

Что почитать дальше

Готовы выпустить Android-приложение, которое выживает в реальных сетях?

Берите два метода, а не один. Throttling в эмуляторе — для цикла разработки, tc/netem плюс ферма устройств — для CI и релизных шлюзов. Покрывайте «EDGE дно», «плохой 3G», «типичный мобильный» и «Wi-Fi с потерями». Измеряйте p95, а не среднее. Ограничивайте полосу и на загрузку тоже, добавляйте джиттер, добавляйте потери пакетов.

Затем встройте фикс-лист в Room, WorkManager и OkHttp, чтобы приложение по умолчанию было offline-first. Эта последовательность — эмулировать, измерить, исправить, эмулировать заново — и есть разница между приложением, которое проходит Play vitals на устройствах p50, и тем, которое удерживает свои четыре звезды на развивающихся и сельских рынках.