Можно ли читать двоичный файл stdout из команды adb shell? Например, все примеры использования screencap включают в себя два этапа:
adb shell screencap -p /sdcard/foo.png
adb pull /sdcard/foo.png
Однако служба поддерживает запись в stdout. Например, вы можете сделать следующее:
adb shell "screencap -p > /sdcard/foo2.png"
adb pull /sdcard/foo2.png
И это работает одинаково хорошо. Но как насчет чтения результатов через АБР? Я хочу сделать следующее:
adb shell screencap -p > foo3.png
И избегайте промежуточной записи на SD-карту. Это создает что-то похожее на PNG файл (запуск strings foo3.png
генерирует что-то с помощью IHDR, IEND и т.д.) И примерно того же размера, но файл поврежден в отношении читателей изображений.
Я также попытался сделать это, используя ddmlib в java, и результаты те же. Я был бы рад использовать любую необходимую библиотеку. Моя цель - сократить общее время, чтобы получить захват. На моем устройстве, используя решение с двумя командами, для получения изображения требуется около 3 секунд. Использование ddmlib и захват stdout занимает менее 900 мс, но это не сработает!
Можно ли это сделать?
EDIT: Вот шестнадцатеричный файл из двух файлов. Первый, screen.png появился из stdout и был поврежден. Второй, xscreen - из решения с двумя командами и работает. Изображения должны быть визуально идентичными.
$ hexdump -C screen.png | head
00000000 89 50 4e 47 0d 0d 0a 1a 0d 0a 00 00 00 0d 49 48 |.PNG..........IH|
00000010 44 52 00 00 02 d0 00 00 05 00 08 06 00 00 00 6e |DR.............n|
00000020 ce 65 3d 00 00 00 04 73 42 49 54 08 08 08 08 7c |.e=....sBIT....||
00000030 08 64 88 00 00 20 00 49 44 41 54 78 9c ec bd 79 |.d... .IDATx...y|
00000040 9c 1d 55 9d f7 ff 3e 55 75 f7 de b7 74 77 d2 d9 |..U...>Uu...tw..|
00000050 bb b3 27 10 48 42 16 c0 20 01 86 5d 14 04 11 dc |..'.HB.. ..]....|
00000060 78 44 9d c7 d1 d1 11 78 70 7e 23 33 8e 1b 38 33 |xD.....xp~#3..83|
00000070 ea 2c 8c 8e 0d 0a 08 a8 23 2a 0e 10 82 ac c1 40 |.,......#*[email protected]|
00000080 12 02 81 24 64 ef ec 5b ef fb 5d 6b 3b bf 3f ea |...$d..[..]k;.?.|
00000090 de db dd 49 27 e9 ee 74 77 3a e3 79 bf 5e 37 e7 |...I'..tw:.y.^7.|
$ hexdump -C xscreen.png | head
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 02 d0 00 00 05 00 08 06 00 00 00 6e ce 65 |.............n.e|
00000020 3d 00 00 00 04 73 42 49 54 08 08 08 08 7c 08 64 |=....sBIT....|.d|
00000030 88 00 00 20 00 49 44 41 54 78 9c ec 9d 77 98 1c |... .IDATx...w..|
00000040 c5 99 ff 3f d5 dd 93 37 27 69 57 5a e5 55 4e 08 |...?...7'iWZ.UN.|
00000050 24 a1 00 58 18 04 26 08 8c 01 83 31 38 c0 19 9f |$..X..&....18...|
00000060 ef 7c c6 3e 1f 70 f8 7e 67 ee 71 e2 b0 ef ce f6 |.|.>.p.~g.q.....|
00000070 f9 ec 73 04 1b 1c 31 60 23 84 30 22 88 a0 40 10 |..s...1`#.0"[email protected]|
00000080 08 65 69 95 d3 4a 9b c3 c4 4e f5 fb a3 67 66 77 |.ei..J...N...gfw|
00000090 a5 95 b4 bb da a4 73 7d 9e 67 55 f3 ed 50 5d dd |......s}.gU..P].|
Просто на быстрый взгляд кажется, что добавлено еще несколько дополнительных 0x0d (13) байтов. Возврат каретки?? Это звонит какие-то колокольчики? Смешивается ли он в несколько пустых строк?