Set Up Android Accessibility Tests Using Espresso

Espresso Logo
The Espresso documentation has a good simple example of how to set up Accessibility Tests in Android. By including AccessibilityChecks, your tests run a number of rules against the activity/fragment under test to ensure it’s accessibility. The tests fail if all the rules do not pass. The basic gist is that you add a @BeforeClass annotated method which calls AccessibilityChecks.enable():

public static void enableAccessibilityChecks() {

You are supposed to enable this in Espresso 3 by adding the following dependencies to your build.gradle file:

androidTestImplementation ''
androidTestImplementation ''
androidTestImplementation ''

Unfortunately, I have not been able to make it work due to an error in the Espresso library.

Espresso 3.0.1 Broken

The setup described in the Android Documentation results in a run-time error if you include the espresso-accessibility library referenced in the documentation:

Error:Error converting bytecode to dex:
Cause: Multiple dex files define Landroid/support/test/espresso/accessibility/R$attr;

This issue was reported on Stack Overflow, but the one answer did not work for me. In the Google Issue tracker a response implies the problem is fixed in v3.0.2. I was unable to get my hands on that version to test it out.

In order to solve the problem, I had to roll back the Espresso libraries to version 3.0.0 in build.gradle:

Espresso 3.0.0 Broken

Turns out this version of Espresso is also broken, but in a different way. It’s missing a transitive dependency on Guava. To get Espresso 3.0.0 to work, you need to add the missing dependency on Guava into your build.gradle:

androidTestImplementation ''
androidTestImplementation ''
androidTestImplementation ''
androidTestImplementation ''

I published a simple example project demonstrating an Espresso UI test that includes Accessibility checks on Github. The project’s one UI test actually fails, so you can see what the output looks like when an accessibility check fails. There is a comment in activity_main.xml where the accessibility problem lies. The “broken” branch has the project set up for Espresso 3.0.1 so you can see that error. Hopefully Google pushes 3.0.2 soon.

Be Consistent Not Uniform

Android UI is not iPhone UI

A common shortcut often taken is to make one UI work on multiple platforms, and I find myself fighting this misconception often. My thoughts on this were spurred by an article Mobile First, Desktop Worst, which basically takes on mobile first and responsive design as being flawed. I think many of the arguments presented in that article were also relevant to building mobile UIs for an app that exists on both iOS and Android.

UI development is the most time consuming aspect of developing mobile apps. As the app owner you may want your app to be the same on all platforms to try and minimize the work, but this thinking is wrong. Individual users don’t use your app on multiple platforms and expect a common experience, they use your app on their chosen platform and expect it to act like other apps on their chosen platform. An application which does not adopt the UI conventions of the target platform will have diminished success. Users now expect applications to match their platform experience, especially millennials or users who don’t have experience in other platforms.

Each platform has controls, widgets and interaction paradigms that do not exist on other platforms. One UI that works across all platforms will not take advantage of the unique features of each platform, becoming a compromised design that does not meet user’s expectations. The differences in each platform are typically what makes a quality user experience for that platform. The least-common-denominator approach of the sameness across platforms reduces the potential for adoption and success of an app on any given platform. Mobile usability and a fabulous UX are now expected, and your app won’t achieve that goal unless it exploits the platform and device features.

Many of the cross-platform tools make this mistake out of the gate and promise a two-for-one outcome, which is fallacious thinking. Don’t fall into this trap.

Apache HTTP Client in Android API 24+

Google had been telling us for quite some time that the Apache HTTP Client was deprecated and going to be removed, and with the release of Marshmallow (API 24) this came true. For the vast majority of developers, this is a non-issue. The HttpUrlConnection object is more than adequate. But for some enterprise developers, this presented a problem. The HttpUrlConnection does not support NTLM (Microsoft Active Directory) authentication. But the Apache client does. If you are using or want to use the Apache client, it is still possible. Simply add this to the android section of your build.gradle:

android {
    useLibrary 'org.apache.http.legacy'

Now when you build the Apache client becomes available again. It’s still marked as deprecated and Android Studio will complain, but it definitely works.

Resources – Android Authentication in the Web World

I am presenting this talk at the Michigan GDG DevFest on April 22nd. It’s an look at understanding and using existing web technologies for authenticating an Android application to web services, to make for a more secure experience for your Android users.


Github repo



Resources – Apps Users Want to Use


I am presenting this talk at DetroitDevDay on November 12th. It’s a look into some differing views on psychology and app composition and how it affects users of software. As a mobile developer, this kind of work had come to the forefront as the bar for mobile apps continues to rise.




Adding Keyboard Navigation to a RecyclerView

List showing selected tab only

I’ve created a list of items using a RecyclerView which works fine (see the screenshot). But, in order to keep my app accessible, I need to support keyboard-based navigation. Just using the normal Recyclerview pattern and the associated layout was not good enough. If I use a keyboard, I am unable to move the focus down into the list, the focus stops in the tab control and then cycles back up to the app bar. Tapping the items with your finger works fine, and even switch access moves the focus properly to the list items. But it doesn’t work for the keyboard.

The trick is to set the LinearLayout to focusable and clickable, and set the background of the LinearLayout to:


as shown below in the XML layout snippet below. These three changes allow the list items to be selectable by the keyboard.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android=""



What should I build?

Crystal Clear app ktip

I’ve been asked by developers who are learning this exact question. They want to build something to practice their skills or learn a new language or platform, but they don’t have ideas. Luckily, there are solutions for this problem that don’t require the next great idea.

Recreate A Simple App

Look in the App Store or Google Play for a really simple app. A timer, flashcards, a calculator, a pedometer. It doesn’t matter. Make one of your own, use the one you found as a set of requirements. You don’t need to publish the app, you just need to have something to build. If you can publish it, that’s even better but the goal is to practice and get better at coding.

I did a variation this one. Initially, I made a flash card game for my daughter to learn her fact families. The school required here to complete 50 problems in under 2 minutes. I couldn’t find any game at the time that had that feature, so I made one myself. Since that time I’ve re-written that game on two additional platforms (Silverlight and Android) and even ended up publishing it.


Hackathons are events where a bunch of programmers get together and build things. Sometimes it’s for fun, sometimes it’s to help others, like nonprofit organizations or the local government.The ideas typically come from organizations who need help. Sometimes hackathons are competitive and have prizes. They can be in person or online. Usually they take place over time time period, from hours to weeks in duration. You can find a list of hackathons at DevPost. In-person hackathons are great because you can learn from other developers and network with your peers. The online versions are more likely to offer prizes though.

Open Source

You can contribute to an open source project. It’s helpful if it’s a project you are already familiar with. Look at their issues list. There are bound to be bugs reported that need fixing. Fork the code, fix the bug, submit a pull request. Make sure you talk to the project leaders though and understand what they are looking for in pull requests so you head down the right path when you start fixing the bug. This route helps you learn to read code, and get good experience setting up a development environment for someone else’s work.

Exercises for Programmers

This book from the Pragmatic Programmer series provides a set of exercises you can use to build something. Lots of them are small, but there are quite a few that could be a full app. Not original ideas you could probably publish, but still plenty of ideas you could build.

Learning To Have Ideas

Like any other skill, having ideas can be learned and practiced. In the end it’s a numbers game, you need to have lots of bad ideas in order for some good ones to come out. Set aside time and try to come up with ideas, no matter the quality. Write them down. Do it again tomorrow, and again after that. Before long you will start to see better ideas emerging. But you need to keep at it. Doing it once isn’t going to work.