如何在没有root权限的情况下以编程方式对其他应用程序进行截图，比如截图UX试用？

Question

如何在没有root权限的情况下以编程方式对其他应用程序进行截图，比如截图UX试用？

>

我知道我可以在我的应用程序中捕获根视图的位图。但是当我的应用程序在后台运行时，我无法获得其他应用程序的根视图

bitmap=bitmap.createBitmap（rootview.getdrawingcache（））；

清单中有一个捕获当前帧缓冲区的权限:Android.permission.read_frame_buffer。但是一些网站说它只适用于签名应用程序。

检查Android权限-保护级别

在尝试截图UX试用后，我阅读了权限：

• Internet：用于连接到本地主机屏幕截图服务器，用于根电话。
• system_alert_window：用于最上面的相机按钮。
• 振动：用于振动反馈。
• write_external_storage:保存截图。
• get_tasks:用于检测非根和非预加载捕获方法的前台开发设置活动。

似乎system_alert_window或get_tasks允许应用程序截图。我对它的工作原理有两个猜测：

1. 它可能能够访问前台活动的活动，它获取活动的根视图，捕获其截图。
2. 调用GlreadPixels

如果你尝试我的一个猜测，请让我知道结果。

Answer 1

这是极其困难的。我花了好几年的时间想做这件事。我最终成功了，但任何解决方案都将涉及商业和技术努力。

下面的大部分内容不再是最新的。经过这么多年，现在有了一个android.media.projection包https://developer.android.com/reference/android/media/projection/package-summary.html，它终于可以满足您的需要了！

为了完整起见，我希望包含您自己的注释，即您可以使用bitmap.createbitmap（rootview.getdrawingcache（））；和类似的机制捕获您自己的应用程序的映像。

我觉得这有点可悲，所以早在2009年，我就提交了一个Android开源项目，要求开放它1。Android架构师黛安娜·哈克伯恩的回应是：

嗯，没有。绝对不是。

所以，那很顺利！因此，该权限至今仍是签名级别。

但是，如果您有此权限，您可以调用ISurfaceComposer2的CapturesCreen成员。您需要编写一些本地代码来访问这个函数，使用Android NDK和一些未记录的API。然而，这是可能的。

在Android graphics子系统内部，它使用GlreadPixels调用将像素从GPU检索回CPU。（GPU用于Android上的大部分合成。事实上，Android4.0+支持额外的硬件合成程序，而Surface Flinger需要做更多的工作才能将这些像素拉回CPU。）

这个调用运行得很好，除了几个小问题：

• 使用不受支持的API的风险，该API随时可能崩溃；
• 在C++中调用它的麻烦
• 它会导致GPU流水线停顿，这可能会让GPU设计者感到不安，但实际上并不会造成问题
• 它依赖于从GPU返回CPU的大带宽。这有时会有问题，因为内存体系结构被设计成以相反的方向发送数据。然而，我似乎记得所有现代Android芯片组架构都直接在GPU和CPU之间共享内存，除了一个（可能是Broadcom？--我不记得了），这可能会导致该机制非常慢。

...还有一个大问题...

• 最重要的是，作为一个普通的应用程序编写器，由于所需的签名级权限，您甚至不能调用此API。

有些人试图读取这些表示framebuffer的Linux设备文件。但是，存在三个问题：

• 您需要root。
• 有时他们甚至不在那里。
• 通常，它们并不代表真实的屏幕图像。请记住，在Android上，图形是在GPU上合成的。因此，CPU没有理由可以访问完整合成的屏幕图像的副本，而且通常不会。这个文件有时包含撕裂（最好的情况下）和垃圾图像（最坏的情况下）。有趣的是，一些有根电话的工具确实使用了这种方法，我认为这是一个错误。如果您有root，那么根据定义，您拥有所有Android权限，因此可以调用上面的capturescreenAPI来获得正确的图像。

现在我们进入需要商业行动的解决方案。

与Android芯片组制造商交谈通常会给出一个解决方案。因为他们设计了硬件，所以他们可以访问framebuffer，而且他们通常能够提供完全避免Android权限模型的库，只需直接访问他们的自定义内核驱动程序。

如果你的目标是一个特定的手机型号，这往往是一个很好的方式前进。当然，很可能你需要和手机制造商以及硅制造商合作。

有时这可以提供出色的结果。例如，我听说在某些硬件上可以将手机硬件framebuffer直接管道到手机硬件H.264视频编码器中，并检索手机屏幕上的任何预先编码的视频流。杰出。（不幸的是，我只知道这在TI OMAP芯片上是可能的，这些芯片正逐渐退出手机市场3）。

Android严格执行其权限模型，并且几乎没有安全漏洞。然而，Android原始设备制造商有时会更加粗心。

例如，一个名字以S开头的主要OEM已经实现了一种使用击键捕获屏幕的方法。它将其保存到SD卡上的一个世界可读的文件中。假设您可能能够找到拦截这些密钥的东西，并了解它是如何工作的。也许你可以做类似的事情。

也许还有另一个名字也以S开头的主要OEM公司的方法。

不，我不打算在这部分做更多的细节。为了弄清楚如何做这些事情，我需要有反向工程软件，而这可能是非法的。不过祝你好运。

如前所述，手机制造商可以随时访问一个有效的API。并且电话制造商具有所需的签名级权限。

所以，你所需要做的就是安排让手机制造商签署你的软件。

然而，这很难。通过签署软件，手机制造商保证了它的质量--所以他们应该想审核你的源代码。此外，由于Android的性质--如果他们签署了软件，他们需要是分发软件的人。如果是别人的签名，你就不能把它放在市场上。

然而，OEM不需要在ROM中包含它--他们仍然可以在Android市场上分发它。但你不能。

一个好的解决方案是，每个供应商签署一个小型库，然后可以通过公共SDK访问该库。这让我想到...

我对此了解很多，因为我曾经在RealVNC工作过。我们与所有主要的Android手机供应商合作，以获得这些签名级API。我怎么强调都不为过，为了实现这一目标，需要付出许多、许多人多年的努力（商业和技术上）。一些原始设备制造商已经公布了这项工作-例如4。

我不再在RealVNC工作了，所以我没有从他们的软件广告中获得任何好处。但是如果你真的真的想在多个Android设备上捕捉屏幕，你可能希望与他们联系，重新使用他们的远程控制服务或Android VNC SDK5。它不是开源的，所以你应该付费，相信我，考虑到与所有这些Android OEM合作的史诗般的努力，这是足够公平的。

为了平衡起见，我应该指出，其他供应商也在这方面与手机制造商合作--例如SOTI。但我相信它们都提供特定的设备管理解决方案，而不是一般的远程控制/事件注入SDK。

另一个选项--adb守护进程监听通过USB调试连接的权限比普通应用程序略多，这就是为什么它能够抓取屏幕（您可以使用ddms工具查看它的图像）。如果您能够使用adb运行任何命令，那么您也可以获得这些特权（根据前面链接的android-screenshot-library）。

最终，这个问题让我灰飞烟灭，我离开了更绿色的牧场，不需要试图从Android手机中挤出像素。

然而，在我离开RealVNC之前，我们再次尝试将这些API贡献给Android开源项目。这次我们得到了一个更积极的反应。简而言之，有人认为我们的安全方法几乎是正确的，但图形系统太混乱了，无法接受我们的补丁。好吧，好消息是图形系统不再混乱--事实上，它现在有了capturescreenAPI，这意味着不需要任何图形系统更改。因此，可以围绕这个API向AOSP提交一个新的安全机制，最终解决了这个问题。

祝你好运！