Working on Cover for Android

Our fancy office sign

I’m excited to share about the latest project I’ve been working on, Cover for Android. It’s a lockscreen replacement that learns what apps you use and where you use them, and uses that information to put the right apps at your disposal immediately when you unlock your phone. Modern smartphone usage revolves around rapidly increasing numbers of apps, so easing that process is what we’ve focused on with Cover. With our invitation-only beta we support four features around that theme, and you can see them in our launch video, a more in-depth overview by Todd, or these articles from The Verge and TechCrunch.

There’s been a lot written about what we’re doing with the product, so I won’t rehash that – just watch the videos or check out one of the great articles! Instead I’d like to talk briefly about why I find working on Android interesting from a developer’s perspective.

Contextual computing

ic_settings_outWe carry our phones around with us everywhere, and those phones already generate and collect a large amount of data about who we are and what we do. Even though Android and iOS platforms have unfettered access to this data, in many ways the science-fiction future of computers that understand our wants and needs has felt far away. If you’ll forgive the snowboarding analogy, getting involved in contextual computing at this time in the industry is like having a mountainful of fresh powder to play in. We’ve got the potential in the next few years to map out what’s possible, and there’s no better place to be doing that experimentation than at a startup dedicated to a mobile platform with huge distribution, an extremely flexible developer SDK, and a user community that is hungry for well-designed apps.

Design balance on Android


One of Android’s strengths and weaknesses is the sheer amount of choice present for users. It’s got huge enough distribution that large communities of users dedicated to heavily customizing their phones can seem like the entire market. Those communities are vocal, enthusiastic, and supportive of developers, and much of the traditional aesthetic of Android development has been driven by these groups almost as much as Google’s design guidelines. However, the tradeoffs inherent in too much choice are well-known.

Our challenge is to design an app that simplifies getting to the right apps at the right time in a way that respects the work that long-time Android users have put into customizing their phones already. To that end, Cover is a lockscreen replacement that leaves users’s launchers, homescreens and custom ROMs intact. We’ve definitely got challenges ahead, but what’s been so interesting to discover is the ability to use the less-frequently-explored parts of Android’s API to try and address them in creative ways.

Android’s Deeply Ingrained Flexibility

…the Android team designed their platform to grant flexibility to developers while keeping power in the hands of users.
On that note… before working with it, I certainly didn’t realize the extent to which the Android team designed their platform to grant flexibility to developers while keeping power in the hands of users. Traditional apps really only need a fraction of the feature set available in the Android API – especially if all you’re doing is directly porting apps from iOS. In fact, you won’t realize how much you’ve become accustomed to working with lowest-common-denominator access until you stop worrying about what’s going to run cross-platform and start really digging into the Android SDKs. The Android team planted the seeds to enable developers to push their entire OS in ways they hadn’t imagined, as opposed to just defining a single common sandbox for everyone to play within. As a company, being committed to Android has led us to constantly be surprised and delighted by the kinds of features and functionality we’re can deliver to users because of this fundamentally different philosophy of mobile computing.

Android API stability post-Gingerbread

If you’re aiming to support a very wide range of Android devices on a fast timeline, Gingerbread is a reasonable SDK version to work with as your baseline for feature support. It’s been around a while, and many post-Gingerbread features that weren’t backported in one of Google’s compatibility libraries have been implemented by third-party Android developers in ways that have become industry standards. In my experience, limiting yourself to Gingerbread or ICS-compatible APIs is a workable place to start. When you do that, it makes your life a bit easier than what the Android reputation for fragmentation would have you believe.

See for yourself

The only way to get a good feel for the truth about Android is to go try it out! There’s really too much to describe in a small blog post. You can’t really ask for a nicer IDE to explore Android with than Android Studio (based on IntelliJ IDEA), and its magical intelligence makes working with Java code way easier than I expected. If you start playing with it and get intrigued about the possibilities, let us know! 😉

Othewise, if you’re interested in trying out Cover, please sign up for an invite at