简体繁体 English

Android，屏幕截图

[英]Android, Screen capture

原文 2014-11-06 18:37:43 5 1 android/ android-ndk/ adb

I am building an app that should implement screen ~mirroring~ for any un-rooted device having Android 4 and above, 2 frames / sec will suffice for start. 我正在构建一个应用程序，该应用程序应为具有Android 4及更高版本的任何无根设备实现屏幕“镜像”功能，启动2帧/秒就足够了。

I am trying to use the ADB "framebuffer:" command to grab device screen shots 我正在尝试使用ADB“ framebuffer：”命令来抓取设备屏幕截图

The ADB USB communication protocol is message oriented ( not streaming ), thus, to get a chunk of data a set of read(A_WRTE@4096bytes) / confirm(A_OKEY@24bytes) command pairs are received/sent. ADB USB通信协议是面向消息的（不是流式的），因此，要获取数据块，需要接收/发送一组已读（A_WRTE @ 4096bytes）/确认（A_OKEY @ 24bytes）命令对。
As long as the receiving side didn't send the A_OKEY no additional data will be pushed by the device ( hence, not a streaming protocol ). 只要接收方没有发送A_OKEY，设备就不会推送其他数据（因此，不是流协议）。

In order to optimize performance I have implemented the ADB USB protocol directly rather than using ADB.exe 为了优化性能，我直接实现了ADB USB协议，而不是使用ADB.exe

The image of a Samsung Galaxy 5 device is of a resolution of 1920*1080 and 32 bit-depth, and thus, RAW framebuffer image would weight 1920*1080*4=8294400 bytes ( for iPADs it would even be bigger ), using the "framebuffer:" command over the ADB message oriented protocol it takes ~2 seconds to receive a single screen-shot ( grrr.. ). 三星Galaxy 5设备的图像具有1920 * 1080的分辨率和32位深度，因此，RAW帧缓冲图像的权重为1920 * 1080 * 4 = 8294400字节（对于iPAD，它甚至更大），使用通过面向ADB消息的协议的“ framebuffer：”命令大约需要2秒钟才能收到一个屏幕截图（grrr ..）。

If this would have been a streaming protocol it should have taken ~150 msec on USB 2.0 @ 480Mbps 如果这将是流协议，则在USB 2.0 @ 480Mbps上应该花费约150毫秒

Having the above in mind, is there any way to get the "framebuffer:"s faster? 考虑到以上几点，有什么方法可以使“ framebuffer：”更快吗？
Is there any way to reduce the resolution before sending over USB? 是否可以通过USB发送任何降低分辨率的方法？
Is there any other approach, common to all devices, to take a screenshots, 24x7 in a faster manner ? 是否有其他方法可用于所有设备通用的更快的全天候24x7截图？
An AirPlay equivalent for Android ( COMMON to all devices ) would be optimal ? 相当于Android的AirPlay（ 对所有设备通用 ）是否最佳？

PS PS
I have already tried the ASL project, it doesn't work on my "Samsung Galaxy 5" since ADB.exe shell is not running with system privileges ( rather, it runs under the 'shell' account ). 我已经尝试过ASL项目，因为ADB.exe Shell并未以系统特权运行（而是在“ shell”帐户下运行），所以它在我的“三星Galaxy 5”上不起作用。

1 个解决方案

On Android 4.3 and later you can do what screenrecord does and feed a mirrored virtual display into the video encoder. 在Android 4.3及更高版本上，您可以执行screenrecord操作，并将镜像的虚拟显示输入视频编码器。 Version 1.2 , which ships with 5.0 "Lollipop", has a streaming-over-USB feature built in, including the termio code to send binary data across adb shell . 带有5.0“ Lollipop”的1.2版具有内置的USB流传输功能，其中包括termio代码，可通过adb shell发送二进制数据。 Use the "hidden" argument --output-format=h264 and specify a hyphen ( - ) as the output filename. 使用“ hidden”参数--output-format=h264并指定连字符（ - ）作为输出文件名。

Source code is in frameworks/av/cmds/screenrecord . 源代码在frameworks / av / cmds / screenrecord中。

This is the only way to get decent frame rates over USB. 这是通过USB获得体面帧速率的唯一方法。 You can experiment with uncompressed data by specifying --output-format=raw-frames , but even at VGA resolution you'll have trouble getting frames across at a decent speed. 您可以通过指定--output-format=raw-frames来尝试未压缩的数据，但是即使在VGA分辨率下，也无法以适当的速度获得帧。

FWIW, current devices don't generally use a frame buffer dev, except perhaps in recovery mode. FWIW，当前的设备通常不在恢复模式下使用帧缓冲区dev。 Instead they use overlays that are combined by the hardware composer as the display is scanned out. 取而代之的是，它们使用覆盖层，这些覆盖层是在扫描显示时由硬件编辑器组合而成的。 Full details are in the architecture doc . 完整细节在体系结构文档中。