Cover photo
Dianne Hackborn
Works at Google (Android)
Attended Oregon State University
Lives in California
29,268 followers|3,290,923 views


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.
陈剑锋(chenupt)'s profile photoJomar Tigcal's profile photoChris Boyle's profile photoCloud Chen's profile photo
Add a comment...

Dianne Hackborn

Shared publicly  - 
These are hilarious.  I can't decide which is my favorite.  Is it "don't take a selfie and wave a gun around at the same time (two stupidities don't make a smart!)"?  Is it "don't take a selfie while falling down stairs"?  So many choices!
From the "Selfies kill" brochure by Russia's Interior Affairs Department.

Full PDF over at
9 comments on original post
Alessandro Cherin's profile photoPetr Moravek's profile photoDavid Prather's profile photoTomas Geczi's profile photo
Add a comment...

Dianne Hackborn

Shared publicly  - 
As usual, great talk for developers on what is new in the next release!
Those I/O folks are getting faster and faster at posting our talks on YouTube. Next year, they'll be live before we give them, which would save us the effort of actually doing the talk, since we could simply queue the video instead.

Presenting... What's New in Android, with +Dan Sandler:
25 comments on original post
Vadim Tkachenko's profile photoMark Stevens's profile photoAmit Singh's profile photoFiorella Schischlik's profile photo
Dianne, also I for this moment have my simple Bluetooth app that crashes with TransactionTooLargeException if I'm starting it with debugger attached from Android Studio.

But it works fine if I start it without debugger or if I place breakpoint at the start of the app and then hit "continue".

So this Binder IPC limit bug poisons even debugging of the android apps.

Please fix that.
Add a comment...

Dianne Hackborn

Shared publicly  - 
Ah Nataly Dawn, your music is so awesome.  Please please do another solo album. :)


Maybe here's a working link:
Dianne Hackborn's profile photoAlan LaMielle's profile photoSpencer Riddering's profile photoMauricio Porto's profile photo
Nataly is amazing. Her and Jack are the best!
Add a comment...

Dianne Hackborn

Shared publicly  - 
Our neighbors right next door to us run a business, Fireworks Ceramics, where you can have parties to paint ceramics that they will then glaze and fire for you.

While my family was visiting for the holidays this year we went over to paint some ceramics, and this is the result. :)
Ana Inés de la Fuente's profile photoDan Sandler's profile photoStefan Sonesson's profile photoShane Bugbee's profile photo
very cool! love the red and black tile and cup next to it... hell, they are all rad!
Add a comment...

Dianne Hackborn

Shared publicly  - 
90% off Shadow Warrior...!  If you don't have it, just go buy it. :)
Shadow Warrior is a bold reimagining of the classic 3D Realms’ shooter from independent developer Flying Wild Hog (Hard Reset) starring the legendary and quick-witted warrior Lo Wang. Combine the brute force of overwhelming firepower with the elegant precision of a katana to annihilate the merciless armies of the shadow realm in an...
Sascha Prüter's profile photoIan Stedman (Magic Meeple Games)'s profile photoNicolay Doytchev's profile photoHenning Hoefer's profile photo
All this did is make me buy the original re-release - Shadow Warrior Redux...
Add a comment...
Have her in circles
29,268 people
Karthik Subramaniam's profile photo
KH Moch Oemar Yusman Roy's profile photo
Charlie Burgess's profile photo
Sándor Berkes's profile photo
Justin Meyer's profile photo
Vasco Coelho's profile photo
Eyal LEZMY's profile photo
Orly Zeelon's profile photo
Chris Schofield's profile photo

Dianne Hackborn

Shared publicly  - 
This is a pretty good overview in Ars on Marshmallow.  While looking through it, I saw some things that could use more explanation so thought I'd share my comments.

Extended Voice Actions:

The discussion about how applications work with the new voice interaction service may be a little misleading.  As with Now on Tap, applications here don't directly interact with Google; rather they go through a platform API ( for those who care) which interacts with the back-end speech recognition service.  So I wouldn't describe this as developers plugging in to the Google App -- they are using the platform API, which has a back-end plugged in to it (by default via the Google App) that does the recognition.

This is very much how Now on Tap is integrated into the platform, as described in the previous section.  In fact, it isn't very much like, it is it!  Now on Tap and the new voice interaction are all part of the currently enabled VoiceInteractionService, which is what you are selecting when you select which assistant you want.  (This is also why voice actions can now use the context of what you are currently looking at to help with the recognition, because it is also the assistant so it that can do that.)

So, it wouldn't make sense for this to move to a Google Play Services API, because it is a very well-defined platform API.  This also isn't really the first time this pattern has appeared: it is basically how input methods work, where platform APIs arbitrate interaction between the application and the current back-end input method.  More closely, speech-to-text and the old simple speech recognizer are both pluggable components, which applications interact with through a (simple) platform API to whatever back-end implementation the user has selected.


On the topic of organization of "permissions," while I would agree there is some further cleanup that can happen in the UI, in many cases things are deliberately not simple runtime permissions.  For example, the new "Draw over apps" and "Modify system settings" controls actually correspond to existing permissions, which we explicitly didn't want to turn into simple runtime permissions.  We want to discourage apps from using them unless they have a really good reason, and they don't have anything to do directly with specific personal data access so are really hard to explain to users.

You'll note there is a warning dialog that appears when enabling an app's access to one of these, giving more information about what is happening.  This is also a pattern followed by other existing dangerous access controls like accessibility services and usage access.

Speaking of accessibility, if anything we'd like to see that made less easy for apps to get to.  This feature really is intended for accessibility services, and you should be skeptical about any other kind of app asking for access to it -- it gives that app almost complete control over your device and the ability to see everything you do on it!

Also fwiw, the new runtime permissions implementation makes use of app ops for applying permissions restrictions to pre-M applications.  You can basically see this as the long desired UI for app ops, and app ops' basic behavior remains the same where turning off access means the app simply sees no data (no location, zero contacts, etc).  We never create fake data.


Abuse of high priority messages have a special difference from other things like notifications: they must go through Google servers, so Google can monitor and modify what is being sent to devices.  If apps abuse these for other things besides their intended use, we will be able to stop that abuse without touching any software on the device.  (Also "abuse" here is much less subjective than for notifications, where there is a large gray area of things some users care about and some don't.  For high priority messages, if it isn't something that is time critical to go to the user immediately, it is not appropriate.)

Chrome Custom Tabs:

This isn't really tying an app to Chrome.  It is defining an extended API with the browser than an app can use to get the behavior.  The standard implementation used by apps should work with any browser as long as it supports the API, regardless of what the default browser is.  So Firefox and others should be able to implement the same API as Chrome and get the same behavior from the same apps.
Marshmallow brings a lot of user-requested features but still has no update solution.
Andreas Proschofsky's profile photoNandan Vaidya's profile photoBenjamin Ferrari's profile photoJeffrey King's profile photo
+Dianne Hackborn I take back my comment about users not being able to see all the permissions! I found the option in the permissions screen in the overflow menu which allows to see all the old-style permissions. So I wanted to clarify this for potential future readers.

Also I've watched the "Mother, May I?" talk on YouTube

It really clarifies some things. It does talk about READ_PHONE_STATE permission and how you can avoid requesting that (in addition to what Dianne suggested above regarding audio focus APIs).

Unfortunately they didn't talk about GET_ACCOUNTS permission. Hopefully AccountManager.newChooseAccountIntent really helps with avoiding that (I still need to investigate on this more).

I've started to understand Marshmallow approach better and I think I'm changing my mind and I think we're on the right track. We just need more developers embrace the new model and request less permissions if they don't really really need them.
Add a comment...

Dianne Hackborn

Shared publicly  - 
One of the things we've been working on for M that wasn't in the keynote.  Actually we started on this in L -- if you saw that VoiceInteractionService thing appear in the L SDK and thought "wtf why is there this weird thing here that doesn't really do a whole lot?"...  well this is what it actually is. :)
William Brine's profile photoJarek Wilkiewicz's profile photoMichel Racic (rac)'s profile photoBruce Benedict's profile photo
Hola tengo un móvil con 2 baterias, una interior 3,7V 2200mAh, y otra con cables fuera 3.7V 3000mAh. Pero el medidor no mide bien, al 5% tiene 3,6V y se apaga lo enciendes, y pasa a un 20%. Me gustaria quitarlo el medidor. Gracias!

Hi I have a phone with two batteries, an internal 3.7V 2200mAh and 3000mAh 3.7V connected by wires cables. But the meter does not measure well, 5% have 3.6V and you phone goes out, and restart passes 20%. I would like to remove the meter. Thanks! 
-The phone: -The Batterie:
*Batería segundaria/Battery secondary:
 ·  Translate
Add a comment...

Dianne Hackborn

Shared publicly  - 
Wow, this show is so incredibly good.  We just spent the past week tearing through the two current seasons...  and now have to wait for more.  *sob*

I was worried that the clone thing would end up a little gimmicky, but it is not at all, it is incredibly well done and never stands out in ways it shouldn't.
Sarah hopes that cleaning out a dead woman's bank account will solve all of her problems. Instead, h...
Mark Womack's profile photoSondra H.'s profile photoJustin Smith's profile photoArshad Khan's profile photo
I think we watched a couple before we came down and it looks interesting.  I think we have a couple more in The Good Wife and then we will get back to it.
Add a comment...

Dianne Hackborn

Shared publicly  - 
"From the designers of World of Goo and Henry Hatsworth in the Puzzling Adventure"

Okay, no more needs to be said, I'm there.  How did I miss this until now?!?
"A beautiful masterpiece", "inventive, moving and unrelentingly funny", "a ...
Paul M Edwards's profile photoStacy Devino's profile photoZeynel Abidin Öztürk's profile photoMike Pearce's profile photo
+Paul M Edwards  I agree. I mean under his definition, Goat Simulator would not be a game. Now, I wouldn't argue that its a great game, but an interesting concept that is just kinda funny when you try it.

If looking for a great old casual game : Bubble Ghost 

My favorite version is the one for the GameBoy just because the graphics are a bit more refined. 
Add a comment...

Dianne Hackborn

Shared publicly  - 
I really like this article on the importance of thinking about performance during development, instead of ignoring it completely with the excuse of "premature optimization."

This is especially relevant for mobile development: performance issues that users don't even see can have negative impact on things like battery life; the resource requirements of our code has a direct impact on the hardware it requires to run well, which can completely push the product out of large markets; and user's expectations of the responsiveness of mobile applications tends to be higher than desktop applications even though they are running on slower more constrained hardware and often with much higher-resolution screens.

My own feeling on this is that as a professional software engineer, part of our job is to understand the actual trade-offs we are making during implementation.  There are many things you can do that will be significantly more expensive than other options, which really aren't worth whatever small advantages they provide.  Integral to being proficient at a language, framework, or platform is having a general understanding of the relative efficiency of the various ways you use it so that you can use that knowledge as part of the decision making process throughout development -- from design through implementation and maintenance.  That is not "premature optimization," that is making good use of your tools.

Another way to look at it is this: the hardware you are running on has a fixed amount of resources; when you are implementing your code, you are deciding how to make use of those resources.  Every decision you make that favors other things over efficient use of those resources is also a decision that is limiting the number of features you can deliver to your users, because those resources are no longer available to deliver features.  Of course this doesn't mean you should micro-optimize everything you do, but you also shouldn't ignore efficiency at all -- you need to understand the trade-offs you are making to create the best product for your users.  If you don't, there is a good chance another developer will make better decisions, and be able to developer a superior product that is able to deliver more or better features because they have a more efficient implementation without really sacrificing their productivity.

For example, there are a lot of things in the Java language that can lead to significantly less efficient results than other equally viable approaches.  Selecting between a standard or enhanced for loop can have a 3x difference in performance when iterating over an ArrayList; Java enums are tremendously more expensive in code size than simple static final ints; classes and objects have not-insignificant overhead, so if you take a very class-heavy approach to your implementation you can end up with a significantly larger code size and RAM footprint for your app.

All of these are things that you decide throughout the implementation of your app, but are very hard to fix later on.  This is not the kind of stuff you can throw under a profiler and see, "oh here is the hot spot in these 100 lines of code" and spend a day optimizing that.  Instead what you end up with is pervasive small performance problems throughout your entire app that add up to a large problem, for which a profiler will either not reveal any clear indication of a problem at all (because it is everywhere), or you will end up in an "oh sh*t" moment where you realize that fixing your performance problems are going to require changes all through your code base.

One experience that will always stick with me was when I was working at a previous company on a mobile operating system.  We had spent a few years working on it, had the system up and running on reference hardware, but were not happy with the performance we were getting.  We did a lot of profiling, trying to find what was causing it to be slow, but couldn't find anything significant.  Finally in desperation we went to the hardware manufacturer and asked if they could help out.

The answer we got back from them: "you are running too much code."  Out first reaction was, wtf, of course there is too much stuff being done, but what is it?  But the problem wasn't that there was some specific parts of the platform that needed optimization, it was that just generally all over the place the implementation was too expensive for the hardware it was running on.  It was blowing out the CPU caches all over the place, needing too many instructions given the speed of the CPU, etc.  Fixing such issues requires tremendous work across the code-base reworking how every little thing is implemented to get rid of overhead.  It is lots of steps of find 1% here, .5% there, and on and on, until you either run out of time or you eventually decide "good enough."  It is not a situation you want to be in at the end of your product development.

Our Android documentation has a lot of information on these topics for both Java and the Android framework that every Android developer should have a good understanding of:
Andreas Adam (AA1973)'s profile photoSeyed Mohammad Hossein Mayboudi's profile photoCarlos Sobrinho's profile photoAbu Ruqaiyah's profile photo
+Miguel Vargas I seriously think that document hasn't been given enough attention by Google, and therefore does not merit enough respect.  If they wrote that b.s. about Enums there, then how can you trust other information in there is accurate?
Add a comment...

Dianne Hackborn

Shared publicly  - 
Nice new storage APIs in Lollipop, courtesy of Jeff Sharkey.

Also worth noting is the new getExternalMediaDirs() method that gives you a place for your own files on any available secondary storage, without needing to request read/write permissions:
Richer access to secondary shared storage devices

In KitKat we introduced APIs that let apps read/write file in app-specific directories on secondary storage devices, such as SD cards.

We heard loud and clear that developers wanted richer access beyond these directories, so in Lollipop we added the new ACTION_OPEN_DOCUMENT_TREE intent.  Apps can launch this intent to pick and return a directory from any supported DocumentProvider, including any of the shared storage supported by the device.  Apps can then create, update, and delete files and directories anywhere under the picked tree without any additional user interaction.  Just like the other document intents, apps can persist this access across reboots.

This gives apps broad, powerful access to manage files while still involving the user in the initial selection process.  Users may choose to give your app access to a narrow directory like “My Vacation Photos,” or they could pick the top-level of an entire SD card; the choice is theirs.

To make it easy for developers to transition to these new APIs, there’s a new DocumentFile support library class.  It looks and feels just like a traditional java.lang.File object, which makes it easy to adapt existing code:

These new APIs aren’t just limited to shared storage; they can be used with any DocumentsProvider that adds support for Root.FLAG_SUPPORTS_IS_CHILD, such as the advanced Vault example:

#android   #sdcard   #psa  
Madan Ankapura's profile photoChristian Melchior's profile photoOliver Kötter's profile photoChi Draconis's profile photo
+Emil Georgiev could you advice how to choose the place to store images for a camera app which suppose to run on both Kitkat and Lollipop?
Add a comment...
Have her in circles
29,268 people
Karthik Subramaniam's profile photo
KH Moch Oemar Yusman Roy's profile photo
Charlie Burgess's profile photo
Sándor Berkes's profile photo
Justin Meyer's profile photo
Vasco Coelho's profile photo
Eyal LEZMY's profile photo
Orly Zeelon's profile photo
Chris Schofield'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