Want to capture screenshot of current screen from phone

1266 views
Skip to first unread message

Bharathiraja R

unread,
Jun 2, 2011, 5:27:15 AM6/2/11
to Android Developers
Hi All,

Want sample code to capture screenshot of current screen from phone,
same like ddms (screen capture).
Please help me out.

Regards,
Bharathiraja R

Paul Turchenko

unread,
Jun 2, 2011, 3:11:48 PM6/2/11
to Android Developers
Your process will need permission to do that. ADB has it by default,
but regular apps don't. Unless you're rooted, you can't do that.

On Jun 2, 4:27 am, Bharathiraja R <bharathiraja.andr...@gmail.com>
wrote:

New Developer

unread,
Jun 2, 2011, 3:35:33 PM6/2/11
to Android Developers
I'm trying to do something similar

Inside my button's OnClick I have

View myView = arg0.getRootView();
myView.setDrawingCacheEnabled( true );
mPDF.addImage( myView.getDrawingCache() );

I'm hoping this will capture the screen to a bitmap

my PDF.addImage is as follows:

public void addImage(Bitmap bmp) {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
bmp.compress(CompressFormat.JPEG, 100 , bos);

mImage += "5 0 obj \n" +
"<< /Type /XObject\n" +
" /Subtype /Image\n" +
" /Width " + bmp.getWidth() + " \n" +
" /Height " + bmp.getHeight() + " \n" +
" /ColorSpace /DeviceRGB\n" +
" /BitsPerComponent 8\n" +
" /Length " + bos.size() + "\n" +
" /Filter /ASCIIHexDecode\n" +
">>\n\n" +
"stream\n";

mImage += bos.toString() + "\n";

mImage += "endstream\n" +
"endobj\n\n";
}


1) Is the onClick the correct way to capture the screen to bitmap ?
2) Is the PDF code the correct way to store an image inside a PDF ?

thanks in advance

New Developer

unread,
Jun 2, 2011, 4:09:33 PM6/2/11
to Android Developers
Okay I output my bitmap to file as PNG and it only shows the visible
portion of the layout
What is currently seen on the screen not the entire layout.
So would I change the onClick Code to capture the entire layout ?

thanks in advance

Bharathi raja

unread,
Jun 3, 2011, 8:11:03 AM6/3/11
to android-d...@googlegroups.com
Hi,
Thanks for sharing code.

Code u shared will capture the entire screen, even if it is not widget component.
[mean screen may have android or flash or web component]
i wanted to capture all the three.

Regards,
Bharathiraja R

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

New Developer

unread,
Jun 3, 2011, 8:30:10 AM6/3/11
to android-d...@googlegroups.com
Well after much trial and error I managed to capture the entire  layout  or activity
using the following code

View   myView = findViewById(R.id.form);
Bitmap bmp    = Bitmap.createBitmap( myView.getMeasuredWidth() , myView.getMeasuredHeight() , Config.ARGB_8888);
Canvas canvas = new Canvas(bmp);
myView.draw(canvas);
try {
   FileOutputStream out = new FileOutputStream( "/sdcard/screen.jpg"  );
   bmp.compress(Bitmap.CompressFormat.JPEG, 100, out);
   out.flush();
   out.close();
} catch (Exception e) {
   e.printStackTrace();
}

Not sure if this will help or not ?  NOTE: that you can also save as a PNG if you want .

Bharathi raja

unread,
Jun 7, 2011, 10:56:28 AM6/7/11
to android-d...@googlegroups.com
Hi,
thanks for ur sample code.
As i said, they are some application screens made up of graphics component.
For eg. Gallery3D application, all the component there in screen are graphics component. (those component can't see through hierarchy viewer tools)
Can't test it through robotium.
Only way to test the applicaiton is clickOnScreen() with x,y co-ordinate
and for every action need to capture the screen and finally verify it with the captured image.

below code will capture only android component(i.e widget component)

harsh chandel

unread,
Jun 8, 2011, 1:17:07 AM6/8/11
to Android Developers
go to ddms select device on top you have options for getting the
screen capture for device
click on capture then save it wherever you want

On Jun 7, 7:56 pm, Bharathi raja <bharathiraja.andr...@gmail.com>
wrote:
> Hi,
> thanks for ur sample code.
> As i said, they are some application screens made up of graphics component.
> For eg. Gallery3D application, all the component there in screen are
> graphics component. (those component can't see through hierarchy viewer
> tools)
> Can't test it through robotium.
> Only way to test the applicaiton is clickOnScreen() with x,y co-ordinate
> and for every action need to capture the screen and finally verify it with
> the captured image.
>
> below code will capture only android component(i.e widget component)
>

Bharathi raja

unread,
Jun 8, 2011, 6:57:38 AM6/8/11
to android-d...@googlegroups.com
Same thing i wanted to do it on phone without connecting to pc.

Mark Murphy

unread,
Jun 8, 2011, 7:11:50 AM6/8/11
to android-d...@googlegroups.com
On Wed, Jun 8, 2011 at 6:57 AM, Bharathi raja
<bharathira...@gmail.com> wrote:
> Same thing i wanted to do it on phone without connecting to pc.

What you want is impossible, for security reasons.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

Android 3.0 Programming Books: http://commonsware.com/books

Adam Ratana

unread,
Jun 8, 2011, 2:07:27 PM6/8/11
to android-d...@googlegroups.com
I just checked this approach out as a user had emailed me asking about screenshot capability.  This definitely does the trick, but a another poster pointed out, any output from certain components (in my case the camera preview surfaceview) does not show up.
Perhaps the correct approach then is to capture the output of the surface views as bitmaps, and then draw on top of them, it's not quite an "instant" screenshot, but will probably serve the purpose?  I'll experiment with this and if I have good results will post back.

Mark Murphy, you said this is impossible, did you mean in the sense of the way DDMS grabs the full-monty screenshot?

I do hope that Android Handset/Tablet manufacturers catch on and implement hardware screen capturing options, a la iOS -- I don't believe screenshots are programmatically possible there either, for the same reasons, but the user can capture one at any time with a combination of hardware buttons.  It will prevent us from having to come up with adhoc solutions like this, and allow the screenshot process to be user driven, and thus alleviating security concerns.  I believe I read that either Samsung or Motorola may do this in future handsets?

> > On Jun 2, 4:27 am, Bharathiraja R <bharathira...@gmail.com>

> > wrote:
>
> > > Hi All,
>
> > > Want sample code to capture screenshot of current screen from phone,
> > > same like ddms (screen capture).
> > > Please help me out.
>
> > > Regards,
> > > Bharathiraja R

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Mark Murphy

unread,
Jun 8, 2011, 2:11:19 PM6/8/11
to android-d...@googlegroups.com
On Wed, Jun 8, 2011 at 2:07 PM, Adam Ratana <adam....@gmail.com> wrote:
> Mark Murphy, you said this is impossible, did you mean in the sense of the
> way DDMS grabs the full-monty screenshot?

Um, for some definition of "full-monty", I presume, yes. :-)

> I do hope that Android Handset/Tablet manufacturers catch on and implement
> hardware screen capturing options, a la iOS -- I don't believe screenshots
> are programmatically possible there either, for the same reasons, but the
> user can capture one at any time with a combination of hardware buttons.  It
> will prevent us from having to come up with adhoc solutions like this, and
> allow the screenshot process to be user driven, and thus alleviating
> security concerns.  I believe I read that either Samsung or Motorola may do
> this in future handsets?

I haven't heard anything about that.

Adam Ratana

unread,
Jun 8, 2011, 8:57:29 PM6/8/11
to android-d...@googlegroups.com

Reporting back, as far as specifically capturing camera preview output to a bitmap and following the prior examples to draw, this is definitely possible.  There's some interesting things going on that may be helpful for others:

1. Camera preview size varies, some phones (such as the Samsung Galaxy S) support full-screen preview sizes.
2. Full screen preview sizes are not in the same aspect ratio as the camera image itself (on the galaxy s, it's 4:3, pretty standard for consumer digi-cams)
3. The full screen preview appears to be non-distorted, in that, it appears to be a slightly zoomed and cropped subset of the actual image buffer.  Taking a picture from the same preview reveals that more of the scene is captured.  This is important to note for those whom approximate knowledge of field of view is important.
4. Getting the main view which contains all views and simply drawing that to a bitmap does not work, because the camera surfaceview comes out blank.  So, we get a handle on the main containing view, which will indicate the final image size.  Get a handle on everything but the camera preview.  This might be a layout directly after the camera preview in a relativelayout which wraps everything else.  Create a bitmap from the camera view, downscale it (and possibly more as below), place it onto a bitmap the size of the containing view, then draw to that bitmap from the handle on everything but the camera preview.

Looks like there's 2 options as far as "screenshotting" a screen with a camera preview and other items on top (for example, an augmented reality scenario with simple non-openGL canvas drawing on top, some buttons etc)

a. Use Camera.takePicture() and Camera.PictureCallback.onPictureTaken().  With the resulting image, scale it down, but to match the exact preview image, it must be zoomed and cropped accordingly, not sure if the crop position varies by device.  Copy the pixels into a bitmap the size of the containing view. 

b. Implement Camera.PreviewCallback and onPreviewFrame().  This seems the most raw method to use, and caution must be taken.  For 2.2+ (and 2.1 using reflection) it looks like there's some other ways to do this more efficiently - http://code.google.com/p/android/issues/detail?id=2794 

I may try option B and profile it to see if it's worth it.  Option A seems to work pretty well other than the scaling ickyness, and not knowing what's going to happen on other phones.

Don't know if this is any more helpful to anyone, it's basically integrating a few things from around, but this seems to work okay for Camera previews at least.

albnok

unread,
Jun 12, 2011, 8:49:52 AM6/12/11
to Android Developers
The Samsung Galaxy Tab 7" does support screenshots, albeit unelegantly
- while holding down Back, press Power. You may have to go into
another activity first before pressing Back and hitting Power at the
same time LOL.

rich friedel

unread,
Jun 12, 2011, 3:10:10 PM6/12/11
to android-d...@googlegroups.com
What security implications arise from allowing the device to take screenshots? I see that line of reasoning toss about a lot to describe why something doesn't work automatically.

I don't understand why this couldn't be something that is normally available... all it would require is a simple permission.

Mark Murphy

unread,
Jun 12, 2011, 3:58:44 PM6/12/11
to android-d...@googlegroups.com
On Sun, Jun 12, 2011 at 3:10 PM, rich friedel <rich.f...@gmail.com> wrote:
> What security implications arise from allowing the device to take screenshots?

Allowing the user to take screenshots would not be a problem, in isolation.

Allowing an SDK application to take screenshots of itself presumably
would not be a problem, though I'm not sure how useful this is. After
all, you can already get most of it -- only things outside your
activity (e.g., status bar/system bar) aren't available.

Allowing an SDK application to take screenshots *of other
applications* is a big security problem. If you don't believe me, then
you won't have a problem posting your bank account details in a reply
to this list, the way malware could by taking a screenshot of your
device while you are in your banking app.

I suspect that part of the reason why user-level screenshot capability
is not in the OS is to make damn sure that there's no way via
reflection or other games that somebody could programmatically invoke
it. That's just a guess, though.

> I see that line of reasoning toss about a lot to describe why something doesn't work automatically.

Often times, that line of reasoning is tossed about due to legitimate
security concerns. You are certainly welcome to disagree with those
concerns, of course.

> I don't understand why this couldn't be something that is normally available... all it would require is a simple permission.

Similarly, you are welcome to your opinion regarding the efficacy of
the permission system for preventing users from malware.

Android Training in NYC: http://marakana.com/training/android/

rich friedel

unread,
Jun 12, 2011, 11:12:41 PM6/12/11
to android-d...@googlegroups.com
I agree that an app taking a screenshot of extremely private information is a high security risk. However, how is that any different than allowing an application access to my contacts, browser, phone state, etc... As an example take LauncherPro, because it is a complete launcher it requires nearly every permission available. I can only trust that the dev isn't stealing all my information.
Often times, that line of reasoning is tossed about due to legitimate
security concerns. You are certainly welcome to disagree with those
concerns, of course.
I am real big on security. I have to say though that for the screenshot issue, I don't see how it is any different than any other app that has access to my personal information. Like I said make it a requirement to add the permission. Just like any other app, it is up to the user to discriminate against any potential nefarious app by reading those permissions.

Similarly, you are welcome to your opinion regarding the efficacy of
the permission system for preventing users from malware.
Again, there are many many apps that require worse permissions than a screenshot.

Finally, if it was truly as high a risk as is said, I would assume (not guarantee though) that with all the rooted devices, various mods and screenshot apps that are out there and running that anything bad would have surely at least peeked its ugly head by now.

Dianne Hackborn

unread,
Jun 13, 2011, 12:48:38 AM6/13/11
to android-d...@googlegroups.com
On Sun, Jun 12, 2011 at 12:58 PM, Mark Murphy <mmu...@commonsware.com> wrote:
I suspect that part of the reason why user-level screenshot capability
is not in the OS is to make damn sure that there's no way via
reflection or other games that somebody could programmatically invoke
it. That's just a guess, though.

Mostly it is because it is not as easy as people think.  There is no consistent way across the various hardware to get the current contents of the screen -- on some hardware you can't even get to the frame buffer to read back, or reading back the frame buffer may not give you a consistent snapshot.

In Android 3.0 there is a way to have the surface flinger re-render the screen to an off-screen bitmap to transfer out through a shared memory area that is used for the running tasks previews.  This facility will be used at some point to allow the user to take screenshots (and is the way ddms now takes screen shots), though no UI has been build for that yet.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Dianne Hackborn

unread,
Jun 13, 2011, 12:59:17 AM6/13/11
to android-d...@googlegroups.com
You are significantly under-stating what you can do with the ability to take a screenshot at any time.  This basically lets you see whatever the user is doing.  For example it would be quite feasible to wait until you determine the user is needing to enter their password and start taking screenshots at that point to determine what they enter.

You will notice there is no permission for "get the user's password."  Nor in fact one for "get the user's bank account" etc.

Also just throwing some feature behind a permission is not a magical solution.  We actually rely on permissions too much, and are trying to reduce that through other security techniques.  And for the cases where we do use permissions, the less clear a permission is about what it actually implies then the less useful it is.  From that perspective, "read your contacts" is *far* more useful as a permission than "take screenshots (oh btw this means the app could get any data you display on the screen and figure out things like your password)."

Put another way -- many more users upon being confronted with "this app can read your contacts" will understand what that means and be able to make a good judgement about whether they think this is okay with them, than they will be able to evaluate a "take screenshots" permission.

If/when we do have an API for an application to take a screenshot, this will probably be something along the lines of making a request for the screenshot, resulting in the system taking the screenshot and showing it to the user for them to confirm they want it given to the app before it is actually returned.

Finally, as far as a launcher app needing "nearly every permission" -- the platform's standard launcher needs: call phone, read contacts, set wallpaper, vibrate, write settings.  If you are finding a launcher app that needs a wall full of permissions, I would suggest re-considering whether you actually want to install that app.  They are definitely not necessary.  (And honestly, we really should fix things so the lancher doesn't need call phone or read contacts either.)

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

rich friedel

unread,
Jun 13, 2011, 4:26:46 AM6/13/11
to android-d...@googlegroups.com
I am only throwing the permissions thing out there as it was the easiest to illustrate my point. I fully understand the implications of an app having the ability to take a screenshot. However, sometime this is a reasonable need by a user. What I was trying to say is that there must be a better way than to just say: It's a security risk therefore it is not feasible.

And you address that here:
If/when we do have an API for an application to take a screenshot, this will probably be something along the lines of making a request for the screenshot, resulting in the system taking the screenshot and showing it to the user for them to confirm they want it given to the app before it is actually returned.
That, to me, would be a perfectly acceptable solution where you would make it so there is no other option but to show what image the app just grabbed and it would be managed by the system.

As far as permissions go and their vagueness making them useless... well that is a whole other debate. 

Mark Murphy

unread,
Jun 13, 2011, 6:49:03 AM6/13/11
to android-d...@googlegroups.com
On Mon, Jun 13, 2011 at 4:26 AM, rich friedel <rich.f...@gmail.com> wrote:
> And you address that here:
>
> If/when we do have an API for an application to take a screenshot, this will
> probably be something along the lines of making a request for the
> screenshot, resulting in the system taking the screenshot and showing it to
> the user for them to confirm they want it given to the app before it is
> actually returned.
>
> That, to me, would be a perfectly acceptable solution where you would make
> it so there is no other option but to show what image the app just grabbed
> and it would be managed by the system.

Agreed.

When I cite "not possible for security reasons", I'm referring to the
present day, not a statement for all time. I will try to work
"presently" into my statements in the future.

Warescription: Three Android Books, Plus Updates, One Low Price!

Reply all
Reply to author
Forward
0 new messages