Подробнее по теме: читайте наш полный гайд — WebRTC на Android: SDK, захват, Compose UI (2026).
Демонстрация экрана через WebRTC на Android в 2026 году — это уже не задача на выходные: Android 14 сломал половину паттернов, которые работали в 2023-м. Если вы передаёте видео пользователям Android сегодня, вам нужен сервис в foreground типа mediaProjection, запущенный до запроса проекции, поддерживаемая библиотека WebRTC (официальная сборка от Google больше не работает) и продуманная UX-стратегия с учётом нового режима частичного захвата экрана, появившегося в Android 14+. Этот гайд проходит весь путь реализации, который команда Android в Форс Софт использует в боевых продуктах, таких как виртуальный класс BrainCert и система перевода VOLO.live на 22 000 участников, с код-скелетами, реальными бюджетами битрейта и пятью граблями, на которые наступают команды в продакшене.
Ключевые тезисы
- Перестаньте использовать google-webrtc. Официальная сборка не поддерживается с 2018 года. В 2026 году используйте getstream/webrtc-android (рекомендуем) или форк от LiveKit.
- Сначала foreground service, потом проекция. Android 14 требует именно такого порядка; если перепутать — приложение упадёт с
SecurityException. - 15 fps при 720p и 1,5–2 Mbps — реалистичные параметры для трансляции экрана по сотовой сети. 1080p стоит использовать только если вы уверены, что пользователь подключён к Wi-Fi.
- Частичный захват приложения в Android 14+ меняет принципы пользовательского интерфейса: теперь пользователь может выбрать только одно окно. Следите за событиями
onCapturedContentResizeиonCapturedContentVisibilityChanged. - Android 15 автоматически прекращает запись экрана на блокировке, скрывает содержимое уведомлений при проекции и предоставляет обратный вызов состояния записи, чтобы приложения могли защищать чувствительные экраны.
- Фора Софт внедряет новые функции быстрее за счёт повторного использования протестированного модуля захвата экрана в разных WebRTC-проектах — сроки и бюджет сокращаются на 30–40% по сравнению с разработкой с нуля.
Зачем мы написали это руководство
Фора Софт разрабатывает решения на базе WebRTC с 2010 года, включая Android-клиенты BrainCert (LMS с годовой выручкой 225 млн ₽), VOLO.live (22 000+ участников на Black Hat 2025) и Sprii (платформа live-коммерции с оборотом €365 млн+). Функция демонстрации экрана была реализована на нескольких Android-кодовых базах и для разных версий Android, и мы хорошо знаем, где возникают сложности.
Это руководство передаём новому Android-инженеру, который начинает работать над фичей демонстрации экрана в 2026 году. Каждый код-скелет компилируется, каждая цифра по битрейту взята из продакшен-трафика, каждая грабля — та, на которую мы наступили и которую починили.
Пропустить вперёд. Если нужен только код — переходите к скелету на Kotlin. Если у вас была работающая реализация, которая сломалась — читайте про изменения в Android 14. Если что-то горит в продакшене — идите к матрице диагностики.
Демонстрация экрана на Android — обзор за 60 секунд
На верхнем уровне путь демонстрации экрана в Android состоит из пяти подвижных компонентов:
1. MediaProjection. Системный API Android для захвата изображения с экрана. Требует согласия пользователя при каждом запуске.
2. Foreground service. В Android 14 media projection должна запускаться внутри foreground-сервиса типа mediaProjection, и сервис нужно запустить до получения проекции.
3. ScreenCapturerAndroid. Реализация VideoCapturer из библиотеки WebRTC, которая использует MediaProjection для получения потока кадров экрана.
4. PeerConnection. Абстракция WebRTC, отвечающая за ICE, сигнализацию и SRTP-шифрование с удалённым пиром.
5. Сигналинг. Внешний канал (WebSocket, SIP, кастомный), через который обмениваются SDP offer/answer и ICE-кандидатами.
Пропустите любой пункт — и функция не заработает. Перепутайте порядок на Android 14+ — и система завершит работу приложения.
Выбор библиотеки WebRTC в 2026 году
Это первое решение — и то, в котором большинство команд ошибается. org.webrtc:google-webrtc от Google не поддерживается с 2018 года, а готовая сборка исчезла вместе с закрытием JCenter. Если в ответе на Stack Overflow от 2025 года вам советуют использовать её — для 2026-го этот совет уже устарел.
Наш выбор для новых проектов: io.getstream:stream-webrtc-android. Библиотека активно развивается, следует за обновлениями WebRTC, имеет удобные API для Kotlin, поддерживает Jetpack Compose и не создаёт проблем с лицензированием.
// build.gradle.kts (Module: app)
dependencies {
implementation("io.getstream:stream-webrtc-android:1.3.6")
// optional Compose helpers
implementation("io.getstream:stream-webrtc-android-ui-compose:1.3.6")
}
Актуальную версию всегда проверяйте в репозитории GetStream/webrtc-android.
AndroidManifest.xml — разрешения и объявление сервиса
В Android 14 и выше пропущенные разрешения или неправильный тип сервиса могут сломать функцию — либо без предупреждения, либо с неясными ошибками. Здесь нужно в первую очередь всё привести в порядок.
<manifest ...>
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PROJECTION" />
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<application ...>
<service
android:name=".ScreenShareService"
android:foregroundServiceType="mediaProjection"
android:exported="false" />
</application>
</manifest>
Два неочевидных момента: FOREGROUND_SERVICE_MEDIA_PROJECTION обязателен с Android 14, POST_NOTIFICATIONS — с Android 13. Оба нужно указать в манифесте, а разрешение на уведомления — запросить во время работы приложения.
Foreground service — порядок вызовов, который ломает Android 14
Начиная с Android 14, startForeground нужно вызывать до getMediaProjection. Если порядок нарушить, приложение выбросит SecurityException. Скелет:
class ScreenShareService : Service() {
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
val notification = buildNotification()
startForeground(
NOTIF_ID, notification,
ServiceInfo.FOREGROUND_SERVICE_TYPE_MEDIA_PROJECTION
)
// NOW it's safe to grab the projection
val resultCode = intent!!.getIntExtra(EXTRA_RESULT_CODE, -1)
val data = intent.getParcelableExtra<Intent>(EXTRA_DATA)!!
val mp = mediaProjectionManager.getMediaProjection(resultCode, data)
startCapture(mp)
return START_STICKY
}
}
Что важно: передавайте resultCode и data Intent от проекции в сервис через putExtra. Intent проекции — одноразовый: если вы получили его в активности и потеряли, восстановить уже не получится.
Запрос проекции — это согласование действий пользователя
Пользователь должен подтверждать каждую сессию проекции. Диалог нельзя отключить. Процесс выглядит так: запускаем intent → получаем результат → передаём его в foreground service.
// In your Activity (Compose or View)
private val projectionLauncher = registerForActivityResult(
ActivityResultContracts.StartActivityForResult()
) { result ->
if (result.resultCode == RESULT_OK && result.data != null) {
val svc = Intent(this, ScreenShareService::class.java).apply {
putExtra(EXTRA_RESULT_CODE, result.resultCode)
putExtra(EXTRA_DATA, result.data!!)
}
ContextCompat.startForegroundService(this, svc)
}
}
fun requestScreenShare() {
val mpm = getSystemService(MediaProjectionManager::class.java)
projectionLauncher.launch(mpm.createScreenCaptureIntent())
}
Подключаем capturer к PeerConnection
Внутри сервиса передайте проекцию в ScreenCapturerAndroid, оберните её в VideoSource и добавьте полученный трек в ваш PeerConnection.
private fun startCapture(projection: MediaProjection) {
val eglBase = EglBase.create()
val factory = PeerConnectionFactory.builder()
.setVideoEncoderFactory(
DefaultVideoEncoderFactory(eglBase.eglBaseContext, true, true)
)
.setVideoDecoderFactory(
DefaultVideoDecoderFactory(eglBase.eglBaseContext)
)
.createPeerConnectionFactory()
val capturer = ScreenCapturerAndroid(
projectionData(projection),
object : MediaProjection.Callback() {
override fun onStop() { stopSelf() }
}
)
val sthelper = SurfaceTextureHelper.create("CaptureThread", eglBase.eglBaseContext)
val source = factory.createVideoSource(true) // isScreencast = true
capturer.initialize(sthelper, this, source.capturerObserver)
capturer.startCapture(1280, 720, 15) // width, height, fps
val track = factory.createVideoTrack("screen0", source)
peerConnection.addTrack(track, listOf("stream0"))
}
Ключевой флаг: createVideoSource(true) — параметр isScreencast заставляет WebRTC использовать профиль кодировщика, настроенный под экран (меньше ключевых кадров, битрейт подстраивается под содержимое). Забудешь этот флаг — и демонстрация экрана будет выглядеть плохо. Это самая частая ошибка.
Битрейт, частота кадров, разрешение — всё зависит от бюджета
Большинство команд выбирают цифры, которые хорошо смотрятся на маркетинговой странице (1080p, 30 fps), а потом релиз теряет кадры в сотовой сети. Цифры ниже — из реального трафика продакшена в выпущенных Android-приложениях Фора Софт.
Дефолт для продакшена: 1280×720, 15 fps, целевой битрейт 1,5 Mbps, максимум 2,5 Mbps. Такой формат работает почти на всех 4G-соединениях, отлично смотрится на 95% экранного контента и не нагружает CPU устройств среднего уровня.
Максимальный битрейт ставьте явно через RtpSender.parameters.encodings[i].maxBitrateBps. Без этого congestion control в WebRTC задушит звук и менее приоритетные потоки в том же соединении.
Кодеки — что использовать в 2026 году
Выбор кодека на Android в WebRTC зависит от поддержки кодека аппаратной частью устройства и от возможностей удалённого пира по его декодированию.
H.264. Универсальная аппаратная поддержка на Android. Лучший выбор по умолчанию для демонстрации экрана в 2026 году, потому что любое устройство кодирует его на уровне железа. Минус: сжимает хуже, чем VP9, на текстовом контенте.
VP8. Исторический стандарт по умолчанию в WebRTC. Поддерживается программно везде, аппаратно — зависит от устройства. На экране при одинаковом битрейте работает чуть лучше H.264.
VP9. Лучше сжимает изображения с большим количеством текста. Аппаратная поддержка на среднем Android — неравномерная. Подходит как способ обновления с возможностью программного отката.
AV1. Лучшее сжатие, но требует в 3–5 раз больше CPU, чем VP9. Аппаратные декодеры AV1 на Android в 2026 году — редкость, большинство устройств декодирует программно, и это быстро сажает батарею. AV1 SCC (Screen Content Coding) интересен для сверхнизкого битрейта при трансляции экрана (100–500 кбит/с), но массовое внедрение начнётся только в 2027–2028 годах.
Практический дефолт: H.264 с возможностью переключения на VP8. Договоритесь о кодеках через SDP munging — пусть удалённый браузер или приложение выберет подходящий. AV1 для демонстрации экрана пока не используйте, пока аппаратные декодеры не станут широко доступны — за исключением особых случаев с очень узкой полосой пропускания.
Захват системного звука вместе с экраном
Android 10+ предоставляет AudioPlaybackCaptureConfiguration, который позволяет записывать системный звук во время использования функции «проекции медиа». Это полезно, когда вы делитесь экраном и на нём воспроизводится видео или звуковые уведомления приложений.
val config = AudioPlaybackCaptureConfiguration.Builder(projection)
.addMatchingUsage(AudioAttributes.USAGE_MEDIA)
.addMatchingUsage(AudioAttributes.USAGE_GAME)
.build()
val audioRecord = AudioRecord.Builder()
.setAudioPlaybackCaptureConfig(config)
.setAudioFormat(...)
.setBufferSizeInBytes(bufferSize)
.build()
Подводные камни: приложения с флагом android:allowAudioPlaybackCapture="false" блокируют захват звука (так делают, например, банки и приложения с защитой контента). Микрофонный вход — это отдельный AudioRecord; объединяйте оба потока на сервере или на устройстве — в зависимости от задачи.
Изменения в Android 14 — частичный захват приложения и обратные вызовы при изменении размера
Android 14 принёс два серьёзных изменения, которые ломают наивные реализации:
1. Частичный захват приложения. ОС предлагает пользователю выбрать одно приложение для передачи, а не весь экран. Вашему коду ничего делать не нужно — проекция просто передаёт кадры выбранного приложения. Но возникает путаница: пользователь считает, что показывает слайды, а вы думаете, что он демонстрирует домашний экран.
2. Новые callbacks. MediaProjection.Callback#onCapturedContentResize(width, height) срабатывает, когда захватываемое приложение меняет размер. onCapturedContentVisibilityChanged(isVisible) сообщает, когда захватываемый контент становится невидимым — например, пользователь свернул приложение.
projection.registerCallback(object : MediaProjection.Callback() {
override fun onStop() { stopCapture() }
override fun onCapturedContentResize(w: Int, h: Int) {
capturer.changeCaptureFormat(w, h, 15)
}
override fun onCapturedContentVisibilityChanged(visible: Boolean) {
if (!visible) showResumePrompt()
}
}, handler)
Без них расшариваемое приложение в 1080×1920 может схлопнуться до 800×600, потому что пользователь перетащил его в режим разделённого экрана, и удалённый зритель увидит растянутую и размытое изображение.
Android 15 — остановка на экране блокировки и детектирование записи
Android 15 ещё сильнее усилил защиту приватности:
Автоматическая остановка при блокировке. Если пользователь заблокировал устройство, проекция останавливается автоматически. Чтобы продолжить, потребуется новое подтверждение. Планируйте UX с учётом этого: при разблокировке предлагайте пользователю начать демонстрацию заново.
Маскирование уведомлений. Во время проекции скрывается содержимое уведомлений. Пользователи видят только надпись «Уведомление» вместо реального текста.
Callback детектирования записи. Приложения теперь могут определить, что их записывают, с помощью MediaProjection.Callback#onRecordingStateChanged(). На чувствительных экранах (банкинг, ввод пароля, двухфакторные коды) приложение должно обнаруживать запись и не отображать содержимое.
Чип в статусной строке. Android 15 показывает постоянный чип в статусной строке во время проекции. По нему можно нажать, чтобы остановить демонстрацию. Приложение не может его скрыть.
Защита контента — FLAG_SECURE и DRM
Если вы делаете приложение, которое работает с чувствительными данными (банкинг, медицина, платный стриминг), вам нужно понимать, что значит FLAG_SECURE чужих приложений для вашего захвата экрана и что значит FLAG_SECURE у вас — для того, чтобы вас можно было захватить.
Захват защищённого контента. Окна приложений с FLAG_SECURE отображаются чёрным на скриншотах. Аппаратный DRM (Widevine L1) работает на уровне чипсета, и программные обходы не действуют.
Защита собственного контента. Если ваше приложение отображает информацию, которую нельзя записывать (PIN-коды, одноразовые пароли, личные данные), используйте window.setFlags(FLAG_SECURE, FLAG_SECURE) в нужных Activity. Начиная с Android 15 также реализуйте callback для отслеживания состояния записи — это дополнительная защита.
Сигналинг, ICE и TURN — связь, необходимая для демонстрации экрана
WebRTC требует канал сигналинга для обмена SDP offer/answer и ICE-кандидатами. Сам WebRTC такой канал не предоставляет — его нужно организовать отдельно (наиболее популярный выбор — WebSocket).
ICE-серверы. Настройте и STUN, и TURN. STUN обеспечивает прямую связь между пользователями при дружелюбных NAT. TURN необходим в мобильных сетях, потому что большинство сотовых CGN-сетей блокируют прямую связь между устройствами. В реальных развёртываниях используют 2–3 STUN- и 1–2 TURN-сервера в разных регионах.
Провайдеры TURN. Twilio Network Traversal Service, Xirsys, Cloudflare Calls TURN или self-hosted coturn. Закладывайте 0,3–0,7 ₽/мин на ретрансляцию трафика одного пользователя; на больших объёмах эти расходы легко перекрывают затраты на сигналинг и SFU.
Стратегия переподключения. Мобильные сессии демонстрации экрана длятся долго — обычно от 10 до 30 минут. Соединение WebSocket обязательно оборвётся. Реализуйте экспоненциальную задержку при переподключении с проверками активности (heartbeat) и заново согласуйте SDP, если новое соединение оказалось в другой IP-топологии.
Глубже про архитектуру — в наших гайдах по архитектуре WebRTC и реальным WebRTC-системам.
Ориентация, уход в фон и поворот экрана
Три условия во время выполнения молча ломают демонстрацию экрана, если их не обработать.
Поворот. При повороте устройства происходит изменение конфигурации. Capturer будет продолжать отправлять кадры в прежней ориентации, пока вы не вызовете capturer.changeCaptureFormat(width, height, fps) с новыми параметрами. Подписывайтесь на событие onConfigurationChanged на уровне сервиса или используйте DisplayManager.DisplayListener.
Уход приложения в фон. Пользователь может поделиться приложением и переключиться на другое. На Android 14+ это вызывает onCapturedContentVisibilityChanged(false) — покажите подсказку, чтобы пользователь вернулся.
Doze и оптимизации батареи. Уведомление о foreground-сервисе защищает приложение от остановки из-за неактивности, но режим Doze может ограничивать доступ к сети. Для длительных сессий запросите исключение из оптимизаций батареи (REQUEST_IGNORE_BATTERY_OPTIMIZATIONS) с понятным объяснением для пользователя — в Google Play действуют строгие правила против злоупотреблений.
Матрица диагностики — симптомы и причины
Стратегия тестирования — как проверить перед релизом
Демонстрацию экрана сложно покрыть юнит-тестами — она зависит от реальной графики, реальной сети и реальных пользователей, которые нажимают кнопки в системных диалогах. Наша пирамида тестов:
Юнит-тесты. Замокайте MediaProjection; тестируйте жизненный цикл — обработку интента, порядок запуска сервиса, подключение колбэков. Это ловит баги «неправильного порядка».
Инструментальные тесты на Firebase Test Lab. Запуск на реальных устройствах с Android 11, 12, 13, 14, 15. С помощью UiAutomator проверяйте, что появляется диалог захвата экрана и что ваш сервис запускается. Прогоны в лаборатории нестабильны, но хорошо выявляют регрессии по семействам устройств.
Ручная матрица. Тестируйте на Pixel 6+ (Android 14–15), Samsung Galaxy A-серии (Android 13–14), Xiaomi Redmi (Android 12–13). Эти три семейства охватывают 90% проблем совместимости.
Шейпинг сети. Используйте adb shell tc или прокси вроде Charles Network Conditioner, чтобы смоделировать 3G, нестабильный 4G и частые переключения сети. Большинство багов, возникающих в реальных условиях, можно воспроизвести именно так.
Продакшен-аналитика. Логируйте ключевые метрики WebRTC (битрейт, потерянные пакеты, частоту кадров) по каждой сессии в бэкенд. Без этого не получится разобраться с жалобами пользователей.
Как крупные приложения подходят к демонстрации экрана на Android
Zoom. Проприетарный набор кодеков, оптимизированный для работы в реальном времени. Использует аппаратное кодирование, если оно доступно, и активно снижает битрейт при перегрузке сети. По умолчанию ограничивает разрешение до 720p при подключении через сотовую сеть.
Google Meet. Работает на базе WebRTC; нативное приложение для Android использует кодек VP8 для передачи экранного контента с возможностью переключения на H.264. Цель — 1,5 Мбит/с при разрешении 720p и частоте кадров 15 Гц для демонстрации экрана.
Microsoft Teams. Кастомный видеопайплайн, оптимизированный под корпоративные сети: стабильная работа при пропускной способности 1–1,5 Мбит/с при разрешении 720p и частоте кадров 15 fps. При недостаточной скорости сети система плавно переключается на текстовый или аудио режим.
Discord. Работает на базе WebRTC; по умолчанию — 30 кадров в секунду для игр, при нагрузке автоматически снижается до 15. Для трансляции экрана используется кодек VP8.
Slack Huddles. WebRTC; консервативные 500–1000 кбит/с при 720p; делают приоритетом доступность на слабых сетях, а не визуальное качество.
Все они перешли с чистой peer-to-peer архитектуры на SFU. Подробнее о SFU и P2P — в нашем гайде по архитектуре WebRTC.
Кейсы — как мы реализовывали это на реальных проектах Фора Софт
BrainCert — виртуальный класс на WebRTC, LMS. Более 100 000 платящих клиентов, годовая выручка — 225 млн ₽. Преподаватели демонстрируют экраны своих Android-устройств, чтобы разобрать задачи. Наша реализация работает в разрешении 1280×720, 15 кадров в секунду, с целевым битрейтом 1,2 Мбит/с и фолбэком на TURN; стабильное качество даже при слабом 4G в учебных центрах Индии и Юго-Восточной Азии.
Телемедицинские проекты. Врачи иногда показывают экран Android, чтобы провести пациента по портальным сценариям. Мы по умолчанию устанавливаем флаг FLAG_SECURE в приложении врача, чтобы пациент не мог сделать скриншот или записать экран; события обнаружения записи логируются для проверки соответствия требованиям.
Sprii — лайв-шопинг. Ведущие показывают крупные планы товаров; мы повышаем fps до 24 для плавного движения при разрешении 720p. Синхронизация аудио и видео обеспечивается за счёт transport-wide CC в WebRTC.
Вывод Фора Софт
Демонстрация экрана на Android — это вопрос корректной работы жизненного цикла, а не выбора кодека. Правильно настройте запуск foreground service, обработайте новые callback’и в Android 14, предусмотрите повторное согласие в Android 15 — и остаётся только оптимизация. Наш подход Agent Engineering позволяет использовать эту работу в разных проектах, поэтому сроки и бюджет на 30–40% ниже, чем при разработке с нуля.
Тренды 2026–2027, на которые стоит ориентироваться при планировании
AV1 станет массовым к 2028 году. Аппаратные энкодеры появляются в топовых процессорах Snapdragon; средний сегмент будет отставать. До 2027 года используйте VP8 и H.264 по умолчанию, AV1 — как дополнительный вариант.
AI-аугментация захвата. Размытие фона, отслеживание объектов, автоматическая обработка конфиденциальных участков на устройстве — всё это становится стандартом. WebRTC-приложения 2027 года будут запускать небольшую ML-модель на каждом кадре.
Усиление приватности в Android 16. Ожидаем более точные типы intent-ов для записи экрана — например, разделение на коммерческую запись и личную демонстрацию, обязательные аудит-логи и, возможно, автоматический отзыв разрешений при длительной неактивности.
WebRTC-NV. Лучший контроль загрузки сети (gcc-next), нативная поддержка аппаратного кодирования AV1, расширения масштабируемости RTC. Android обычно отстаёт от десктопных версий на 2–3 года.
MoQ (Media over QUIC). Возможная долгосрочная замена части WebRTC. В 2026 году ещё не готов для использования в продакшене, но стоит следить за ним для проектов 2028 и позже.
Когда НЕ стоит делать демонстрацию экрана на Android WebRTC самим
Скажем честно: это одна из самых сложных фич Android — чтобы реализовать её правильно. Три сценария, когда лучше купить готовое решение или найти партнёра, а не разрабатывать с нуля.
1. Вам нужно через 4 недели. Команда, новая в WebRTC, всегда недооценивает объёмы тестирования. Берите LiveKit Cloud, Daily или 100ms; выкатывайтесь за две недели; перепишете потом, если понадобится.
2. У вас один продукт в одной стране. Фиксированные затраты на его сборку плохо конкурируют с оплатой 0,4–0,7 ₽ за минуту участника managed- SFU.
3. У вас нет Android-инженера, который разбирается в foreground services. Наймите специалиста или работайте с партнёром — не проверяйте это на своих пользователях.
Похожие материалы
Гайд по архитектуре WebRTC для бизнеса в 2026 году — SFU, MCU, mesh: как выбрать.
AI + WebRTC — как умные агенты меняют коммуникацию в реальном времени — следующий уровень стека.
Услуги разработки WebRTC от Фора Софт — что мы делаем для клиентов.
Разбор стоимости WebRTC-разработки — как на самом деле выглядят бюджеты.
Сравнение альтернатив Agora.io — если вы выбираете управляемый SFU.
Часто задаваемые вопросы
Можно ли захватывать экран без запроса разрешения?
Нет. Диалог согласия MediaProjection управляется операционной системой, и на серийных устройствах его нельзя отключить. Обойти его могут только привилегированные системные приложения (предустановленные производителем с разрешением CAPTURE_VIDEO_OUTPUT); обычным приложениям это недоступно.
Почему мои захваченные кадры чёрные?
У захватываемого приложения или окна установлен флаг FLAG_SECURE, либо оно отображает DRM-защищённый контент (например, Netflix, Disney+, банковские приложения). Это ограничение обеспечивается на уровне операционной системы и аппаратного обеспечения и обойти его невозможно. Опишите это ограничение явно; не обещайте пользователям, что они смогут поделиться экраном с банковским приложением.
Нужен ли foreground service, если приложение и так на переднем плане?
Начиная с Android 14 — да: даже если ваше приложение сейчас открыто, проекция должна работать в foreground service типа mediaProjection. Иначе ОС выбросит SecurityException.
Какой FPS брать для демонстрации экрана?
15 кадров в секунду — хороший выбор по умолчанию для большинства случаев. Используйте 5–10 кадров в секунду для статичных документов и слайдов, 24–30 — для видео и анимации. Более высокая частота кадров требует больше пропускной способности и ресурсов процессора, но редко заметно улучшает восприятие неподвижного контента.
Можно ли транслировать экран без WebRTC?
Да — можно захватывать кадры через MediaProjection и передавать их по RTSP, RTMP, HLS или HTTP. WebRTC лучше подходит для сценариев с минимальной задержкой, прямой передачи между устройствами или через SFU; RTMP — для вещания одному из многих, где задержка в 3–6 секунд допустима.
Как захватывать звук вместе с экраном?
Используйте AudioPlaybackCaptureConfiguration (Android 10+) вместе с проекцией, чтобы записать системный звук. Если нужно одновременно использовать и системный звук, и запись с микрофона, микшируйте их с помощью AudioRecord. Приложения, в которых установлено allowAudioPlaybackCapture="false", нельзя захватить — это решение разработчика исходного приложения.
Какое максимальное разрешение можно захватить?
Ограничено только разрешением дисплея устройства. На практике для передачи стоит уменьшать до 1280×720 или 1920×1080: нативное разрешение (например, 3200×1440) — расточительно, и удалённый зритель всё равно его уменьшит.
Поддерживается ли демонстрация экрана на Android 9 и ниже?
MediaProjection доступен с Android 5.0 (API 21). Однако требования к foreground service сильно менялись в Android 8, 10, 13 и 14, из-за чего единая кодовая база, поддерживающая старые и новые версии, приводит к сильному ветвлению. К 2026 году поддержка версий ниже Android 10 будет иметь мало смысла — более 95% активных Android-устройств работают на Android 11 и выше.
Можно ли это сделать, не обращаясь к нативному коду?
Да — LiveKit, Daily и 100ms предлагают высокоуровневые Android-SDK, которые скрывают MediaProjection и WebRTC за простым API. Если вам не нужен тонкий контроль — это самый быстрый способ.
Читать дальше
Архитектура
Архитектура WebRTC для бизнеса в 2026 году
SFU, MCU, mesh: что выбрать под ваш масштаб.
AI + RTC
AI-агенты на WebRTC — плейбук
Где медиа реального времени встречается с агентным ИИ: стоимость, задержка, выбор фреймворка.
Стоимость
Стоимость разработки WebRTC
Сколько команды реально платят за выпуск WebRTC-фич в 2026 году.
Вендор
Сравнение альтернатив Agora.io
Если вы выбираете managed-SFU вместо самостоятельного построения.
Кейс
BrainCert — виртуальный класс на базе WebRTC
Демонстрация экрана в продакшене на проекте с годовой выручкой 225 млн ₽.
Кейс
VOLO.live — система перевода в реальном времени
22 000+ участников на Black Hat 2025.
Итог — как запустить демонстрацию экрана через Android WebRTC в 2026 году
Возьмите поддерживаемый форк WebRTC (getstream/webrtc-android), объявите foreground service типа mediaProjection, запустите сервис до запроса разрешения на проекцию экрана, передайте проекцию в ScreenCapturerAndroid и добавьте полученный трек в PeerConnection с параметром isScreencast=true. По умолчанию используется разрешение 720p, 15 кадров в секунду и битрейт 1,5 Мбит/с. Отслеживайте события изменения размера и видимости экрана в Android 14 и выше; планируйте остановку при блокировке экрана в Android 15; предусмотрите использование TURN-серверов как резервный вариант для сотовых сетей. Проведите тестирование на устройствах Pixel, Samsung и Xiaomi.
Фора Софт уже реализовала этот паттерн в нескольких боевых Android-приложениях, включая BrainCert, VOLO.live и Sprii. Если вы начинаете с нуля или пытаетесь исправить застрявший WebRTC-проект — следующий шаг — 30-минутный звонок для обсуждения задач.
Делаете WebRTC на Android?
Получите фиксированную оценку за 48 часов.
Мы определим объём работы по функции демонстрации экрана, подберём подходящий WebRTC-стек и согласуем стоимость — с оценками на 30–40% ниже агентских ставок благодаря нашему подходу Agent Engineering.
