Shared publicly  - 
#AndroidDev #Design

Updates to Android Design

We've updated Android Design with some important new content!

Patterns → Settings (NEW!) (
Design guidelines for application settings.

Patterns → Navigation (
We've updated the "Navigation into Your App via Home Screen Widgets and Notifications" section ( and added the "Navigation Between Apps" section (
Settings is a place in your app where users indicate their preferences for how your app should behave. This benefits users because: You don't need to interrupt them with the same questions over an...
Martin Belcher's profile photoRobyn M's profile photoHugo BALLESTER (Hashtagman)'s profile photoJose Luis Navarro's profile photo
Especially liking the 'navigate into app from widget'.
Thanks for doing this guys! We are already starting to see a change in the app space due to the guidelines. Tons of small apps already follow them. It will just take more times for the big players to jump on board but they will get there.
I don't think I agree with the navigation scheme for widgets. As a user, I ALWAYS expect the back button to take me back to the previous activity, regardless of what app I'm currently in. According to the widget navigation, hitting compose on the widget and then back should take me to the gmail inbox. I never visited the gmail inbox so it makes little sense to me why when I hit back, I would have to go through that activity.

The same thing happens with notifications. If I'm in a news app, get an email notification and click on it, I expect to be able to read the email, hit back and return to my news article. Instead I get taken through the extra step of going through the inbox before I can return to the article. Isn't that the entire purpose of the "up" navigation?
Good stuff. Some choice quotes from new navigation sections got me thinking that perhaps an additional "OS integration" section covering Intents/Intent filters/App widgets from a design perspective would be also be useful, since many apps seem to omit Quick Search integration/URL interception.

Since many (particularly those originating from alternate platforms) use the Design site as a sort of "crib notes" to understanding Android, I think adding such a section would dramatically increase awareness/adoption since the problem seems to be that many don't realize these features exist and/or their significance (classic example being ports implementing their own share widgets from scratch instead of firing off an intent).
thats some awesome stuff, i have an andorid and its awesome now, but with those improvements it will be amazing!!!
+Roman Nurik I'm not sure I agree with this: "In the case of the Back button, you should make navigation more predictable by inserting into the task's back stack the complete upward navigation path to the app's topmost screen." ... isn't this what the up button is for? Isn't it less confusing if "Back" always goes back to the previous screen, regardless of anything else?
+Eric Butler +Craig Jennings I agree this is somewhat controversial, and may seem counterintuitive for certain cases, but AFAIK our user studies showed this scheme better fit users' mental models and helped stabilize expectations for BACK. /cc +Adam Powell
Ah, good to read some of those things cleared up.
The guidelines now suggest that, if a setting would only be used by 20% of our users, we should consider getting rid of the setting and just forcing those 20% to use it the same way as everyone else. This surprises me - I rather thought that this is exactly what settings are for!

I've tended to think that one of the advantages of Android is that you can customize it to work the way you want, rather then having the developers tell you how to use it. I think it is good if the apps have that same advantage.

Also, I previously thought that the continued use of the term 'preferences', as well as 'settings' was just an error, but now I see that both terms are used prominently in the guidelines. Can someone explain the difference?
Regarding the Back button and the Back Stack, +Roman Nurik 's answer - our studies show that this is best for users - is hard to argue with so I will look at implementing that way. However, if this behavior is counter-intuitive for developers and designers then it is likely to be unevenly implemented, and then you have the worst outcome for users: inconsistency.
I Can't help but noticing that the 'Up' button is not present in settings.
This concept is already hard enough to understand for the user so we need to make sure its as consistent as possible.

What is the rational behind not having an up button (apart from the top screen case)?
The overriding principle is that in the new world, Back should not cross task boundaries.

Deep linking from a widget or notification is a task jump. In most cases you've moved to the task of the app that posted the notification.

The Back button's historical navigation model is really useful for a few steps; beyond that it starts getting unpredictable as you're not quite sure what you were doing N steps away. It gets even worse on devices that are designed to stay running all the time and be put into a pocket or a coffee table for hours at a time, retaining the state of everything you were doing beforehand. It gets even worse than that when this history threads across multiple distinct tasks.

To have actually consistent behavior in a world where Back always takes you to what you were previously looking at you'd end up in a lot of weird cases that you don't want. Does pressing Home and returning to the launcher create history, so that Back now takes you back into the app you were in? How about switching tasks within Recents? If the answer to those things is no, why? How does that interact with apps that have an internal idea of history, such as a browser? Which behavior takes over when?

We decided that the most consistent way to deal with this across a wide variety of apps was to declare that Back should not cross task boundaries, leaving each task with its own independent history stack. This makes a task behave very much like a browser tab and has a number of advantages. Back navigates the current task's history, Recents navigates your history of tasks, and Up gives you an anchor for jumping back to a known, familiar place from where you are or jumping over to stay within an app that was used to handle an intent in another task. Back navigates history, Up navigates structure.

When it comes to widgets and notifications, the synthetic back stack for that task creates a history from structure to keep the world consistent. It doesn't matter whether you come back to that task several seconds or several days later, or whether you do so through the launcher, recents, or any other mechanism. Your previous history within that task is far less relevant after a deep link straight into it; where you are now doesn't have a strong contextual link to where you were in that same task before.

More to come on all of this. :)
Thanks for the clarification of the main idea.
I think it makes perfect sense to divide every task into independent history stacks and it certainly clears up a lot of the navigational issues that plagued earlier version of android.
Navigating the music player when entering from the stats bar 'playing' notification for example.

My question still remain unanswered though. What is the reason there is no 'Up' button in main settings? There is for example an up button in application specific settings like calendar's or gmail's
+Björn Lindberg No deep philosophical reason, it just didn't make the deadline. It'll be there later on. The system Settings app is remarkably complex for a number of historical reasons.
+Adam Powell +Roman Nurik Hmm, whilst checking out the backstack behavior of some other 4.0 Google app widgets to compare to Gmail, the 2x2 "Google+ posts" widget threw a spanner in the works of my understanding.

When you hit the compose/camera button on the widget, then press up, it takes you to the homescreen (after the discard confirmation dialog) if you don't have a G+ task already open. That seems to contradict both of the options given in the the Widget guidelines:

"For both of these cases, handle the Up button as follows:

-If the destination screen is typically reached from one particular screen within your app, Up should navigate to that screen.
-Otherwise, Up should navigate to the topmost ("Home") screen of your app."

Or is the Homescreen widget considered the "topmost screen" for this scenario? In which case how do you differentiate whether the main screen of the app or the homescreen should be the topmost screen for a given app widget?
+David Lawerteh sounds like a bug. Up should never take you out of the app (at least I can't think of a situation where that's appropriate).
There are many cases across our own apps that we're cleaning up in this department. :) When in doubt, refer to the guide.
I really liked ICS on the GN (very nice graphics...), but ... I can't use mine as a phone due to the other party to the conversation losing the ability to hear me at some point in the conversation. Went through 3 phones---the last is on my nightstand as a paperweight. :( Samsung states (within the past week), and I quote,
"Thank you for your correspondence and we sincerely apologize for any inconvenience this presents.
As we have checked our reviews, we do not have any known issue for this device. Rest assured that as this is an isolated problem that you have encountered with your phone.
We understand that you have some concerns pertaining to your handset."

Concerns... mhm...
Verizon is willing to send me more phones, but I have a business to run... so I'm using a razr maxx-whose external speaker just stopped working (new phone arriving tomorrow...).

Google is silent.

I'm worried...

Any update/news at ALL would be ... beyond magical.
WOW that many problems with phones, what exactly are you doing with them? Were ya accidently muting calls on the 3 Galaxy Nexus you were having problems with?
I love this guide. This is a fragmentation (of apps) killer. Hope major and most developers will follow them. A consistent experience never hurts.
How to implement the master/individual on/off switches? I guess the individual ones are "SwitchPreference"s and the master ones "TwoStatePreference"s. Are there any examples? Is it possible to support the new style on older versions in a better way than just separated "xml-v*" directories?

By the way, could you please try to introduce separated files for default values? Currently, I have to define them in every source file that gets the preference, as well as each preference.xml, which was only one before Honeycomb, but now there's a whole bunch of them for Honeycomb (using fragments), and it seems like soon there'll be a third bunch for ICS. So the data's redundant in at least 4 places, and if there's an error in one or I miss to modify a new default at one place, strange things might happen...
I did nothing... Stock phone/OS. I've posted about the issue, and it seems many have the same problem-although I couldn't give you any percentages...
+Adam Powell I understand what you mean, but I still disagree. When using Back, I feel I should never be taken to an activity that I haven't seen. In your example of the browser back button, If I was reading the news, saw that I had an email and navigated straight to that email (skipping the inbox) and then hit Back, where would you expect to be taken? I would expect to go back to my article, but in this design, you are saying I should be taken to the inbox. You state that the Back should navigate history, but then adding activities to the back stack without the user's knowledge creates a false history that the user is not aware of. Why is the history not dictated by where the user navigates?

Also, Back will navigate between tasks eventually. In my news article and email example, adding the inbox to the back stack simply makes me press Back one more time before I switch back to the news article (crossing a task boundary). Since that behavior is practically unavoidable, why are we trying to change it to make it harder to do so?

I think the main problem I have with this is that I agree that Back should be behave like the back button of a browser, i.e. when I hit Back I am taken to the previous "page", and yet that is not the behavior you are going for. Instead, you are wanting to add a false history behind the user's back so that when they navigate back, they become confused about why they are seeing an activity they never visited.
IMHO, the entire "back" thing is pretty confusing for common users. There are several different approaches how it's acutally used, partly even by Google apps:
- oneway back throu all previous contents (not necessarily Activities!, mind e.g. directories in file managers or the browser history itself)
- oneway back throu all windows (= activities)
- like a "close" button - which is even supported by Android's differential behaviour between back (onStop, manageable key event) and home (onPause, no ways to handle) buttons. This behavior is also supported by several apps with "Do you really want to close" dialogs or "press again/long to close".

If users expect the back button to bring them to activities they've never seen before, it seems like they are expecting the back button to act similar to a close button. Imagine a bad old Windows app. If you go directly to a task, it often opens a main window and a modal dialog (or sub window / tab) for the task. You close the task, you see the main window. You close the main window, you see the desktop or previous app. Bring this to Android, and the solution would be like "back in the app works like the up button, on the main activity, it returns to the previous app".
Maybe it would've been better if there had been a close button instead of 'back' in the first place. I even read posts and mails from users expecting the app to 'exit' (i.e. stop background services or even terminate the process completely) with 'back' while 'home' keeps it running (like the minimize button in Windows), and almost nobody seems to use the back button from the home screen.

Additionally, I think you should think about whether you stick with the task idea or go back to what people were used from Windows. If I interrupt my current task for another one (like reading a mail I've been notified about), do I wish to finish that task and return, or do I switch to another app that will become active (and thus modifies the history)?
This is great and all but when you give developers editor choice or a spot in the featured section that clearly don't follow any of your guidelines then what's the point +Roman Nurik & +Adam Powell? It seems the development team is doing a good job but what is considered a priority might need to be looked at again when its hard finding a tablet app or even trying to tell if its optimized for it.

Love ICS especially on my Galaxy Nexus and Motorola Xoom (Now Transformer Prime) let me tell you I'm a big supporter but as a user can we get a label system that way we can tell if the app is targeted for either of the two?

I know most believe there shouldn't be such a thing as a separate app for both however that's not the case with the end user experience, things need to be enforced for the time being making it easier on those who me wish to invest in the platform.

A few developers are putting the multiple apk support to good use because why not have the app download according to your device screen size or type, but others are just uploading a separate apk and in the name adding for tablets which makes no sense, yet it does.

IOS separates there apps but at least you know if its for both iPad and phones by some kind of indicator which is a plus sign. Its great that in 4.0 that GPU acceleration, UI/UX consistency and layouts are now a priority (now that the OS is up to par) but things like locating a tablet app that is optimized for a larger screen is ridiculously hard and staff picks for tablets aren't even to be considered here. I have some ideas as to how it would be implemented but the execution is on you guys.

I love Android and in the 3wks I've been playing with the new iPad (which isn't really that new) I'm happy with the options and functions I get with Android tablets so returning the iPad soon
1. Don't give developers editor choice who aren't following the guidelines (which doesn't mean to the letter)

2. Labels next to or offset by the apps name indicating the target e.g., in the developer counsel there would be tags or a check box indicating the targeted support scope so that when its uploaded the label or indicator would be applied.

3. How about as an indicator we use Google's Color choice (I've always liked green, red, and yellow) hint* hint*

4. When searching how about a filter for device type, which could be a drop down window of sorts

5. Games like Glu tend to never close and there services stay running yet they get editors choice?
The UP and BACK descriptions in the design guidelines are very confusing and very often broken in Android in my experience. UP works consistently but definitely not BACK. I think the root of it is because BACK was overloaded with UP because there was no guidance until Honeycomb to support UP.

To me, UP navigates you through the breadcrumb trail which I think most developers understand. Email Example: Home > Inbox > Message pressing up would traverse through that backwards. No application boundaries can be crossed.

BACK in my understanding is completely different. It is used exclusively to navigate back to a previous activity shown in reverse sequence. Application boundaries are crossed all the time. Here's an example of a broken BACK button workflow:
Story: While browsing the news feed, I find this article about SOPA, I read it become outraged and click on the phone to call my congressman from the article.
Workflow: News and Weather app > Article in Web Browser > Phone, ..., hang up (I want to read other news), BACK (goes to web browser), BACK (rather than going to the News and Weather app, the browser goes to the previous webpage I read yesterday, WTF?) click BACK a few more times, eventually the browser's history is traversed and then finally sent back to the News and Weather app.

There's plenty of other cases where BACK is easily broken. Tapping a new gmail notification while doing something else comes to mind. Tapping BACK after reading the email brings you to your inbox, not back to the previous activity you were doing.

This article is also interesting to read:
How about updating the Maps API so it can play nicely with fragments please! Then this developer guide would be a little more applicable.
You guys should follow your own guidelines. Play Store Settings has static information as a Preference...

It's great to publish this, but if the "big" Google apps don't follow them, developers aren't going to either.
Actually almost every google app (gmail, youtube, maps, chrome, talk, ...) has the 'About' section within settings. And this indeed is opposite as suggested by the design guidelines. I propose to update the design guidelines. +Roman Nurik can you respond to this? Thanks.
+Craig Jennings If you jump into viewing an email from a notification, that would be a jump across tasks synthesizing a task stack for the email task. Your news task would be left alone. If you press Back from viewing the email you might end up at the inbox, and Back again from there would land you in the launcher. To return to the news app (right back where you were, with the back stack for the news task untouched) you would use Recents.

That does bring up another component I didn't mention above: tasks should be rooted at the home screen/launcher. Again, if you're looking to a browser for analogies, the behavior of jumping tasks is closest to the idea of, "open in new tab." Your old task is still waiting for you to switch back to whenever you'd like.

+Mirko Schenk +Jeremy Edwards We know that Back has been overloaded to mean a lot of different things, which is why we're establishing some stronger guidelines and conventions. The Google apps are going through the same process of adapting to them. We felt it was important to give the developer community early access to a roadmap of where we're going in this area.

As for Mark Murphy's disagreement, (shame he's not on G+, I'd love for him to join this thread,) he missed the point that the launcher is the central "hub" for all tasks - when you back out past the last activity in a task, the launcher is where you end up. I'm also curious why he's decided to throw out the phrase "security holes" seemingly for dramatic effect.

Let's walk through what would happen in the absence of the "synthesize a task stack" guideline in a few cases, as it always seems to be the most contentious element of the navigation guidelines:

You're reading an article in a news app. You get a notification for new email, pull down the shade, and tap it. Task jump. You're now in an activity viewing the text of the new mail you just received. Now press Back.

If you decide not to blow away the old task history for the email app in the process, Back takes you to wherever you were last in the email app. Maybe you were reading a different message a few hours ago - that's where you'd end up. Not so great.

If you do decide to blow away the old task history for the email app as you open the notification to avoid the confusion when you don't, then you end up with a single orphaned mail viewer activity. Pressing Back lands you at the launcher. Surprising!

Of course these two cases are straw men - the behavior that seems most natural on first glance is: "I don't care what task it launches in, Back should take me back to where I was when I tapped the notification." The problem is that while you don't care what task it launches in now, you will care several hours or days down the road when you have a bunch of tasks in a crazy state as a result and Back doesn't do anything sensible anywhere. :)

One possible approach is that a notification or widget always opens the target activity "in a new tab," or rather in its own independent task. Now you have a recipe for a giant mess in the Recents UI - after a day of normal use you have dozens of different "email" tasks, one with each mail you've viewed over time.

"Why? Just have the system clean them up as you leave!" Not showing these orphaned activities in Recents is an option, but then you'd never be able to switch back to them again later without traversing your whole history using the Back button. And in all of this, where would you end up if you simply switched to the Email task in Recents, or entered it from the launcher?

All of this has been an ongoing topic of discussion on the team for quite some time. I once trapped +Matias Duarte in a conference room for the better part of an afternoon trying to convince him of many of these same perceived issues with the synthetic back stack, but as we worked through all of the use cases and ways that other approaches fail across floor to ceiling whiteboards, he ended up convincing me instead. The strict global history approach simply leads to too many confusing results in practice, elegant as it seems to developers and tech-savvy users.

A sea of endless new free-floating micro-tasks creates a giant mess and/or no way to get back to what you were just viewing. (Plus it creates the need for a user-performed garbage collection step that should be familiar to anyone who has ever gone truly nuts with tabbed browsing.) Polluting the task you're already in isn't an option for obvious reasons.

So what we decided on in the end is replacing the current Email task with a synthetic task stack. This makes sense for a number of reasons:

You always have stable behavior of the Back button within a task. It doesn't matter if you pressed Home in the middle of something and came back to it later through Recents or the launcher shortcut, if you took a phone call, if you answered an SMS notification, etc. This kind of siloed context for history is much easier to recall than the twisty maze of jumps across the whole system. A browser doesn't jump back to the previous tab you were viewing if you click a hardware back button on your mouse just because the last thing you did was switch between tabs, it keeps you within the context of that tab you're currently in and navigates that tab's history.

The synthetic task stack for a notification link helps because memory is fuzzy. You want a predictable navigation flow for Back after following an email notification. The old context for what you were doing in the email app is no longer useful because you've completely changed your context for reading email. (And if you were composing a new email to someone at the time, a draft was saved as you navigated away anyway so you're covered.) What's left is to prevent the jarring results of Back returning directly to the launcher.

So we pretend. The synthetic back stack is an illusion of how the user could have gotten there by the most direct route.

It helps to think of notifications and widgets as macros. What the system really did is give them a shortcut to opening that email, completely analogous to pressing Recents, swiping away the current Email task to clear the current Email context, pressing Home, tapping the Email shortcut to land in the Inbox, then tapping the new mail. That's the back stack that the user is left with, they just fell asleep in the back seat and said, "wake me up when we get there." (And not surprisingly, the startActivities() API used to accomplish this under the hood reflects this view of the world.)

You're all being very helpful in letting us know where our docs are unclear or confusing on this, the discussion is much appreciated.
+Roman Nurik I've a SG2 running Official Ics and I tested the last example of tasks A & B. When I press up on compose and then back on inbox I get back to the play store instead of homescreen. Am I missing something or it's a bad implementation of behaviour by touchwiz?
+Adam Powell thanks for your explanations. I'm still digesting them, but in the meantime I have a very simple question: how do I explain this new rule in plain language to an average Android user? Imagine a usability test, the user pressing Back and seeing a screen that he/she never saw before. The user asks "why?", what do I say?

At the moment, I have no idea how to explain this in one sentence.
As a developer, I understand the task concept and how this works in ideal situations.

As a user, I have developed a pathological fear of the back button that I'm afraid "stronger guidelines" just can't fix. I've lost too many half-filled form fields (instinctively pressing back to hide the on-screen keyboard temporarily), been thrown to places I didn't expect, and experienced enough unpredictability that I will just avoid pressing the button if at all possible. That the behavior of the back button may slowly improve over time may eventually benefit new users, but for me, I'll try any other method (app switching, on-screen buttons, etc) to avoid pressing the back button.
+Sergey Povzner The non-answer is that we've found users usually don't ask that question because it doesn't feel unnatural unless you're thinking too hard about it. ;) But the one-sentence explanation is, "You went back in that app." It's highly unlikely that they'll end up at a screen that they've truly never seen before - for example usually you've seen your inbox at least once.

+Andrew Filer We feel your pain, and that's a huge component to why we've made these changes. Our goal is that as they filter down to the apps you use day to day, you'll find yourself using it naturally without even thinking about it.
+Adam Powell Thank you for reading the post and providing insight onto what's going on. The News > Email example makes sense but that just means you're in a win-lose situation, IE probably need to rethink the purpose or need of the BACK button. We need the users to always win. And make it easy for developers to help them win too. Whatever the complicated solution is in ICS it's still broken from a user and developer perspective in my opinion. I've witnessed really screwed up ICS activity stack bugs that make absolutely no sense much more often than I did in Froyo. Here's another example: Activity Stack Bug in ICS using Google Music (actually this weirdness happens in Gingerbread too)

For the clarity problem of the docs, figuring out the activity launch modes and the side effects that have when launching them based on different intent flags is probably the most confusing thing out there now. The root of the problem is the fact that both parties can influence how an activity is launched and there's low visibility on what the side effects actually are. To solve the problem, I think the docs should list a bunch of workflows that are probably desired and tell us the code of how to implement them. Then deprecate all those weird edge case launch flags from the intent class that no one should be using. The docs do a good job explaining what each flag does individually but they sound like they came out of the mouth of the person that implemented them. The problem with that is now I have to have a very deep understanding of how the activity stack works which implies leaky abstraction.

I've had to do lots of testing when setting an activity's launch mode to singleTop and I never was fully confident that my intentions were 100% expressed because someone could call the activity with some permutation of flags and put the app into a state I never intended. Like in the YouTube example.
+Jeremy Edwards The important thing to remember is that the stock Android and Google apps have a lot of known deviations from this right now and can't be used as an example of whether or not this direction is worthwhile to pursue. As I mentioned, we wanted to get these guidelines out to developers as early as possible, which meant getting them out ahead of other update/launch schedules.

When it comes right down to it, Android is a general-purpose computing platform and expressing the kinds of behavior you want in the special cases that inevitably come up needs to be possible. That leads to quite a bit of complexity at the lower levels of the API that most developers shouldn't need to concern themselves with day to day.

The activity launch modes and the plethora of Intent.FLAG_ACTIVITY_CLEAR_TASK_WHEN_FULL_MOON stuff is downright confusing to anyone who doesn't spend their days in ActivityManagerService's source code. That's part of what we're addressing with NavUtils/TaskStackBuilder (and to some extent ShareCompat) in the support library and there will be more to come beyond that.

We want to make these things simpler for everyone. Just because the system is extremely flexible under the hood doesn't mean there shouldn't be a nice layer of porcelain on top of the plumbing that helps apps implement the preferred policies. Keep letting us know what your pain points are and we'll see what we can do for you.
I absolutely love the Android Design site, but it would be great if each section could link to a sample project where the design flow that is described is implemented for all to see. Just my thoughts. Keep it up!
Will there be any visual indication when a new task is started? WebOS made this very obvious by zooming out and showing cards and then zooming in on a new one. I just used Windows Phone 7 this week and noticed that it does a small "flip" animation when you switch from the Facebook app to the browser (for example). Strictly speaking, these are a bit different from the Android workflow, but it seems like a bit of visual feedback would help explain why "back" ends up behaving the way it does.
OK, I agree consistency would be a good thing. But if I'm seeing an open mail after some days (btw., why no timeout to home screen, like Windows Mobile had?), I still don't know whether the back button will bring me to the mail list or the previous mail (if I used the "next mail" button). If you really want predictable behaviour, the back button should work exactly like the up button.

I don't like the concept of the home screen as root of all evil tasks. One of the major advantages of Android always has been the great notification system. I get notified about a new mail without interrupting me, then I open the mail, read it, and quickly return to what I was doing before. Now I need to look for the previous app in recents. Or relaunch it, which might be faster. It's even worse when there's an automated task switch, like by a call or alarm clock.

To me, it seems like you're shifting the usage of back from "history" to "close". Which would somewhat fit the Windows world (Home=Minimize, Back=Close) and would be OK if it wasn't as half heartedly. If I "close" an app, I don't like to see it in "recents" (that task is done!) and if I close a tab in my browser, I will see the previous tab. (And I wouldn't need to go through the entire browser history until the browser's finally closed...)

Currently, I don't see much improvement. If back leads me to where up or the home button will bring me, I'll rather use those, because they already do work consistently. And if I need to search for the previous task afterwards, I'd rather switch directly, even if this means there are dozens of unnecessarily saved activity states of "unfinished" tasks.
+Mirko Schenk The default behavior for the Back button in activities has pretty much always been to call Activity#finish(). (FragmentTransactions added one more step before that.) Since this leaves you at the previous activity in the task's history stack you get close+go back to the previous activity in the stack behavior.

Other differences come in when you jump through several related detail items - say several related cat videos on YouTube. Back will take you to the previous video you were viewing, Up will take you up in the app's hierarchy in one step if you don't want to hit Back through the last 30 videos you watched.

But if you've spent a bunch of time on and off within a task browsing around and you're more comfortable pressing Up than Back, go for it! That's what it's there for.

As for jumping tasks in Recents, the most recent task you were previously at is always right at the bottom of the Recents UI when you open it, putting it closest to the Recents button itself (or Home from long-pressing it if you're on a device without a Recents button) so it's still easy to jump back to the previous task.
+Adam Powell I thought that's just the current state which is about to change, so back will always bring you to the previous "page" in the app and at the last page, it will show the home screen. Maybe I misunderstood...

I think the main trouble with the back button is the mixed expectation. At first, it should have worked like the back button in a browser with just one tab. This didn't quite work, because people still are more used to the "close" concept and it's somewhat confusing after a while. So now you go for something a bit like tabs. But there's still no proper "close tab", so imho the confusion will remain.
For example, I read about a cool cat video in g+, Twitter, a mail, or the like. I open the link, then view some more cat videos. Now I want to return to wherever I came from. But I can't just close the "YouTube tab". I need to use recents or "back" through the entire history.
"Back" will still suffer from the mixed meanings: back in tab (cat video history), back to previous page (previous activity), back from tab ("close" to previous tab/app), back to parent page ("up", faked history), back to home. It also mixes with the old wish for "exit" buttons or menu entries.
IMHO, it would've been the best solution to limit the back button to "close", with sub activities as something like modal dialogs. Let "back in tab" be managed in the app (like lots of alternative browsers do), "back to parent" be done with "up", and "back to home" by the home button. And as little bonus it even fits the Activity#finish() default implementation and the majority of current apps. Seeing notifications/widgets as "macros to sub pages" still would fit this scheme, even better than if it's mixed with "history back". Though I for one would prefer to quickly get back to where I came from. Btw, what if the sub activity was invoked by another app, e.g. a link to an app in Play Store in g+? Should this bring me "back" to Play Store's start page or to g+?
+Tom Malcolmson " The guidelines now suggest that, if a setting would only be used by 20% of our users, we should consider getting rid of the setting and just forcing those 20% to use it the same way as everyone else. This surprises me - I rather thought that this is exactly what settings are for!"

Exactly! Ignoring 20% is far too much. Ignoring 2% is too much.
I've always been taught the correct way is ALWAYS to let the user decide.
Show us three real apps that implement Back and Up and navigation and tasks exactly perfectly. Then maybe we can figure out how you intend for it to work. I've read everything here and it still doen't make sense, but maybe if I saw it working it would 'click'.
My LCARS UI program does it perfectly.
Back returns to the main screen.
If the user enables it, pressing back again will exit the app.
That's how it should be
+Ed Burnette I'd just like to see just one. #facepalm As previously stated the Google apps aren't a good model against these guidelines. The support package supports some as +Adam Powell suggested but not all guidelines. I personally just design around these issues so I don't rely on the back button much. I think this thread has proved that the back button guidelines are confusing and I'd be more inclined to just remove it.
+Techni Myoko It's no big deal if users only will invoke your main activity and your sub activities are always invoked by the main activity. Pressing back in a sub activity will always bring you back to the main activity in that case.
What's this about is direct entry to sub activities, like "write new mail" from a widget or "show received message" from a notification. Unless you modify the history, back would close only the current activity, not bring you back to the mail list.
(And I still wonder what should happen if a sub activity is invoked by another app, like e.g. the share option.)

For me, a really interesting thing would be to know why the test panel users did expect to get "back" to a screen that hasn't been there before. Is it really "I invoked a sub activity of the app, so if I close it, I expect the main activity", like I think? This would fit my "back = close" paradigm, and somewhat miss the original idea of "back". If not, what else could the user think to bring him to this idea?

Btw., as a short addition to my last post's idea about removing "cat video history back": How many times do you really want to go back to previous cat videos, already read mails, or web pages of last month, and how many times do you want to get back to the previous activity/app (or alternatively the main activity)?
I think this new back implementation completely fails user expectations due to Android's intent system. To a user who is using a Twitter client, for example, and clicks a link that brings him to a browser, that user wants an easy way to get back to the Twitter client because that is the activity that he is currently in. The recents list is not intuitive for that purpose because to the user, they are in the same task - reading a list of items and clicking on ones that interest them to get detail. How do you explain to a user in that case that pressing the back button doesn't bring them "back" to the Twitter client they were working on, but brings them back to a previously browsed page, which they may not have been to in days while the phone was sitting on the coffee table?

I can see the point regarding widgets and notifications (although I disagree) but the use case of the Twitter client or news reader I think is extremely problematic for this new guideline. The most intuitive way Back should work, in my opinion, is to go back up the activity stack from the point of view that the user last used, and use up to traverse the current activity tree. Otherwise they are too similar and the back button should simply be deprecated as it really serves no useful purpose in the new guideline.

Maybe the solution is to timeout the back stack due to inactivity, or clear it when launching a new app or when at the home screen. But frankly, if it simply goes up the current task stack as opposed to the user stack across tasks, it has lost its usefulness and makes absolutely no sense.

Edit: Read the guidelines in more detail and my example above appears to be exactly what you are talking about with Intents, so no issue there. I still think that when using a notification or widget, in order to maintain a consistent user experience, those should be treated as last activities viewed rather than inserting new activities that the user never visited. I think this will add confusion to the user's experience.
Fantastic, thanks! These guidelines are getting even more detailed and I love it! Will definitely review each section as I implement features into my apps.
+Michael Salinger Check the example on the Navigation page labeled "navigating between apps to support sharing." ( near the end.) "When the user elects to share via Gmail, Gmail's compose activity is added as a continuation of Task A—no new task is created. If Gmail had its own task running in the background, it would be unaffected."

When an app uses an Intent to invoke an activity from another app to perform some action - view, edit, share, etc., that happens as part of the same task as the app that invoked it. That preserves the Back button behavior you're expecting. In the example above, pressing Back returns to the previous activity within Task A.

Intenting into activities provided by other apps is one of Android's strengths that we're not inclined to disrupt. (It's also one part of what turns navigation into a more complex problem on Android.) The synthetic task stack comes up in two cases: deep linking into another app from a system affordance like a home screen widget or notification where there isn't a "calling" task for the foreign activity to start in, and pressing the Up button while you're in an activity hosted in a task other than its native one.
Someone should tell the Google Currents team to look at these guidelines.
Wish android would make it possible for any os to work on the phone 
Especially bada and windows because they need android bad .
make android app for other os systems like windows bada and apple
it is nice that somebody listens we spend money to pay you
make an improvement widget
+Rainer Burgstaller "Lengthy discussion" is a bit over the top... ;) But you're right, I found this a bit confusing as well.
Add a comment...