Cover photo
Dianne Hackborn
Works at Google (Android)
Attended Oregon State University
Lives in California
29,759 followers|3,529,720 views


Dianne Hackborn

Shared publicly  - 
For Android developers, I'd like to especially point out this I/O video as one to watch. It covers some of the significant changes we have been making to platform behavior to improve battery life, changes which impact all apps.

We did a lot of the outreach to apps back in Marshmallow when doze was first introduces (since it is a rare case where it impacts all apps, not just ones that target a new platform version); however, with doze light in N, it is even more important that apps follow those recommendations so they continue to work correctly. We had to make the initial doze behavior in Marshmallow fairly conservative to mitigate its impact on existing apps... but now that we've had it out there and worked with developers to update their apps, we can start tightening the screws down. :)

The presentation also gives a preview of some significant behavior changes we plan on making to the platform in a future release, related to broadcast receivers and services. This is I think the largest application model change we have ever made to the platform, so it is well worth taking a look at it now so you can prepare for when it hits. Unlike doze, we plan (at least for now) on this being something that doesn't apply to existing apps, only apps that target the newer platform version. (And many changes you make today to have your app compatible with these future restrictions will also have a positive impact for our users on current devices!)
Ian Lake's profile photoStephen Charman's profile photoDianne Hackborn's profile photoGreg S's profile photo
Greg S
Even in regular light I rarely move the brightness up from the minimum. In direct sunlight of course it needs to be high. But indoor electric lights the screen on every Nexus phone has been more than bright enough the minimum setting.

On the occasions when my screen is mostly off the phone lasts nearly forever. That happens with my spare phone when I'm traveling. It basically ends up being a podcast player and I only have to charge it every 2 or 3 days.

My main phone needs to be charged at least once midday to make it through the day and sometimes twice. And the power consumption reported is always much higher for the screen than the rest of the consumers put together.

The latter part sounds relevant and interesting. Sounds like a worthwhile engineering problem to tackle. 
Add a comment...

Dianne Hackborn

Shared publicly  - 
Also, awesome new version of Strictly Genteel.  I totally missed this had been done.
Alison Chaiken's profile photo
"Watermelon in Easter Hay" is my favorite.
Add a comment...

Dianne Hackborn

Shared publicly  - 
Kickstarter for a Frank Zappa documentary!
Alison Chaiken's profile photoDianne Hackborn's profile photoJac Goudsmit's profile photoKris B's profile photo
Kris B
Q: Name the two actors in Bill and Ted's Excellent Adventure.
A: Keanu Reeves and the other guy.
Add a comment...

Dianne Hackborn

Shared publicly  - 
This is great vanilla, and great people.  If you do any kind of cooking, consider getting something on their kickstarter -- you won't regret it.

(Or if you don't cook, they have a tier to get their baked goods, which I can verify are wonderful!  And the smoked vanilla caramel?  Good lord that is good.)

There is no risk, no wait once the kickstarter is over, they have already been making these products, this kickstarter will help support their company.

Also the patches are pretty awesome. :)
Shane Bugbee's profile photoayearat thewheel's profile photo
Thank you so much Dianne! I truly appreciate your support and encouraging words! Thanks!
Add a comment...

Dianne Hackborn

Shared publicly  - 
This is really, really good vanilla:
It cost's you nothing to share this video. thanx in advance for your support.
View original post
Christian Kopp's profile photoChristopher Tate's profile photoMatthew Runo's profile photo
What makes it good? I've been buying my extract from Amazon (good quality, no suger, etc)... Thoughts on difference?
Add a comment...

Dianne Hackborn

Shared publicly  - 
PSA: The new requirement to immediately finish an activity if using Theme.NoDisplay is not a regression, this has always been a requirement of it (see for example).

The reason the platform in M is now crashing the app if it doesn't use this is because not using it would previously break in very subtle and mysterious ways.  For example, you would sometimes end up with your app ANRing for no reason.

Why is this?  Because what Theme.NoDisplay actually does is completely prevent the window for the activity from being shown.  That is, the activity gets launched, but a window for it is never displayed.

If you don't immediately finish the activity in this situation, the app is in a bad state: it has an activity being launched that the system is waiting for a window to be displayed for, but no window will ever appear.  So depending on how the timing goes, you can end up with the system sitting there waiting to see the window appear, which it never does, and bam you have ANRed.

We realized we were repeatedly debugging reports from developers of their apps ANRing when they shouldn't be, tracking those problems down to misuse of Theme.NoDisplay causing their random ANRs.  It is better for all of us if the platform catches this consistently, early, with a clear message about what the app did wrong.

If you really need to have a transparent activity that doesn't immediately finish, you can use Theme.Translucent.NoTitleBar to have a window that is completely transparent.
Marius Gedminas's profile photoDianne Hackborn's profile photoLiran Barsisa's profile photomeng wang's profile photo
Add a comment...
Have her in circles
29,759 people
Alex Wheeler's profile photo
David Ageloc's profile photo
Khoo yao jiunn's profile photo
‫خالد العقرب‬‎'s profile photo
Farzam FardManesh's profile photo
Rildo Zavaleta Hancco's profile photo
Игорь Кравчук's profile photo
Niklas Carledal's profile photo
Tom Mulcahy's profile photo

Dianne Hackborn

Shared publicly  - 
"How should I design my Android application? What kind of MVC pattern should I use? What should I use for an event bus?"

We often see questions from developers that are asking from the Android platform engineers about the kinds of design patterns and architectures they use in their apps. But the answer, maybe surprisingly, is we often don't have a strong opinion or really an opinion at all.

(Edit to clarify: when I write "we" here I am talking about the Android platform team. I am not speaking for all of Google or Android developer relations. There are lots of good suggestions and opinions inside and outside of Google about how to write apps, and I am not intending to dismiss those.)

Should you use MVC? Or MVP? Or MVVM? I have no idea. Heck, I only know about MVC from school and had to do a Google search to find other options to put here.

This may be surprising, because Android could feel like it has strong opinions on how apps should be written. With its Java language APIs and fairly high-level concepts, it can look like a typical application framework that is there to say how applications should be doing their work. But for the most part, it is not.

It is probably better to call the core Android APIs a "system framework." For the most part, the platform APIs we provide are there to define how an application interacts with the operating system; but for anything going on purely within the app, these APIs are often just not relevant.

That said, the Android APIs can often look different (or higher level) from what one typically expects in an operating system, which may easily lead to confusion about how they should be used.

For an example of this, let's consider how an operating system defines "how to run an app." In a classic system, this is basically the contract it has with an application about when it should run:

int main(...) {
// My app goes here!

So the operating system starts the app, calls its main() function, and the app goes off and runs and does what it wants until it decides it is done. And clearly it is not saying anything here about what the app should be doing or how it should be designed within that main function -- it's a pretty pure blank slate.

In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. In particular, we wanted to build a system where the user never needed to think about starting and stopping apps, but rather the system took care of this for them... so the system had to have some more information about what is going on inside of each app, and be able to launch apps in various well-defined ways whenever it is needed even if it currently isn't running.

To accomplish this, we decomposed the typical main entry point of an app into a few different types of interactions the system can have with it. And these are the Activity, BroadcastReceiver, Service, and ContentProvider APIs that Android developers quickly become familiar with.

These classes may look like they are telling you how the internals of your app should work, but they are not! In fact, they are all about how your app needs to interact with the system (and how the system can coordinate its interaction with other apps). As long as that interaction with the system happens, we don't really care what goes on inside of the app.

To illustrate, let's briefly look at these different APIs and what they really mean to the Android system.


This is the entry into an application for interacting with the user. From the system's perspective, the key interactions it provides with the app are:

• Keep track of what the user currently cares about (what is on screen) to ensure the process hosting that is kept running.
• Know that previously used processes contain things the user may return to (stopped activities), and thus more highly prioritize keeping those processes around.
• Help the application deal with the situation where its process is killed so the user can return to activities with their previous state restored.
• Provide a way for applications to implement user flows between each other, coordinated by the system. (The most classic example here being share.)

What we don't care about:

Once we have gotten in to this entry-point to your UI, we really don't care how you organize the flow inside. Make it all one activity with manual changes to its views, use fragments (a convenience framework we provide) or some other framework, or split it into additional internal activities. Or do all three as needed. As long as you are following the high-level contact of activity (it launches in the proper state, and saves/restores in the current state), it doesn't matter to the system.


This is a mechanism for the system to deliver events to the application that may be outside of a regular user flow. Most importantly, because this is another well-defined entry into the app, the system can deliver broadcasts to apps even if they aren't currently running. So, for example, an app can schedule an alarm to post a notification to tell the user about an upcoming event... and by delivering that alarm to a BroadcastReceiver of the app, there is no need for the app to remain running until the alarm goes off.

What we don't care about:

Dispatching events within an app is an entirely different thing. Whether you use some event bus framework, implement your own callback system, whatever... there is no reason to use the system's broadcasting mechanism, since you aren't dispatching events across apps. (In fact there is good reason not to -- there is a lot of unnecessary overhead and many potential security issues if using a global broadcast mechanism for the internal implementation of an app.) We do provide the LocalBroadcastManager convenience class that implements a purely in-process intent dispatching system with a similar API to the system's APIs, if you happen to like them. But again, there is no reason to use that over something else for things going on purely within your app.


A general-purpose entry point for keeping an app running in the background for all kinds of reasons. There are actually two very distinct semantics services tell the system about how to manage an app:

Started services are simply telling the system to, for some reason, "keep me running until I say I am done." This could be to sync some data in the background or play music even after the user leaves the app. Those also represent two different types of started services that modify how the system handles them:

• Music playback is something the user is directly aware of, so the app tells the system this by saying it wants to be foreground with a notification to tell the user about it; in this case the system knows that it should try really hard to keep that service's process running, because the user will be unhappy if it goes away.

• A regular background service is not something the user is directly aware as running, so the system has more freedom in managing its process. It may allow it to be killed (and then restarting the service sometime later) if it needs RAM for things that are of more immediate concern to the user.

Bound services are running because some other app (or the system) has said that it wants to make use of the service. This is basically the service providing an API to another process. The system thus knows there is a dependency between these processes, so if process A is bound to a service in process B, it knows that it needs to keep process B (and its service) running for A. Further, if process A is something the user cares about, than it also knows to treat process B as something the user also cares about.

Because of their flexibility (for better or worse), services have turned out to be a really useful building block for all kinds of higher-level system concepts. Live wallpapers, notification listeners, screen savers, input methods, accessibility services, and many other core system features are all built as services that applications implement and the system binds to when they should be running.

What we don't care about:

Android doesn't care about things going on within your app that don't have any impact on how it should manage your process, so there is no reason to use services in these cases. For example, if you want to start some background operation to download data for your UI, you should not use a service for this -- it is actually important to not be telling the system to keep your process running while doing this, because it really doesn't need to be and the system would be better off having more freedom in managing it with other things the user is doing.

If you just make a simple background thread (or whatever non-service mechanism you want) to do the downloading, you will get the semantics you want: while the user is in your UI, the system will keep your process running for that, so the download will never be interrupted. When they leave your UI, your process will still be kept around (cached) and able to continue downloading, as long as its RAM isn't needed elsewhere.

Likewise for connecting different parts of your app together, there is no reason to bind to a service that is running in the same process as the one binding to it. Doing so is not actively harmful -- the system just sees a dependency from the process to itself so doesn't try to keep it around any more than usual -- but it is a bunch of unnecessary work for both you and the system. Instead, you can just use singletons or other normal in-process patterns for connecting pieces of your app together.


Finally, the ContentProvider is a fairly specialized facility for publishing data from an app to other places. People generally think of them as an abstraction on a database, because there is a lot of API and support built in to them for that common case... but from the system design perspective, that isn't their point.

What these are to the system is an entry-point into an app for publishing named data items, identified by a URI scheme. Thus an app can decide how it wants to map the data it contains to a URI namespace, handing out those URIs to other entities which can in turn use them to access the data. There are a few particular things this allows the system to do in managing an app:

• Handing out a URI doesn't require the app remain running, so these can go all over the place with the owning app being dead. Only at the point where someone tells the system, "hey give me the data for this URI" does it need to make sure the app owning that data is running, so it can ask the app to retrieve and return the data.

• These URIs also provide an important fine-grained security model. For example, an application can place the URI for an image it has on the clipboard, but leave its content provider locked up so nobody can freely access it. When another app pulls that URI off the clipboard, the system can give it a temporary "URI permission grant" so that it is allowed to access the data only behind that URI, but nothing else in the app.

What we don't care about:

It doesn't really matter how you implement the data management behind a content provider; if you don't need structured data in a SQLite database, don't use SQLite. For example, the FileProvider helper class is an easy way to make raw files in your app available through a content provider.

Also, if you are not publishing data from your app for others to use, there is no need to use a content provider at all. It is true, because of the various helpers built around content providers, this can be an easy way to put data in a SQLite database and use it to populate UI elements like a ListView. But if any of this stuff makes what you are trying to do more difficult, then feel free to not use it and instead use a more appropriate data model for your app.
Ke Ning's profile photoAnanth kumar's profile photoSujay Kumar B S's profile photoAlex Bonel's profile photo
Sorry for being late.

+Dianne Hackborn Should we resort to use system components if we want to ensure data consistency in our application?

Here's a typical example. If I use a background thread to perform network requests in my application, if I understand correctly, then there's a possibility that my application could be killed by the system at any time (?): either just after sending request to the server without receiving the answer from it, or even worse, while processing or recording the received answer to some storage?

Should I use a Service in this particular case, or there's no point to worry, and we can rely on the file system or SQLite (if we use them as a storage) if they ensure transaction semantics? Or we should ensure this consistency in our application by ourselves not relying on system components?

I think +Nicola Dorigatti have the same implication in his question.
Add a comment...

Dianne Hackborn

Shared publicly  - 
Good to know!
Secure those bits!

The Android security team has been hard at work building new tools to help developers protect user data in transit.  :)  Yesterday Alex posted about two great features that shipped last year in M:

I'm particularly proud of the strategy I came up with to help detect any plaintext traffic leaving an app using a complex pile of iptables rules.  It's super easy to enable detection in your app with just one method call to this new StrictMode API:

And here's the guts of where the iptables rules are generated using the powerful u32 module to do "shallow" packet inspection, both IPv4/v6 and TCP/UDP are supported:

Since it does bit banging to sniff out the explicit SSL 3.1 (TLS 1.0) signature, I don't recommend shipping it enabled in production, as that version number might increment in the future.
6 comments on original post
Ian Lake's profile photo
Great to see how it works under the covers! I talked about it in our recent StrictMode video ( and blog post (
Add a comment...

Dianne Hackborn

Shared publicly  - 
Rock, Paper and Scissors don’t have much in common, but that won’t stop them. Be Together. #NotTheSame
183 comments on original post
Steven Thurgood's profile photoewhac's profile photoTristan Fillmore's profile photoAndy Bohm's profile photo
WTF?!?!? Did that first bully remove a part of his own body, chew it up and spit it out through a straw?!?!? Or worse?!?! Did he tear a chunk off of another person???

That's just twisted.
Add a comment...

Dianne Hackborn

Shared publicly  - 
This joke would be impossible to execute on Twitter, where replies quickly get clogged with the usernames of everyone involved, or on Facebook, where all it takes is one "lol you guys are nuts" from someone's mom to derail all the fun.

It worked well on Usenet, too! :p
It starts with a confession: "I have no idea who Scalia was." Then a joke, to deflect attention from a failure on the part of public education: "Isn't that the thing that people call themselves...
Matt McIrvin's profile photoShawn Willden's profile photoMoshe Brevda's profile photoJohn Ruble's profile photo
I see this kind of thing on Reddit too. I guess it needs to 1) be threaded, and 2) display the route from trunk to leaf, without any sibling branches
Add a comment...

Dianne Hackborn

Shared publicly  - 
Psychonauts 2?!? YES PLEASE!
Psychonauts is a classic action/adventure platformer from acclaimed developers Double Fine Productions (that’s us!) and written by industry legend Tim Schafer, who created Broken Age, Full Throttle, and Grim Fandango amongst many other things. We want to make a sequel!
Dianne Hackborn's profile photoVladimir Shabanov's profile photoahmad azhar's profile photo
dianne hi, I was one of android users, please give me some info of what application should i download for android and what applications are inappropriate or not useful to an android, tQ
Add a comment...

Dianne Hackborn

Shared publicly  - 
Andrew Oplinger's profile photoRichard Vowles's profile photo
Tears for Fears really came up with some gems.
Add a comment...
Have her in circles
29,759 people
Alex Wheeler's profile photo
David Ageloc's profile photo
Khoo yao jiunn's profile photo
‫خالد العقرب‬‎'s profile photo
Farzam FardManesh's profile photo
Rildo Zavaleta Hancco's profile photo
Игорь Кравчук's profile photo
Niklas Carledal's profile photo
Tom Mulcahy's profile photo
Write code and manage people who write code.
  • Google (Android)
    Android Framework Engineer, 2005 - present
  • PalmSource
  • Be Inc.
  • Lucent Technologies / AT&T
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Naperville, IL - Corvallis, OR - Meridian, ID
Google (Android Framework)
  • Oregon State University
    Computer Science, 1989 - 1996
Basic Information