Android 安卓，屏幕截图

我正在构建一个应用程序，该应用程序应能为任何无根设备（具有Android 4及以上版本）实现屏幕~mirroring~，启动时2帧/秒就足够了

我试图使用ADB“framebuffer:”命令抓取设备屏幕截图

ADB USB通信协议是面向消息的（非流式传输），因此，要获得一块数据，需要一组读取（a_WRTE@4096bytes)/确认（A）_OKEY@24bytes)接收/发送命令对。
只要接收端没有发送命令，设备就不会推送额外的数据（因此，不是流协议）

为了优化性能，我直接实现了ADB USB协议，而不是使用ADB.exe

三星Galaxy 5设备的图像分辨率为1920*1080，深度为32位，因此，原始帧缓冲区图像的重量为1920*1080*4=8294400字节（对于iPad，它甚至更大），使用ADB面向消息协议上的“帧缓冲区：”命令，接收单个屏幕快照（grrr..）需要约2秒

如果这是一个流协议，那么在USB 2.0@480Mbps上应该需要约150毫秒

• 考虑到上述情况，有没有办法让“帧缓冲区”更快
• 在通过USB发送之前，有没有办法降低分辨率
• 是否有其他所有设备通用的方法可以更快地全天候拍摄屏幕截图
• Android的AirPlay等价物（所有设备都通用）是最佳选择

p.S.

---

我已经尝试过ASL项目，它在我的“三星Galaxy 5”上不起作用，因为ADB.exe shell没有系统权限运行（而是在“shell”帐户下运行）。

在Android 4.3和更高版本上，你可以做

屏幕记录

所做的事情，并将镜像虚拟显示提供给视频编码器，它与5.0“棒棒糖”一起提供，内置了USB流媒体功能，包括通过adb外壳发送二进制数据的termio代码。使用“隐藏”参数

--output format=h264

，并指定连字符（

-

）作为输出文件名

源代码在中

这是通过USB获得像样帧速率的唯一方法。您可以通过指定

--output format=raw frames

来试验未压缩的数据，但即使在VGA分辨率下，您也很难以合适的速度获得帧

---

FWIW，目前的设备通常不使用帧缓冲区dev，除非可能处于恢复模式。取而代之的是，当显示器被扫描出来时，它们使用由硬件编写器组合的覆盖层。详细信息请参见。

adbd在所有未经检查的Android股票发行版上以“shell”的形式运行。但是shell应该能够捕获屏幕截图-这就是DDMS中的按钮在生产设备上工作的方式。我在shell帐户下获得了open（“/dev/graphics/fb0”，ordonly）的“权限被拒绝”…多年来你一直不应该这样捕获屏幕-即使你可以打开它，它在大多数带有GPU的设备上都不起作用。你一定是在看一些非常古老的东西。ADBD大约从2010年9月开始使用/system/bin/screencap进行捕获：较新版本也内置了压缩屏幕录制。它可能不会带来很大的性能提升，但您可以尝试将分辨率降低到（比如）720p，和/或将图像压缩为jpeg或其他格式。仅通过压缩，您就可以将时间缩短一半或更多，具体取决于执行压缩所需的时间。感谢您的详细回复，我需要在4.3上使用此功能，screenrecord仅限于最长持续时间为3分钟的录制会话，我需要此功能全天候运行，是否可以通过adb会话访问用于chromecast镜像的相同服务？screenrecord二进制文件需要Android 4.4，并且限制为3分钟。screenrecord 1.0源代码将在Android 4.3上构建（只需稍作调整），您可以取消3分钟的限制。（如果你有这方面的知识，你也可以对可执行文件进行二进制编辑。）该程序使用内部API，因此你不能在不同的设备和版本中可靠地使用一个二进制文件，但4.3中没有与之等效的公共API。我对ChromeCast了解不多，所以我不能这么说。Fadden，可执行文件不是由操作系统供应商密钥签名的吗？这不是访问屏幕捕获功能的签名请求吗？重新编译源代码或修补二进制文件是否真的有效？记住它没有使用供应商密钥签名？可执行文件没有签名，也不需要签名。对虚拟显示器的访问由通常的安全机制控制（即，您必须是“shell”或“root”用户），以防止应用程序做邪恶的事情。@darkyen00:它不是内置的，但您可以编写一个筛选器，从screenrecord捕获标准输出并通过TCP连接发送它。