Programmatically screenshot from the parent’s View

The first necessary step is to add the appropriate permission to your AndroidManifest.xml.

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

The code, in one lump:

View rootView = childView.getRootView();
Bitmap bitmap = rootView.getDrawingCache();

ByteArrayOutputStream baos = new ByteArrayOutputStream();
bitmap.compress(Bitmap.CompressFormat.JPEG, 80, baos);
File file = new File(Environment.getExternalStoreDirectory() + "/my_cap.jpg");

try {
    FileOutputStream fos = new FileOutputStream(file);
} catch(Exception e) {

Where childView is or inherits from the View class.

Hopefully you can extrapolate from line 6 and the usage of an enum that formats other than JPEG exist and this is merely what I chose for this example code.  Likewise 80 is a value I decided on and is the desired quality of the output image; Only values from 0-100 are accepted.  (Even though png files ignore this value it is still necessary to include one and that its value falls within the 0-100 range)

Verifying Fragments With Espresso

I’ve done some searching to see how I can use Espresso to validate the navigation throughout my app. My typical set-up is one activity encompassing whichever fragments make sense to be managed by that activity (adding additional activities with their own fragments as necessary). In my searching, however, all I was finding were people suggesting I select a View that is displayed within that fragment, and check for its existence.


But that seems a little too fragile to me, layouts can change fairly easily as projects progress and so I figured, since there seems to be no way to actually check that the fragment itself is displayed, just give the master layout an id and look for that instead.  I see less chance for that to change than I do a view within it.

    android:id="@+id/parent_layout" >

        android:layout_centerHorizontal="true" />


It’s such a minuscule alteration but I think, how it’s performed currently, this is less likely to fail throughout an app’s evolution.

And if that hasn’t convinced you here’s a picture — 9000 seconds in Paint.


error: ‘;’ expected

I just had a frustrating configuration hunt. I was creating an Espresso test-file for a new app I’m making, and after writing just the tiniest bit of boilerplate I wanted to verify everything was working properly, ran the Gradle connectedAndroidTest configuration and got the below…

error: type annotations are not supported in -source 1.7
(use -source 8 or higher to enable type annotations)

Continue Reading →