如何利用其他应用程序的截图编程没有root权限，如截图UX试用？ [英] How to take a screenshot of other app programmatically without root permission, like Screenshot UX Trial?

问题描述

如何利用其他应用程序的截图编程没有root权限，如截图UX审判？

How to take a screenshot of other app programmatically without root permission, like Screenshot UX Trial?

1. 我知道我能捕捉到根视图的位图在我的应用程序。但是，当我的应用程序在后台运行，我不能让其他应用程序的根视图

1. I know I can capture the bitmap of the root view in my app. But I can't get the root view of the other app when my app is running in background

位= Bitmap.createBitmap（rootview.getDrawingCache（））;

有一个允许捕获当前帧缓冲区的清单： android.permission.READ_FRAME_BUFFER 。但是，一些网站说，这是仅用于签名的应用程序。

There is a permission for capturing current frame buffer in Manifest: android.permission.READ_FRAME_BUFFER. But some website says it's for signature app only.

检查Android权限 - 保护级别

在试图截图UX试用，我读的权限：

After trying Screenshot UX Trial, I read the permission:

• 互联网：用于连接到本地主机截图服务器根电话
• SYSTEM_ALERT_WINDOW：为最顶层的拍照键
• 振动：对于震动反馈
• WRITE_EXTERNAL_STORAG​​E：保存截图
• GET_TASKS：用于检测非植根和放前台DEVELOMENT制定活动;非preloaded捕获方法

看来无论是 SYSTEM_ALERT_WINDOW 或 GET_TASKS 允许应用采取截图。 我有两个猜测它是如何工作的：

It seems either SYSTEM_ALERT_WINDOW or GET_TASKS allow the app to take screenshot. I have two guess of how it works:

1. 这可能是能够访问活动前台活动的，它得到了活动的根视图 ，捕捉到它的屏幕截图。
2. 电话 glreadpixels

1. It may be able to access the Activity of the foreground activity, it gets the root view of the Activity, capture its screenshot.
2. Calling glreadpixels

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

If you try one of my guess, please let me know the result.

推荐答案

这是非常困难的。我花了几年时间试图做到这一点。我终于成功了，但任何解决方案都会涉及商业和技术的努力。

This is extremely difficult. I spent several years trying to do it. I eventually succeeded, but any solution will involve commercial as well as technical effort.

下面的大多数东西不再是先进的，最新的。现在有，毕竟这些年来，一个 android.media.projection 包 <一href="https://developer.android.com/reference/android/media/projection/package-summary.html">https://developer.android.com/reference/android/media/projection/package-summary.html 并最终使你所需要的！

Most of the stuff below is no longer up-to-date. There's now, after all these years, an android.media.projection package https://developer.android.com/reference/android/media/projection/package-summary.html which finally allows what you need!

有关完整，我想包括你自己的评论，你可以捕捉到你自己的应用程序中使用 Bitmap.createBitmap（rootview.getDrawingCache（））的图像; 和类似机制。

For completeness, I want to include your own comment that you can capture an image of your own application using Bitmap.createBitmap(rootview.getDrawingCache()); and similar mechanisms.

首先，你说的没错，一个正常的应用程序不能利用 READ_FRAMEBUFFER 许可的，因为它的签名级。这意味着你必须用相同的密钥作为Android系统的ROM，以便能够采取这样的截图进行签名。

Firstly, you're right that a normal application can't make use of the READ_FRAMEBUFFER permission, because it's "signature"-level. That means you must be signed by the same key as the Android system ROM in order to be able to take such a screenshot.

我认为这是一个有点难过，所以早在2009年我做了一个Android开放源代码项目提交要求将它打开了的 1 。从戴安娜Hackborn的响应，Android的建筑师是：

I thought this was a bit sad, so back in 2009 I made an Android open-source project submission to ask that it be opened up1. The response from Dianne Hackborn, the Android architect was:

嗯，没有。绝对肯定不行。

Um, no. Absolutely positively not.

所以，说顺利的话！因此，该权限仍签名 -level到今天。

So, that went well, then! Hence this permission is still signature-level to this day.

如果您有此权限，但是，你可以调用 ISurfaceComposer 的 captureScreen 成员= http://androidxref.com/4.1.1/xref/frameworks/native/include/gui/ISurfaceComposer.h#123">2 。你需要编写一些本地code访问此功能，使用Android NDK，也有一些无证的API。然而，这是可能的。

If you had this permission, however, you could call the captureScreen member of ISurfaceComposer2. You'd need to write some native code to access this function, using the Android NDK and also some undocumented APIs. However, it's possible.

在内部范围内Android的图形子系统，使用了一种 glReadPixels 呼叫从GPU检索像素，给CPU。 （该GPU可用于大多数在Android上合成的。事实上安卓4.0+支持额外的硬件合成器，表面护圈需要做更多的工作来拉那些像素回CPU。）

Internally within the Android graphics subsystem, this uses a glReadPixels call to retrieve the pixels from the GPU back to the CPU. (The GPU is used for most of the compositing on Android. In fact Android 4.0+ supports extra hardware compositors, and the Surface Flinger has to do even more work to pull those pixels back to the CPU.)

此电话工作很漂亮，除了几个小问题：

This call works beautifully, except for a few small problems:

• 在使用不受支持的API，它可以在任何时刻破发的风险;
• 在调用它在C ++麻烦
• 这会导致GPU管线来搪塞，这会破坏GPU的设计，但并没有真正引起现实问题
• 在它依赖于从GPU的回的给CPU一个大的带宽。这有时是有问题的，因为存储器结构被设计成在相反方向上发送的数据。不过，我好像记得，所有现代的Andr​​oid芯片组架构直接共享的GPU和CPU之间的内存，除了一个（也可能是博通 - ？我不记得）的地方，这可能会导致这个机制是非常慢

• The risk of using an unsupported API which might break at any moment;
• The hassle of calling it in C++
• It causes the GPU pipelines to stall, which can upset the GPU designers but doesn't really cause problems in reality
• It relies on a large bandwidth from the GPU back to the CPU. This is sometimes problematic because memory architectures are designed to send data in the opposite direction. However, I seem to recall that all modern Android chipset architectures directly share memory between the GPU and CPU, except for one (it may be Broadcom? - I can't remember) where this may cause this mechanism to be very slow.

...一大问题...

... and one large problem ...

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

不过，在大多数Android设备，你可以每秒10帧出于此。更妙的是，这个API的确支持缩放最终图像的在硬件上的GPU 的，所以如果你很聪明，你可以pre-规模，只是大小，你所需要的图像，像素前连打CPU。所以它可以是非常高的性能。

Still, on most Android devices, you can get 10 frames per second out of this. Better still, this API actually supports scaling the resulting image in hardware on the GPU, so if you're clever you can pre-scale the image to just the size you need, before the pixels even hit the CPU. So it can be extremely high performance.

请注意，当然，前提是你作为一个应用程序编写者不能调用 glReadPixels ，因为你没有获得相关的OpenGL上下文。它是由表面护圈拥有。

Note, of course, that you as an application writer can't call glReadPixels because you don't have access to the relevant OpenGL context. It's owned by the surface flinger.

有些人很想尝试读取一个重新present帧缓冲，这些Linux的设备文件。但是，存在三个问题：

Some are tempted to try to read these Linux device files which represent the framebuffer. However, there are three problems:

• 您需要root。
• 有时，他们甚至还没有出现。
• 在通常情况下，他们不会再present真正的屏幕图像。请记住在Android上的图形合成在GPU。所以，我们没有理由为什么CPU应该有机会获得全合成画面的副本，它往往并非如此。该文件有时包含撕裂（最好）和垃圾图像（在最坏的情况）。有趣的是，一些为手机根深蒂固的工具确实使用了这个方法，我认为这是一个错误。如果你有根，您可以通过定义有所有的Andr​​oid权限，因此可以拨打以上 captureScreen API来获取正确的图像。

• You need root.
• Sometimes they're not even there.
• Often, they don't represent the real screen image. Remember on Android that the graphics are composited on the GPU. So there's no reason why the CPU should have access to a copy of the full composited screen image, and it often doesn't. This file sometimes contains tearing (at best) and a garbage image (at worst). Interestingly, some of the tools for rooted phones do use this method, which I think is a mistake. If you've got root, you by definition have all Android permissions and can therefore call the above captureScreen API to get a correct image.

现在我们进入这要求商业行为的解决方案。

Now we get into the solutions which require commercial action.

谈起了Android芯片制造商常常presents的解决方案。因为他们设计的硬件，他们有机会获得framebuffer的 - 他们往往能够提供这完全避免了Android权限模型通过简单地直接访问他们的自定义内核驱动程序库

Talking to the Android chipset makers often presents a solution. Since they design the hardware, they have access to the framebuffer - and they often are able to provide libraries which entirely avoid the Android permissions model by simply accessing their custom kernel drivers directly.

如果你的目标在具体的手机型号，这往往是前进的好方法。当然，赔率是你需要与手机制造商，以及硅制造商合作。

If you're aiming at a specific phone model, this is often a good way forward. Of course, the odds are you'll need to cooperate with the phone maker as well as the silicon manufacturer.

有时候，这可能提供的优秀的结果。例如，我听说过有可能在某些硬件管道的手机硬件帧缓冲区直接进入手机硬件的H.264视频连接coder和检索pre-CN codeD的视频流无论是手机屏幕。优秀。 （不幸的是，我只的知道的，这是可能的德州仪器的OMAP芯片，这是逐步从手机市场撤回<一href="http://www.gsmarena.com/texas_instruments_backtracks_from_smartphones_goodbye_omap-news-4861.php">3).

Sometimes this can provide outstanding results. For example I have heard it's possible on some hardware to pipe the phone hardware framebuffer directly into the phone hardware H.264 video encoder, and retrieve a pre-encoded video stream of whatever is on the phone screen. Outstanding. (Unfortunately, I only know this is possible on TI OMAP chips, which are gradually withdrawing from the phone market3).

Android的硬性强制执行其权限模型，并有几个安全漏洞。然而，Android的原始设备制造商有时会比较粗心。

Android rigidly enforces its permission model, and has few security holes. However the Android OEMs can sometimes be more careless.

例如一家大型OEM厂商名称以S的实现方式使用按键来捕捉画面。它保存到SD卡上的世界可读的文件。假设你也许能找到什么截获这些键，看看它是如何工作的。也许你可以做同样的事情。

For example a major OEM whose name begins with S has implemented a way to capture the screen using a keystroke. It saves it to a world-readable file on the SD card. Hypothetically you might be able to find what intercepts those keys and see how it works. Perhaps you could do something similar.

也许有一种方法另一个主要的OEM他的名字也开始使用S。

And perhaps there's a way for another major OEM whose name also begins with S.

没有，我不打算进入这一部分中的任何更多的细节。要解决如何做这些事情，我需要有逆向工程软件，这可能属于违法行为。祝你好运，虽然。

No, I'm not going to go into any more detail on this section. To work out how to do those things, I'd need to have reverse-engineered software, and that might be illegal. Good luck, though.

如前所述previously，手机制造商能够随时获得一个API，它的确实工作的。而手机制造商有签名 -level权限要求。

As described previously, the phone makers have ready access to an API which does work. And the phone makers have the signature-level permissions required.

因此​​，所有你需要做的是安排由手机制造商得到签名的软件。

So, all you need to do is to arrange to get your software signed by the phone maker.

这是，然而，硬盘的。通过签署该软件，手机制造商是保证它的质量 - 所以应该要审核你的源$ C ​​$ C。此外，由于Android的本质 - 如果他们签名软件，他们需要那些分配它。你不能把它的市场，如果它是由其他人的签名。

This is, however, hard. By signing the software, the phone maker is guaranteeing its quality - so they should want to audit your source code. Also, due to the nature of Android - if they sign the software, they need to be the ones distributing it. You can't put it on the Market if it is signed by someone else's signature.

不过，OEM不需要包括它的ROM上 - 他们仍然可以在Android市场上发布。但你不能。

However, the OEM need not include it on the ROM - they can still distribute it on the Android market. But you can't.

一个很好的解决办法是，如果每家供应商签署，然后可以通过一个共同的SDK进行访问的小型图书馆。这使我到...

A good solution would be if each vendor signed a small library which then could be accessed by a common SDK. Which leads me onto...

我知道了很多关于这一点，因为我曾经工作在RealVNC的。我们曾与所有主要的Andr​​oid手机厂商可以访问这些签名级别的API。我不能过分强调了很多很多的人，多年的努力（商业和技术）来实现这一要求。一些OEM厂商已经公布这项工作 - 例如<一个href="http://developer.sonymobile.com/2012/02/29/new-remote-control-service-on-xperia-smartphones-video/">4.

I know a lot about this because I used to work at RealVNC. We worked with all the major Android phone vendors to get access to these signature-level APIs. I cannot overemphasise the many, many man-years of effort (commercially and technically) required to achieve this. Some of the OEMs have publicised this work - for example 4.

我的根本不RealVNC的任何更多的工作的，所以我没有什么广告，从他们的软件来获得。但是，如果你的真的的希望能够捕捉到多个Android设备的屏幕上，您可能希望接近他们关于重新使用他们的远程控制服务或Android VNC SDK的5 。它不是开源的，所以你应该期望支付，请相信我，这是不够公平由于涉及的所有这些的Andr​​oid OEM厂商合作的史诗般的努力。

I do not work at RealVNC any more, so I have nothing to gain from advertising their software. But if you really really want to be able to capture the screen on multiple Android devices, you may wish to approach them about re-using their Remote Control Service or Android VNC SDK 5. It is not open-source so you should expect to pay, and believe me this is fair enough given the epic effort involved in working with all these Android OEMs.

在平衡利益，我要指出的是，其他厂商还和这个手机制造商 - 如：技工机构。但我相信他们都提供特定的设备管理解决方案，而不是一个一般的遥控器/事件注入SDK。

In the interests of balance I should point out that other vendors have also worked with the phone makers on this - e.g. Soti. But I believe they all offer specific device management solutions, rather than a general remote control/event injection SDK.

另一种选择 - 对亚洲开发银行守护进程来监听调试连接了USB有稍微比普通的应用程序的权限，这就是为什么它能够抓取屏幕（可以请参阅使用其形象的 DDMS 工具）。如果你能够运行使用亚洲开发银行那么你也可以得到这些特权（按照Android的截图库连接previously）的任何命令。

Another option - the adb daemon which listens for debugging connections over USB has slightly more privileges than a normal application, which is why it's able to grab the screen (you can see its image using the ddms tool). If you're able to run any command using adb then you too can gain those privileges (as per the android-screenshot-library linked previously).

最后，这个问题降低我灰尘，我离开另谋高就不涉及要挤个像素Android手机。

Eventually this problem reduced me to dust, and I left for greener pastures which didn't involve trying to squeeze pixels out of Android phones.

在我离开的RealVNC虽然，我们再次试图推动这些API到Android开源项目。这一次，我们得到了一个更积极的反应 6 。总之，有人建议，我们的安全的做法几乎是正确的，但是图形系统是太多动荡接受我们的补丁。好了，好消息是，该显卡系统不再处于动荡之中 - 事实上，它现在有一个 captureScreen API，这意味着不需要图形系统更改任何责任。因此有可能提交一个新的安全机制来AOSP解决此API，它终于解决了这个问题。

Before I left RealVNC though, we tried again to contribute these APIs to the Android open-source project. This time we got a more positive reaction6. In short, it was suggested that our security approach was almost right, but that the graphics system was in too much turmoil to accept our patches. Well, the great news is that the graphics system is no longer in turmoil - in fact it now has that captureScreen API which means no graphics system changes are needed whatsoever. It may therefore be possible to submit a new security mechanism to AOSP around this API which finally solves this problem.

祝您好运！

这篇关于如何利用其他应用程序的截图编程没有root权限，如截图UX试用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！