Screenshot UX Trial과 같이 루트 권한없이 프로그래밍 방식으로 다른 앱의 스크린 샷을 찍는 방법은 무엇입니까?

Screenshot UX Trial과 같이 루트 권한없이 프로그래밍 방식으로 다른 앱의 스크린 샷을 찍는 방법은 무엇입니까?

---

Screenshot UX Trial과 같이 루트 권한없이 프로그래밍 방식으로 다른 앱의 스크린 샷을 찍는 방법은 무엇입니까?

1. 내 앱에서 루트 뷰의 비트 맵을 캡처 할 수 있다는 것을 알고 있습니다. 하지만 내 앱이 백그라운드에서 실행 중일 때 다른 앱의 루트보기를 가져올 수 없습니다.

   bitmap = Bitmap.createBitmap(rootview.getDrawingCache());

2. Manifest :에서 현재 프레임 버퍼를 캡처 할 수있는 권한이 있습니다 android.permission.READ_FRAME_BUFFER. 그러나 일부 웹 사이트에서는 서명 앱 전용이라고 말합니다.

   Android 권한 확인-보호 수준

Screenshot UX 평가판을 시도한 후 권한을 읽었습니다.

• 인터넷 : 루팅 된 전화의 localhost 스크린 샷 서버에 연결합니다.
• SYSTEM_ALERT_WINDOW : 최상위 카메라 버튼 용.
• 진동 : 진동 피드백 용.
• WRITE_EXTERNAL_STORAGE : 스크린 샷을 저장합니다.
• GET_TASKS : 루팅되지 않고 미리로드되지 않은 캡처 방법에 대한 포 그라운드 개발 설정 활동을 감지합니다.

SYSTEM_ALERT_WINDOW또는 GET_TASKS앱이 스크린 샷을 찍도록 허용하는 것 같습니다 . 어떻게 작동하는지 두 가지 추측이 있습니다.

1. Activity전경 활동 에 액세스 할 수 있고 ,의 루트보기를 가져 와서 Activity스크린 샷을 캡처 할 수 있습니다.
2. 부름 glreadpixels

내 추측 중 하나를 시도하면 결과를 알려주십시오.

---

이것은 매우 어렵습니다. 나는 그것을하기 위해 몇 년을 보냈다. 결국 성공했지만 모든 솔루션에는 상업적인 노력과 기술적 인 노력이 필요합니다.

---

2015 년 3 월 업데이트

아래 항목의 대부분은 더 이상 최신 상태가 아닙니다. 몇 년이 지난 지금, 마침내 필요한 것을 허용하는 https://developer.android.com/reference/android/media/projection/package-summary.htmlandroid.media.projection 패키지 가 있습니다!

---

자체 애플리케이션의 화면 이미지 캡처

완전성을 위해 Bitmap.createBitmap(rootview.getDrawingCache());및 유사한 메커니즘을 사용하여 자신의 애플리케이션 이미지를 캡처 할 수있는 자신의 의견을 포함하고 싶습니다 .

백그라운드에있는 동안 다른 응용 프로그램의 화면 캡처

사용 READ_FRAMEBUFFER권한을

첫째, 일반 응용 프로그램은 READ_FRAMEBUFFER"서명"수준이기 때문에 권한 을 사용할 수 없다는 것이 맞습니다 . 즉, 이러한 스크린 샷을 찍으려면 Android 시스템 ROM과 동일한 키로 서명해야합니다.

나는 이것이 조금 슬프다 고 생각했기 때문에 2009 년에 안드로이드 오픈 소스 프로젝트를 제출하여 오픈을 요청했습니다 1 . Android 설계자 인 Dianne Hackborn의 답변은 다음과 같습니다.

음 .. 아니야. 절대적으로 긍정적이지 않습니다.

그럼 잘 됐어요! 따라서이 권한은 오늘날까지도 여전히 signature수준입니다.

그러나이 권한이있는 경우 2 의 captureScreen구성원에게 전화 할 수 있습니다. Android NDK 및 일부 문서화되지 않은 API를 사용하여이 함수에 액세스하려면 일부 네이티브 코드를 작성해야합니다. 그러나 가능합니다.ISurfaceComposer

Android 그래픽 하위 시스템 내부에서 이것은 glReadPixelsGPU에서 CPU로 다시 픽셀을 검색 하는 호출을 사용합니다 . (GPU는 Android에서 대부분의 합성에 사용됩니다. 실제로 Android 4.0 이상은 추가 하드웨어 합성기를 지원하며 Surface Flinger는 이러한 픽셀을 CPU로 다시 가져 오기 위해 더 많은 작업을 수행해야합니다.)

이 호출은 몇 가지 작은 문제를 제외하고 아름답게 작동합니다.

• 언제든지 중단 될 수있는 지원되지 않는 API를 사용할 위험이 있습니다.
• C ++로 호출하는 번거 로움
• 이로 인해 GPU 파이프 라인이 중단되어 GPU 설계자가 당황 할 수 있지만 실제로는 문제를 일으키지 않습니다.
• GPU 에서 CPU로 돌아가는 큰 대역폭에 의존합니다 . 메모리 아키텍처는 반대 방향으로 데이터를 전송하도록 설계 되었기 때문에 때때로 문제가됩니다. 그러나 모든 최신 Android 칩셋 아키텍처는이 메커니즘이 매우 느려질 수있는 하나 (Broadcom 일 수 있음)를 제외하고는 GPU와 CPU간에 직접 메모리를 공유한다는 것을 기억하는 것 같습니다.

... 그리고 하나의 큰 문제 ...

• 가장 중요한 것은 일반 애플리케이션 작성자로서 필요한 서명 수준 권한으로 인해이 API를 호출 할 수도 없다는 것입니다.

하지만 대부분의 Android 기기에서는 초당 10 프레임을 얻을 수 있습니다. 더 좋은 점은이 API가 실제로 GPU의 하드웨어에서 결과 이미지 크기 조정을 지원 하므로 영리하다면 픽셀이 CPU에 도달하기 전에 필요한 크기로 이미지 크기를 미리 조정할 수 있습니다. 따라서 매우 높은 성능이 될 수 있습니다.

물론 응용 프로그램 작성자는 glReadPixels관련 OpenGL 컨텍스트에 액세스 할 수 없기 때문에 호출 할 수 없습니다 . 표면 플린 저가 소유하고 있습니다.

사용 /dev/graphics/fb0및 유사

일부는 프레임 버퍼를 나타내는 이러한 Linux 장치 파일을 읽으려고합니다. 그러나 세 가지 문제가 있습니다.

• 루트가 필요합니다.
• 때로는 거기에 있지도 않습니다.
• 종종 실제 화면 이미지를 나타내지 않습니다. Android에서는 그래픽이 GPU에서 합성된다는 점을 기억하십시오. 따라서 CPU가 전체 합성 화면 이미지의 사본에 액세스해야 할 이유가 없으며 종종 그렇지 않습니다. 이 파일에는 때때로 찢어짐 (최상의 경우) 및 가비지 이미지 (최악의 경우)가 포함됩니다. 흥미롭게도 루팅 된 휴대폰 용 도구 중 일부는이 방법을 사용하는데, 이는 실수라고 생각합니다. 루트가있는 경우 정의에 따라 모든 Android 권한이 있으므로 위의 captureScreenAPI를 호출하여 올바른 이미지를 얻을 수 있습니다.

하드웨어 파트너 사용

이제 우리는 상업적 조치가 필요한 솔루션에 들어갑니다.

Android 칩셋 제조업체와 이야기하는 것은 종종 해결책을 제시합니다. 하드웨어를 설계하기 때문에 프레임 버퍼에 액세스 할 수 있으며, 사용자 지정 커널 드라이버에 직접 액세스하여 Android 권한 모델을 완전히 피하는 라이브러리를 제공 할 수 있습니다.

특정 휴대 전화 모델을 목표로하는 경우 이는 종종 좋은 방법입니다. 물론 실리콘 제조업체뿐만 아니라 전화 제조업체와 협력해야 할 가능성이 있습니다.

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).

Using security holes

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

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.

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.

Working with the phone makers

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.

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.

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

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...

Work with software partners who have solved this already

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.

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.

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.

Over USB

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).

Contribute to the Android open-source project

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.

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.

Best of luck!

---

Maybe the android-screenshot-library can help. But well in their Usage page it says that it needs a native service started with adb (from the android sdk).

PS: Remember that Screenshot UX does not work for every unrooted phone.

---

I don't think Android will allow you to access another app's frame buffer. This is just part of the security of Android. Each app should keep to its own resources.

If you really need to get a screen capture of any app, I would suggest using the native screen grab "gesture". For the the Nexus 7 for example, simply "... hold the power button and the volume down button at the same time for approximately 2 seconds."

A Google search will usually find the trick with your device.

ReferenceURL : https://stackoverflow.com/questions/12462944/how-to-take-a-screenshot-of-other-app-programmatically-without-root-permission