2014-11-06 4 views
1

Я создаю приложение, которое должно реализовать экранирование ~ зеркалирования ~ для любого без корневого устройства с Android 4 и выше, 2 кадра/сек будет достаточно для начала.Android, Захват экрана

Я пытаюсь использовать ADB «видеобуфер:» команду, чтобы захватить экран устройства снимки

Протокола USB связи АБР сообщение ориентированного (не потоковые), таким образом, чтобы получить порцию данных набора для чтения (A_WRTE @ 4096bytes)/подтверждение (A_OKEY @ 24bytes) пары команд принимаются/отправляются.
Пока принимающая сторона не отправила A_OKEY, никакие дополнительные данные не будут выталкиваться устройством (следовательно, это не протокол потоковой передачи).

В целях оптимизации производительности я реализовал протокол USB АБР напрямую, а не с помощью ADB.exe

Изображение 5 устройства Samsung Galaxy имеет разрешение 1920 * 1080 и 32 битовой глубиной, и таким образом, изображение рамочной камеры RAW будет весить 1920 * 1080 * 4 = 8294400 байт (для iPAD оно будет даже больше), используя команду «framebuffer:» по протоколу, ориентированному на сообщение ADB, для получения одного снимка экрана требуется ~ 2 секунды (grrr ..).

Если бы потоковый протокол он должен был ~ 150 мс на USB 2.0 @ 480Mbps

  • Имея выше в виду, есть ли способ, чтобы получить «видеобуфер:» S быстрее?
  • Есть ли способ уменьшить разрешение перед отправкой через USB?
  • Есть ли какой-либо другой подход, общий для всех устройств, сделать скриншоты 24x7 быстрее?
  • Эквивалент AirPlay для Android (ОБЩИЕ для всех устройств) был бы оптимальным?

P.S.
Я уже пробовал проект ASL, он не работает на моем «Samsung Galaxy 5», так как оболочка ADB.exe не работает с системными привилегиями (скорее, она работает под учетной записью «shell»).

+0

adbd работает как «оболочка» на всех распакованных сайтах Android. Но оболочка должна уметь снимать скриншоты - вот как кнопка в DDMS может работать на производственных устройствах. –

+0

Я получаю «Permission denied» для open («/ dev/graphics/fb0», O_RDONLY) под учетной записью оболочки ... – NadavRub

+0

Это не так, как вы должны были запечатлеть экран в течение многих лет - даже если вы может открыть его, он не будет работать на большинстве устройств с графическим процессором. –

ответ

2

На Android 4.3 и более поздних версиях вы можете делать то, что делает screenrecord, и подавать зеркальный виртуальный дисплей в видеокодер. Version 1.2, который поставляется с 5.0 "Lollipop", имеет встроенную функцию потоковой передачи через USB, включая код termio для отправки двоичных данных через adb shell. Используйте «скрытый» аргумент --output-format=h264 и укажите дефис (-) в качестве имени выходного файла.

Исходный код находится в frameworks/av/cmds/screenrecord.

Это единственный способ получить приличную скорость передачи кадров по USB. Вы можете поэкспериментировать с несжатыми данными, указав --output-format=raw-frames, но даже при разрешении VGA вам будет сложно получить кадры с приличной скоростью.

FWIW, текущие устройства обычно не используют фрейм-буфер dev, кроме, быть может, в режиме восстановления. Вместо этого они используют наложения, которые комбинируются аппаратным композитором при отображении экрана. Полная информация находится в architecture doc.

+0

Спасибо за ваш подробный ответ, мне нужно это для работы на 4.3, screenrecord ограничивается сессией записи максимальной продолжительностью 3 минуты, мне нужно это для запуска ~ 24x7, можно ли получить доступ к той же службе, которая используется для хромового зеркалирования через сеанс adb? – NadavRub

+0

Для экрана screenrecord * binary * требуется Android 4.4 и ограничено 3 минутами. Исходный файл screenrecord 1.0 * будет построен (с одним незначительным изменением) на Android 4.3, и вы можете удалить 3-минутный лимит. (Вы также можете бинарно редактировать исполняемый файл, если у вас есть этот набор знаний.) Программа использует внутренние API-интерфейсы, поэтому вы не можете надежно использовать один двоичный код для разных устройств и выпусков, но в 4.3 нет общедоступного API-эквивалента. Я мало что знаю о ChromeCast, поэтому я не могу с этим поговорить. – fadden

+0

Fadden, не является ли исполняемым файлом, подписанным ключом поставщика ОС? разве это не требование подписания для доступа к функциям захвата экрана? Будет ли перекомпиляция источника или исправление бинарного файла на самом деле, имея в виду, что он не подписан с ключом поставщика? – NadavRub

Смежные вопросы