Cover photo
Dianne Hackborn
Works at Google (Android)
Attended Oregon State University
Lives in California
26,579 followers|2,526,309 views
Have her in circles
26,579 people
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
Contributor to
Google (Android Framework)
  • Oregon State University
    Computer Science, 1989 - 1996
Basic Information


I noticed a few posts from people on the new document-centric recents in Android:

Might as well post my own thoughts. :)

I'm really excited about this feature in L -- it will probably significantly change the application experience on Android more than you may think from what you have seen so far.

If you have the developer preview running, you can get an idea for how this changes things through a few flows:

- Go to an app in Play Store, hit the share button, select Gmail: this will launch a Gmail compose activity as a separate task, instead of part of the Play Store task.  Any existing Gmail task is left as-is.  When you finish the compose (sending or backing out), the task goes away.  This currently works for sharing to any target as long as you go through a standard share dialog.

- Go to Play Movies, go in to one of your movies; scroll down to the shopping recommendations and tap one (or select shop in the side bar).  This will launch the play movies app for shopping as a separate task.  You can now use recents to switch back to your movie without losing what you were shopping for.

- Go to Gmail and look at an e-mail with a YouTube link; click on the link and launch the YouTube app.  The YouTube player activity for that video is now in its own task and you can use recents to return to your e-mail without closing the video.

Note that none of these flows have required any changes to the apps involved: they are being done by the platform introducing some new behavior when going through the platform's share UI, and re-interpreting the existing FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET flag.

The share flow is pretty straight-forward: we just tack on some new flags when launching the target activity, one to have it in a new document task and another to have the task go away (instead of remain in recents) when there are no more activities in it.  This is very safe for current applications, since they are already dealing with a case where one of their activities is running separately as another task.  It's just now that task is a dedicated task, instead of some other app's task.  The main compatibility issue is for apps that implement their own custom share UIs, which won't get this behavior.  So those will need to update or, ideally, please switch to using the platform's UI for this. :)

FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET is more interesting.  We had a lot of discussion about this, because there is some rightful concern that this is changing the semantic of the flag in ways that are problematic for apps.  But my argument is this: the meaning of the flag is, "hey system yeah I know I am launching this thing as part of my task, but to the user it isn't really part of my app, so if they re-launch me from home please get rid of it or the user is doing to be very confused."  In the new document-centric recents world, that situation is pretty much exactly the situation where the correct thing to do now is to create a new document task.  So that flag is now poof FLAG_ACTIVITY_NEW_DOCUMENT.  And as such, when you tap on a link in Gmail, or launch Play Store from Play Movies, these are now represented as new tasks instead of stacking on the existing task.  And the user experience for this really is not all that different: still, if they re-launch the base app from home, they will come back to where they expect.  They can just still get to the separate task they had launched from recents.  And now if they bring up recents to return to the app, they see that they can return either to the base app or the separate document they had launched from it.

For developers, a key thing will be to just make sure your apps are using FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET/FLAG_ACTIVITY_NEW_DOCUMENT in appropriate places.  This will actually give you the correct behavior on both L and previous versions of the platform.

And for the smaller set of apps that really are document-centric (office suites, web browsers, etc), in L we have a more extensive set of APIs for you to represent those documents in recents and manage what is shown to the user and what happens when they are launched.
Tony Hoffman's profile photoJulien Ho's profile photoWill Keaney's profile photoLucas Laurindo dos Santos's profile photo
Actually I think the best flag for intents is "FLAG_ACTIVITY_NEW_TASK" , as it will force the launched app to be on a new task, which will allow you to switch between your app and the launched app easily.
Add a comment...

Dianne Hackborn

Shared publicly  - 
Nice little interview with an artist I happen to know. :)
I produce a website that questions artists about art... here is the newest edition to the interviews on underground art... 
Sondra H.'s profile photo
Well, I know who the artist is.  Who is Shane?
Add a comment...
For several years now, mobile device manufacturers have been in a race to push the pixel density of mobile devices higher and higher. The race began with the iPhone 4 “Retina” display – an at the time impressive 330 pixels per inch (PPI) 960x480 3.5” display.

sigh  No, it did not.

Android started it on modern smart phones, with the original Droid that was 240dpi, and the platform itself introduced the robust multi-density support we have today a bit before that in 1.6, including full support for retina class and the ever increasing densities we see today.

But you know what?  It doesn't make sense to say that Android started this, either.  In fact Android from the start had core support for multiple display densities (through the dp units and such), but this happened because of previous experience at PalmSource where Palm devices had already experienced increases in display density, going from the original ~80dpi screen to high resolution 160dpi screens, and then trying to deal with 120dpi screens to be able to use then pervasive 240x320 panels.

The troubles of that last step -- trying to implement 1.5x scaling on a system where apps are using absolute layout of UI elements in pixel coordinates and the resulting strange rounding artifacts -- is a major element of what drove Android's original design.  To be able to do non-integral scalings well, Android relies on layout managers to do final placement of UI elements, which run at the native screen resolution.  The use of layout managers not only makes it a lot easier for applications to adjust to different screen sizes, but also allows scaling screen density by non-integral amounts without causing odd spacing between interface elements or having to use sub-pixel positioning of all elements and the resulting anti-aliasing artifacts.
Fabrice Di Meglio's profile photoColin McMillen's profile photo곽민규's profile photoChris P's profile photo
Yeah I was abbreviating,
Anyways, story time!
I went to the apple store a week ago, bored from finishing my lunch early. I see the iPad mini, note that I was looking down on it from two(three?) feet and then held it up to my chest. Swype look at newsstand, just checking out then the genius girl comes and blathers about specs and features I know and kinda ignore her just looking thank you .. Then she motions to another iPad mini, less bright and paler in color, that was the retina one. Oh, I go.. I did not see a difference at first sight in pixel density but the retina mini has less color gamut and I actually liked the original more since it produced richer colors .... That price tag doe...
In the end apple did not make those panels lg did, and display companies are pushing the resolution up more and more, and then comes the perplexity of why does a 50" display cost hundreds to make and yet the sgs5 display only $63? R&D and pushing those pixels are the culprits hence the iPad mini 2013 released with an a7.
Add a comment...
For anyone interested in how the internals of Android work, the new 4th edition of Tanenbaum's Modern Operating Systems book is out and includes about 50 pages on Android that I had the privilege of contributing.  Topics in the book include:

- What Android is, its design goals its relationship to Google, and a brief history of its early development.
- What wake locks are, why they exist, and how they work.
- The design and purpose of the Android out-of-memory killer.
- Dalvik's role in Android.
- Binder IPC, from the kernel module to user space: the execution flow of IPCs, what Binder objects are and how they are transported across processes, the core Binder classes (IBinder, Binder, Parcel), AIDL and how it fits on top of the architecture.
- Structure of an Android application.
- How the activity manager runs applications, and the models behind activities, services, receivers, and content providers.
- Intents and intent resolution.
- How activities, content providers, and intents work together to create major Android features such as sharing and fine-grained URI-based permissions.
- The design of Android's application sandboxes and how it leverages Linux's core security features.
- How processes are launched and initialized, and how their lifecycle is managed by the system.

Note that this is part of an operating system design book, so this is not generally material that will be of interest to developers implementing code on top of Android -- there is little discussion of actual APIs or how to implement things using Android, nor does it delve much into the actual code implementation of the system.  It does however have a wealth of information on many of the core designs in Android and the reasons Android works the way it does.
Jason Gann's profile photoRory Macdonald's profile photoRitchie Philip's profile photoAlex Lockwood's profile photo
$135 😐
Add a comment...

Dianne Hackborn

Shared publicly  - 
New favorite soda: Virgil's Zero Real Cola.  (And of course the root beer as well.)
Kevin Brown's profile photoAlan LaMielle's profile photoGene Chiu's profile photoDaniel Cormier's profile photo
Virgil's makes great beverages. I bought a mini keg of their root beer and enjoyed it.
Add a comment...
Most surreal piece of tech reporting so far this year.

h/t +Andrew Stadler 
Matthew Gardner's profile photoChristopher Perry's profile photoChris P's profile photoChristopher Smith's profile photo
Stuff like this makes me worry about the effects of second hand stupidity.
Add a comment...
Have her in circles
26,579 people

Dianne Hackborn

Shared publicly  - 
Also another one I recently finished and quite enjoyed: Call of Juarez Gunslinger.  I can't say I am really in to westerns, but this one is really well done and has a very fun narrative self-awareness about it.
Add a comment...

Dianne Hackborn

Shared publicly  - 
Just noticed that Shadow Warrior is on sale at Steam.  One of the more enjoyable first person shooters I've played recently, well worth the 80% off price!
Richard Gaywood's profile photoSean Reynolds's profile photoTerry Poulin's profile photoBenjamin Ferrari's profile photo
+Benjamin Ferrari You are me, apparently.
Add a comment...

Dianne Hackborn

Shared publicly  - 
So very true.
A guide to understanding us engineers.

[edit: I forgot to add an important one:
Working as intended = Reality is wrong, and has to be fixed to match the output of the code]
Tommy McCarthy's profile photoMario Miniaci's profile photoRich Visotcky's profile photoChristian Ide's profile photo
+Dave Roth Oh snap! And I have been wasting my time with :wq all this time. I'll try that instead.
Add a comment...

Dianne Hackborn

Shared publicly  - 
Finally!  Blog post on the new "procstats" service in Android 4.4.

This was a fun feature to work on.   I am pretty happy at how it is already able to provide a dashboard-style representation of RAM consumption (like existing representations of storage or battery use), given the actual complexity of what is really happening with RAM behind the scenes.

Every app developer should keep an eye on this as they develop their app; it is invaluable for catching issues where apps leave processes running more than they should.  This facility will also make it increasingly easy for users to see when applications are running too much or using too much RAM and causing memory issues on their device.

One of the things I find fascinating about operating system development is that many of the problems you need to solve are as much social as technical.  Problems with RAM use are in many ways just an instance of "tragedy of the commons" -- each developer is operating in their own self-interest, where their own app is the most important thing to them, which is perfectly rational in isolation; however, when you put together the output of these individuals on one device, the overall system begins to fail due to over-committed resources like RAM.

An important tool for managing such issues is creating more accountability, by making it visible at the systemic level who the users of your resources are.  That was the thought behind the battery use UI that we did a while ago, and the new procstats tool is a start at taking that same approach for RAM.
Android 4.4 introduces a new tool for analyzing how your app uses system resources over time -- Process Stats. Existing tools let you spot-check your app’s memory use, but Process Stats now gives you a broader, time-based view of your app’s behavior.

Process Stats is based on a new procstats system service that continually monitors the state of all app processes over time, aggregating that information and collecting PSS memory samples from those processes while doing so.  

You can view a graphical representation of your app’s memory information right on the device, by going to Settings > Developer options > Process Stats. For more detailed information, you can also access the raw data collected by the underlying procstats service through an adb shell command

Check out the post below for a walkthrough of Process Stats and details on the memory data behind it and why it's so useful to you as you analyze your app. 


Related developer topics: 
Investigating Your RAM Usage:
Managing your App’s Memory:

Alexander Lent's profile photoAnders Aagaard's profile photoJohan Appelgren's profile photoNithin Sarath's profile photo
Is there an intent that is associated with this screen?
Add a comment...

Dianne Hackborn

Shared publicly  - 
I love this song.  It reminds me of Frank Zappa's great doo-wop songs.
Patrick Horgan's profile photoPaul Almond's profile photoBo Stone's profile photoChristopher Tate's profile photo
Only just started to follow +Dianne Hackborn.
Excuse my ignorance as I am relatively new to android and have been out of software development since 1990!
Anyone who is a fan of Zappa and a senior android software engineer has to be worth following! 
Add a comment...

Dianne Hackborn

Shared publicly  - 
I think Android might not quite be dead, yet.  Maybe in another two years?
곽민규's profile photoPaul Almond's profile photoVijay de Prabu's profile photoSerge Masse's profile photo
+Benji Hertel if I have read correctly it is two years on (written Jan 2012),
Or were you being ironic
Add a comment...