30
Jul
Android1
Last Updated: October 8th, 2012

Multi-user support is one of the few remaining things a desktop OS can do that Android can't. The "coffee table tablet" use case would greatly benefit from a multi-user setup, as would an enterprise user who wants to keep work and home separate. It's been a top 20 item on the Android bug tracker since the debut of Honeycomb, so there is certainly demand for it.

As we've seen from my previous experiments in sticking my nose where it doesn't belong, Google likes to leave breadcrumbs in shipping products for the astute observer to find, and the multi-user situation is no different. After a bit of research, I can tell you that Google is listening. There is a surprising amount of multi-user work being done on Android - some of it is even working on devices right now.

Before we jump into things, we're going to need to learn some vocabulary. "AOSP" is Android Open Source Project, you should know that one. It's the publicly available code base for Android.  A "commit" is a code push to this code repository. You're supposed to include a helpful comment with your commit, telling people what the new code is supposed to accomplish. This is Android code, so the commit comments are written by Googlers. In other words: they're accurate.

Now, on to the evidence:

The First Clue

2012-07-27 21.22.002012-07-27 21.22.06

You can't see it, but there is multi user support in there somewhere.

I was originally clued into the idea of multi-user code already existing by Abhisek Devkota, aka "ciwrl," CyanogenMod's Head Moderator. The guys at CM had stumbled upon some interesting sounding methods named "SetCurrentUser" and "onUserChanged." These methods were found in LockPatternKeyguardView.java, a file for Android's pattern unlock. Here's the whole section:

public void onUserChanged(int userId) {
               mLockPatternUtils.setCurrentUser(userId);
               updateScreen(getInitialMode(), true);
}

I'm no expert, but this looks pretty straightforward: when the user changes, switch the lock screen over to the new user's lock screen, and redraw the screen so the user can see these changes. It sounds like pattern unlock is listening for a user switch!

There's way more to this than just that one section. Ciwrl also pointed out a few commits to me, and if you start digging through the public AOSP repository, you'll start noticing tons of work related to multi-user functionality. After a bit of work, I've been able to piece together a decent timeline of multi-user upgrades to the AOSP code base.

The Timeline Of Commits

Please note that, just because something is mentioned, doesn't mean it is 100% working, or even working at all. And, just like any big change to Android, the biggest problem is ecosystem support: you have to implement this without breaking everything else. So consider this to be merely a peak at what has been worked on, and nothing more.

Direct quotes of commit comments are in bold, and my attempt at translations are in regular text:

April 14th, 2011 - "Plumbing in PackageManager and installd for multi-user support."

By Amith Yamasani, A Google Engineer

  • Create /data/user directory and symlink /data/user/0 -> /data/data for backward compatibility - A big part of switching to a multi-user OS will be moving all of the global settings, files, and apps from wherever they are now, to a users/[username] directory, while remaining backwards compatible and not breaking anything. Luckily, Android is built on Linux, which supports all sorts of handy file system tricks, like a "symlink." A symlink allows you to move a directory, but leave behind a pointer for anything that goes looking in the old location. Here, they moved the /data/data directory to /data/user/0, and made a symlink, so anything looking in /data/data will know to look in /data/user/0. In theory, nothing will break. In theory.
  • Create data directories for all packages for new user - "Package" is just technical speak for "app." When a new user is created, the system will now make them their own copies of app data for every currently installed app.
  • Remove data directories when removing a user - Then you'll want to delete all that data if the user is removed.
  • Create data directories for all users when a package is created - Now, when you install Angry Birds, everyone gets a separate save file.
  • Clear / Remove data for multiple users - I assume this is talking about the "clear data" button in app info, and the uninstall procedure. This brings up a good example of how complicated this can be. What happens to User 1's data when User 2 hits clear data?
  • pm commands for createUser and removeUser (will be disabled later)

May 4th, 2011 - "Multi-user - 1st major checkin"

By Amith Yamasani

  • Switching activity stacks - In other words, change the running apps when a user switch happens. The back button stack would change, the recent apps would change, etc.
  • Cache ContentProvider per user - Content providers share data between multiple applications. Anything that is shared will use a Content Provider, so, for instance, Contacts and Calendar info. These are per-user now.
  • Long-press power to switch users (on phone) - User Interface?! I wish I could find this somewhere, but I can't. Maybe this wasn't UI, and was just a dirty testing hack.
  • Added ServiceMap for separating services by user - A new part of Activity Manager for handling background services on a per-user basis.
  • Launch PendingIntents on the correct user's uid
  • Commands added to pm and am to allow creating and switching profiles. - "pm" stands for "PackageManger," which deals with information about installed applications. "am" stands for "ActivityManager." An activity is basically the any piece of UI in Android - usually full screen windows. Basically, this is Android's first lesson on how to deal with multiple users. You'll need to create separate user profiles, with different apps settings, and different sets of running apps.

March 13th, 2012 - "Package restrictions per user"

By Amith Yamasani

  • Packages can be enabled/disabled per user. This requires maintaining stopped/launched states and enabled / disabled components and packages per user. - Well, there you go, per-user app disabling.
  • Refactored pm.Settings and PackageSettingsBase to keep track of states per user. - Similar to the above, per user Package Manager settings.
  • Migrated the stopped-packages.xml to users/<u>/package-restrictions.xml  - More global settings being moved to per-user settings.
  • Changed intent resolution to handle individual user restrictions.  - A good example of intent resolution is the app picker box that pops up when more than one application can be used for an action. It matches the intent (like "I want to open a web page") with the programs that can handle it. So if 1 user prefers Chrome and another user prefers the stock browser, it can do that.
  • Bunch of IPackageManager calls now have a userId argument.

March 22nd, 2012 - "User management and switching"

By Amith Yamasani

  • Broadcast intents that get sent out when users are added/removed/switched. - When a user switch happens, you're going to need to run around to everything on the system and let it know about it.  
  • More work on generating user-specific information in package manager queries.
    • APIs to update user name and query a user by id.
    • Removed Package.mSetStopped and mSetEnabled, since they're not user specific.  - You can now ask Package Manager about installed apps for individual users.
  • User removal:
    • Cleanup ActivityManager, PackageManager, WallpaperManager, AppWidgetService
        and AccountManager.
    • Shutdown processes belonging to the user. - When a user is deleted, you're going to want to wipe out all of their settings and kill all their apps.
  • Lock the screen when switching users, to force unlocking. - Sounds like you would pick a user, then get the unlock screen, which would make sense and be secure.

March 28th, 2012 - "Lockscreen settings per user"

By Amith Yamasani

  • Move all lockscreen related settings to LockSettingsService.
    • LockPatternUtils uses this through IPC instead of Secure settings.
    • Migrate old settings to new database managed by LockSettingsService. - It sounds like the lock screen is the primary interface for user switching, so it needed a rewrite.
  • Passwords and patterns are stored in a new per-user location, except for the primary user, for backward compatibility. - Like I said, doing this without breaking everything is going to be a challenge, so it looks like, initially, not all users will be equal as far as the system is concerned, for compatibility reasons. That doesn't necessarily mean end users will see the difference.
  • KeyguardViewMediator and LockPatternKeyguardView listen for changes to user and updates the lockscreen. - This is referencing the code I showed, above. Pattern unlock is listening for a user switch! Currently the user switch never happens, but it's ready for it.
  • Settings provider will look for Lock settings in the LockSettings service now for the entries that used to be stored in Settings.  - Ah, so the lock screen settings used to be stored with all the other settings, but they have been spun off into their own file. This is another security measure. It sounds like, before, you would need to load the entire settings file to get the lock screen settings. Now you load as little as possible until the lock screen can verify the user.

So How Much Of This Actually Works?

Of course, the question arises when reading those comments, how much of this is actually in Android right now? All of those commit dates are pre-Jelly Bean, and some are pre-Ice Cream Sandwich, so some of this stuff must be live, right?

One of the more interesting and new-ish Android files is called "UserManager.java." It references a "userlist.xml" file in /data/system/users, so that sounds like a good place to start. Here it is in Jelly Bean:

wm_2012-07-26 17.46.50wm_2012-07-26 17.47.13

Oh my. You're telling me this works right now?!

That is a live, working, multi-user directory structure. A single-user OS would just store everything under /data/system, but the fact that this is already storing things in a "user" folder is just phenomenal progress. There are settings for app widgets I have on my home screen, apps I have installed and disabled, and my wallpaper settings. It's been right under our noses this whole time: Jelly Bean is a multi-user OS, with only 1 user. I am User 0.

Let's take a closer look at some of these files:wm_2012-07-26 17.48.06

wm_2012-07-26 17.46.58wm_2012-07-26 17.47.04

As we can see in the "<users>" section of "userlist.xml," there is only 1 user, User 0. A quick look at users/0/appwidgets.xml confirms that user is me, because those are the widgets on my home screen. It's interesting that app widgets are here, but there's no mention of the actual app shortcuts.

"0.xml" will probably, one day, house things like my name and my profile picture, but for right now, my name is just "Primary." If you recall, we've heard of "Primary" before in the March 28th, 2012 commit: "Passwords and patterns are stored in a new per-user location, except for the primary user, for backward compatibility." Primary is the least exotic and most backwards compatible user.

"Accounts.db" is an SQLite database. It contains the accounts listed under the "Accounts" section of settings, in my case, Google and Dropbox. It also contains the full list of every Google service I've ever used, my preferred language, and my authtokens. So it looks like accounts and syncing is on a per-user basis now, too.

wm_2012-07-28 23.53.25

Package-restrictions.xml has a seemly complete list of apps on my phone, and their enabled/disabled status. Toward the middle you can see "com.google.android.email enabled=3" which means I've gone to app info and hit the disabled button for it. So, as we saw in the commits, each user can enable/disable the apps of their choosing.

In the April 14th 2011 update, we saw a switch from /data/data to /data/user/0, so let's check that out on Jelly Bean:

2012-07-28 20.57.332012-07-28 20.57.392012-07-28 20.57.452012-07-28 20.57.482012-07-28 20.57.552012-07-28 20.57.592012-07-28 20.58.042012-07-28 20.58.082012-07-28 20.58.142012-07-28 20.58.21

Wow. The magic of Linux. Thanks to the symlink, the majority of apps are now storing their data in a user directory, instead of dumping them in a global directory. There's almost 100 directories in here. I was concerned about 3rd party app support, but it looks like most app is ready for more users.

Conclusion

So, in my very-much-non-expert-opinion, it looks like the following things are separated for multiple users: lock screens, installed applications, running applications, application data, default applications, home screen widgets, accounts, syncing, and language.

And the following things still need to be worked on: Namely, every piece of UI. You need a user switching screen, an entire settings section for managing users, setting permissions, taking or picking user avatars, names, etc. You'll also need a way to know what user is currently logged in. There also doesn't appear to be separate settings for home screen shortcuts, and probably a million other settings. And who knows how 3rd party apps would really deal with a massive change like this. Lots of testing needs to happen.

The first commit was over a year ago, and the last one we know about was 4 months ago. A lot of work has already gone into multiple user account support, but I'm sure there's still a lot more work to be done. Keep plugging away Googlers! I'll be watching...

Ron Amadeo
Ron loves everything related to technology, design, and Google. He always wants to talk about "the big picture" and what's next for Android, and he's not afraid to get knee-deep in an APK for some details. Expect a good eye for detail, lots of research, and some lamenting about how something isn't designed well enough.
  • Nicolas Klein

    This explains why on a Jelly Bean phone the sdcard folder is /mnt/sdcard0/ instead of /mnt/sdcard/ !!!

    We will have different sdcard folder for each user too !

    • Abhijeet Mishra

      I see it as sdcard on my Galaxy Nexus, running Jelly Bean. Never saw it being sdcard0 tbh.. :)
      That sdcard0 might be internal, with the external storage being called sdcard1, though not likely..

      • derekross

        I believe it's a symlink. /storage/sdcard0 exists.

      • EH101

        If you have titanium backup go into the settings in titanium and view the save location for backups.

        You'll likely see sdcard0/titaniumbackup as the directory. This caused me a few headaches when I jumped to jelly bean.

    • http://www.facebook.com/profile.php?id=1653571802 Debadatta Bose

      That means, if the sdcard is encrypted by user0 (suppose), other users can never open it?

    • tony

      No, that's just how the developer/manufacturer of your JB rom decided to represent the mounted folder. It could be named anything, including /mnt/flying_donkeys.

      • http://code.google.com/p/lg-v909 Aaron Echols

        Actually, NO, the fuse binary requires /mnt/sdcard0 going forward, from JB and beyond.

    • Marvin (FatherStorm) Francois

      no. that's to enumerate the mounted storage devices, in this case sdcard.. it's theoretically possible to have a device with multiple sd cards, and they would mount as /mnt/sdcard0 /mnt/sdcard1 /mnt/sdcard2 &etc.. additionally, if you wanted to you could repartition a sdcard, and mount each partition seperately. you can check out how to mount here:
      http://www.tuxfiles.org/linuxhelp/mounting.html

      • digi_owl

        Except that since 3.2, stock Android SD access is messed up. And Google seems to not be interested in removable storage, as their last couple of devices to not feature such a slot.

    • http://code.google.com/p/lg-v909 Aaron Echols

      No, this is how Google wants to implement multiple SDCARD's going forward. SDCARD is shared storage.

  • John

    Awesome write up. One thing, who the hell would actually utilize that?

    • http://profiles.google.com/tim.glaser Tim Glaser

      This would be very useful for tablets, especially ones used by families. There can be a user for the 8 year old, and one for dad. Dad's home page doesn't have to be messed with by the kids, dad's work email isn't there for just anyone to use.

    • RedPandaAlex

      Anyone with a tablet and more than one person in their home

    • derekross

      Everyone with a family...

    • wolfkabal

      Families with shared a shared tablet perhaps?

    • John

      Ah. So I was completely thinking the wrong direction on this. I stand corrected. Everyone would ;)

    • http://www.androidpolice.com/ Artem Russakovskii

      Here's another use case - I have a Galaxy Nexus reserved for foreign travel, and right now my wife went to Europe with it. Because of that, I had to wipe and sign her in, whereas with user accounts she'd just sign in and voila - all her accounts and none of mine.

    • Simon Belmont

      Have house guests? Have a tablet?

      This would be great to allow them Internet/E-mail access without access to your apps and settings. Seems like a great idea.

  • http://twitter.com/LinkofHyrule89 Matthew

    This will be nice for Tablets I really don't see a major use for this on Phones except for maybe when kids want to play with dad's phone. I wish Chrome Mobile had User Switching already.

    • RajivSK

      I'd actually really like to have a guest account on my phone with just some permissions like wifi and some apps. I always saw it like this, either you swipe the pattern or just swipe away the screen and be in guest mode. Ideal when you just want to play some music or read some feeds. No need to secure that with a pattern or password.

      • digi_owl

        Could also have separate private and work accounts.

  • RedPandaAlex

    In Android 5, Google is going to have to worry about competing with Windows 8 tablets. To me, there are two big features that Windows 8 has over Android 4.1. One is multiple users. The other is docked sidebar apps. I'm hoping they both come in Android 5 this winter. Seems like they're already working on multiple users, and docked sidebar apps shouldn't be too difficult to implement--just put the phone view of an app in a sidebar on the tablet.

    Of course, it'd be nice if they competed with new hardware, like a Nexus 10, too.

    • thistimearound

      I'd check out the Nexus 7 first if you think they're not competing in hardware. It's a beast tablet and has radically changed many people's opinions (including my own) on the feasibility of a 7" tablet.

      • RedPandaAlex

        I'm sure it is, but it doesn't compete directly with the Surface MS announced, which is 10.6 inches. Some people want a smaller tablet, some want a larger tablet. I don't see why Google would cede any ground to them by not putting out a compelling larger tablet against the Surface.

        • http://twitter.com/samcobra Samcobra

          Because Google can indirectly compete through its OEMs who will undoubtedly also make 10inch implementations of Jelly Bean tablets and hopefully will benefit from the entire ecosystem being buoyed by the Nexus 7. However, the issue of developer support for a 10-inch layout still remains.

          • RedPandaAlex

            True, but if they're going to launch a new version of Android in the 4th quarter, which I think they will, and it has good new tablet features, they should make sure there's a 10" Android tablet on the market with the new version of Android, nexus or not. Maybe they'll be able to do that with their new program where OEMs get pre-release versions of Android.

        • thistimearound

          Don't misunderstand, Google is probably eyeing a 10" very seriously with the recent success of the Nexus 7. But my point is that people don't know what they want. I've had several 10" tablets, including an HP Touchpad and iOS. The OS makes a difference, for sure, but the form factor and portability of a 7" is killer. They are directly competing in the market by offering a superior product that everyone else has written off.

          Make no mistake, Apple and Microsoft have adjusted their plans and will be seriously discussing a 7". Many people may say they want different sized tablets, but I'd be shocked if there's a large portion that want a 10" after having spent some time with the Nexus 7. It is, in every shape and form, a killer. A Kindle killer, a Soundhound/Shazzam killer, and a Siri killer. Microsoft, Apple, Amazon, etc. will continue to survive, despite this, but they will adjust their game. I promise you. Direct competition does not have to come from equal form size.

          • RedPandaAlex

            Ok, but let me ask you this. It's a genuine question since i don't have a 7-inch tablet. Do you find yourself using it for productivity as effectively as 10-inch devices? Things like document editing, with a Bluetooth keyboard and without, note taking, web research, sketching designs, and remote log in? My intuition is that Microsoft is going to have a lead with customers who care about those things with a larger flagship device.

          • thistimearound

            Legit question, and I can't really answer it at the moment. On my 10" tablets I did all of the above. Right now I'm applying for medical school, so I need a real computer anyway. I've done some web research on my Nexus 7" and kept important files synced, but mostly been using it for reading. Reading books, articles, and magazines is perfect on a 7", imo.

            Sketching, note taking, remote login? Haven't had a need/had time to do those yet. And you may be right. I don't see why form factor or screen size would matter for most of those actions, but then I said the same thing about gaming and reading on a 7".

    • Google_Soldier

      I just think Mathias Duarte should redesign the tablet UI on android as he did with the phone UI

      • Ravrahn

        Matias created the tablet UI. He had major influence in Honeycomb.

        • RedPandaAlex

          And really, ICS and JB have just been refinements of Honeycomb.

          • Ravrahn

            In the sense that every version of Android has been a refinement of the previous version, yes. ICS actually had heaps of new APIs, even coming from Honeycomb.

        • John

          I doibt that Matias had any influence whatsoever on HoneyComb. He joined Google barely a month or so before HC was released. He most certainly influenced ICS and JB.

          • http://codytoombs.wordpress.com/ Cody Toombs

            Sorry, he was there much sooner.

            May 27, 2010 article confirming he's joining the Android team: http://www.engadget.com/2010/05/27/palms-matias-duarte-has-joined-google-as-user-experience-direct/

            Honeycomb was released in Feb, 2011. Given that there had to be a couple of months involved in prep and release, that still gives between 5 and 6 months worth of influence by Matias.

            There's also several interviews out there where he talks about stepping through the doors and almost instantly re-crafting the design. I have a sneaking suspicion that he was working on redesigning Android before he left Palm, even if it was just on his own time (don't forget, he worked with Andy Rubin for several years prior to this). I know from my own experience, 6 months is a really long time if you step in and have the power to really make changes and people are on your side.

      • Z750

        I like the tablet UI, It's simple yet it stays out of the way. Is there room for improvement? Always! But, as a whole, I like the way Android does its tablet interface.

    • Ravrahn

      Doubt Android 5 will be Q4 2012. It seems like Jelly Bean was meant to have mutliple users, but they ran out of time, so it'll probably arrive in 4.2, not 5. I'm guessing 5 will be at I/O 2013, and there has to be something really big to merit a jump to 5, which I'm hoping will be desktop support.

      • Simon Belmont

        I tend to agree. I think the next version of Android will be another minor version bump like Jelly Bean was, probably launched alongside the new Nexus (Nexii?) phone(s) in late 2012.

        Google would be smart to do that too because it will make the transition from ICS or JB to the next version easier since it won't be like a GB to ICS jump again. Give OEMs time to catch up.

  • http://profiles.google.com/ah.ejazz Ahmad Ejaz

    Pretty interesting read and good ground work.. hope to see it in next iteration of Android

  • http://twitter.com/MrYuzhai *Certified_geek™

    i was just thinking about this last night..! if it can happen i'll gladly buy another tablet and leave it on the coffee table for all (meaning family) to use!

  • http://www.facebook.com/kam.w.siu Kam Siu

    Great move google. i think many people will love this. Sharing is caring! (and less $$)

  • Randy

    I don't think tablets are where this will really shine. Tablets are still rather personal devices, and the prices aren't so prohibitive that each member of a family wouldn't have their own.

    Now the television in the living room with Google TV? That's the ideal place for this.

    • RedPandaAlex

      I think tablets are only really personal devices because multiple users isn't an option. I use my girlfriend's chromebook all the time because all I need to do is sign in with my Google account and all my bookmarks, saved passwords, etc are right there. I'd love it if it was as easy for her to jump on my Xoom.
      I hear you on the Google TV thing though. We just got one last week and are trying to figure out how to manage that.

      • http://www.facebook.com/dgemus Don Gemus

        IF Android can work like chromebooks, that would be awesome

    • http://www.androidpolice.com/ Artem Russakovskii

      But why have multiple tablets if you can have one and with a touch of a button have it become "yours"? Right now I don't want a pile of tablets in the living room, and I also don't want to have my wife's emails on my tablet, just like she doesn't want mine on hers. User accounts kind of solve this, at least partially. Ideally, both users would still be able to run and we'd have a nice dashboard of what's going on with notifications in each, rather than signing everyone but one user out, but I'd settle for anything at this point.

      • Randy

        I'm not claiming it won't be useful on tablets - certainly it will.

        However, I think all the features of a tablet - it's small size, the fact that it is handheld, that for many people it is their e-reader, and then the relatively inexpensive price of the 7-inch tablets - make it a very personal device. In other words, it's likely that each person will own their own.

        It's like the phone; 20 years ago when everyone had land-lines it seemed ridiculous that each family member would own their own phone. Today? Not so much.

        There is no denying that multi-users will be a welcome addition on all form factors, but of those currently in the market I think none will benefit from this as much as TV.

      • squiddy20

        While I see your point, what if Mom, Dad, and little Jimmy all wanted the Android powered tablet at the same time for doing different things? Two of them would have to wait their turn while the other finishes whatever he/she is doing. You run into the same problem like with the 1 TV vs Multiple TVs in the same house, but on a "higher" scale because you can actually DO things on a tablet.

    • Simon Belmont

      I dunno. I know a few family friends that let their kids share a tablet.

      Having separate accounts where they can each customize everything to their liking would be fantastic for them. Just saying.

  • John

    I wonder how they'll handle the memory/storage required for apps, files, etc belonging to multiple users. Partition the SD card and move all apps to it maybe? That would be a problem for the Nexus 7 and other tablets without an SD card reader.

    • http://twitter.com/havens1515 Randroid

      I was wondering the same thing the whole time I was reading this. As it is now, it kinda seems like it would be better used on a desktop rather than a tablet or phone. Otherwise, phones and tablets are likely going to need more RAM to handle multiple users.

  • http://twitter.com/LH Luke Hutchison

    That looks like a horrifically leaky way to handle per-user security, by building per-user support into each piece of the framework, as opposed to relying on system user separation, and just completely shutting down and restarting the UI (and appropriate system services) on user switch. I guarantee there will be lingering cross-user security bugs to deal with for years to come.

  • http://musingmarc.blogspot.com IDisposable

    Multiple user accounts have been available for the HTC Flyer since February http://forum.xda-developers.com/showthread.php?t=1478322&highlight=switch

    • Max Barlow

      Not the same thing... that app creates a whole new section to be booted into and can only be switched via that app and rebooting. This implementation would mean that you could switch the user while on the phone/tablet seamlessly and would take account of everything on the phone (And just fyi that app is available to the majority of android phones/tablets)

      • http://musingmarc.blogspot.com IDisposable

        Agreed, it is NOT the same thing... but much of the same effect is there, showing the way toward a BETTER solution :)

        • Tyler

          Might as well do it right if you going to do it at all. Also i would clasify it as better seeing as you wouldnt want to reboot phone and lose(such as spot in open app) data on user1 when user2 wants to use the tablet.

  • Kenny O

    How would multiple user accounts impact memory in terms of storage......would it be noticeable?

    • http://code.google.com/p/lg-v909 Aaron Echols

      Depends on the user. If a user installs more apps, and stores more local data, then yes. I'd expect to see tablets and phones with more internals storage going forward.

  • http://twitter.com/ToysSamurai Toys Samurai

    I wish this will be released along with a way to backup app data per user. The current way (or the lackof) just doesn't work -- almost no developers are saving data to Google's cloud.

  • Luis Coelho

    I'm using switchme on My tablet, só i can easily share it with my wife só i guess there is demand

    https://play.google.com/store/apps/details?id=fahrbot.apps.switchme

  • Carlos

    there was a cm10 kang that had it for the nexus 7 a couple weeks ago. It was awesome for when my daughter wanted to play with it. Unfortunately, out of my stupidity, i updated the rom without backing up and the feature was taken out. If only i can find that download again! :(

  • http://code.google.com/p/lg-v909 Aaron Echols

    [QUOTE]In the April 14th 2011 update, we saw a switch from /data/data to /data/user/0, so let's check that out on Jelly Bean: ... Wow. The magic of Linux. Thanks to the symlink, 100% of apps are now storing their data in a user directory, instead of dumping them in a global directory. There's almost 100 directories in here. I was concerned about 3rd party app support, but it looks like every app is ready for more users.[/QUOTE]

    This is incorrect. It's still storing data in /data/data, and /data/user/0 is actually symlinked -> /data/data.

    • ericl5112

      Looks like you're right. However, that could just be there to prevent apps from saving to /data/user/0 for now.

      • http://code.google.com/p/lg-v909 Aaron Echols

        That is exactly why it is setup this way.

    • http://twitter.com/havens1515 Randroid

      He basically said that:
      "Thanks to the symlink,"...

      I this the rest was to simplify it for people who don't understand Linux and what symlink does.

      • http://code.google.com/p/lg-v909 Aaron Echols

        No he didn't, he stated data was now stored in the user dir, which it isn't. It's stored in /data/data with a symlink in /data/user/0 -> /data/data. So the data ISN'T stored in the user dir.

  • ericl5112

    "Thanks to the symlink, 100% of apps are now storing their data in a user directory, instead of dumping them in a global directory"

    Minor correction. Every app that is following guidelines and storing data in /data/data/packagename/* will store in /data/user0/packagename/* it looks like. they did a great job making that transparent, I've been writing apps that do tons of data transfer and didn't even realize.

    That said, there are still devs that store saves and data to /sdcard/somefoldername/*. Those may have issues, depending on how google handles this. Google puts out guidelines, and google will probably be blamed if those apps don't work, but it's the devs own fault.

    • Ron Amadeo

      Yeah my wording was probably a little too absolute. I changed it to "the majority of apps". Thanks.

    • http://profiles.google.com/fahadayaz Fahad Ayaz

      UnlessI the symlink also changes when the user changes. So /data/data always points to the current user. That way, current apps can continue to function as they would without adverse affects.

  • ericl5112

    I'm interested in how google will go forward with this. As far as I know, there is no logic in symlinks. You can't say:

    if(userID==0){
    //save to /data/user0
    } elseif(userID==1){
    //save to /data/user1
    } etc...

  • Simon Belmont

    This is pretty cool. Very nice write-up, Ron, as usual.

    I could see myself using this for a "guest account" on my tablet if someone visiting just needed basic access to Internet and email and I didn't want them mucking around with my settings, etc. It would be great if you could set security levels so you could prevent "guests" from installing apps or changing settings in "their" account, so its just there for the aforementioned email and internet access.

  • http://profiles.google.com/fahadayaz Fahad Ayaz

    Ah! So that's why they put my name on the lock screen on my Nexus 7! :)

    http://db.tt/XVbAyJvT

  • Deepak Giri

    Amazing! Can this thing be patented? :->

  • Guest

    Oh good. Then we will only have to buy 1 device... instead of 2-3.
    Just want a company that MAKES and SELLS devices, would want.

  • bleep

    Maybe, in three years.

  • surethom

    Fantastic news, Android could do with revealing what they are upto before Windows 8 Tablets are released, to let users no that they now have a choice ot Tablets Android or Windows 8 for multiusers.

  • http://www.facebook.com/gapimentel German Alonso Pimentel Vera

    Nice, better get this legal before Cupertinmo strikes again

  • Cory M

    Hope Google patented this "development" as a method for multiple user profiles on mobile OS.....oh and make it as broad as possible.

    • Tyler

      As pathetic as that idea sounds, they probably will have to stoop down to that level in order to keep other companies from using that design philosophy.

  • karenbrown2012

    Pretty interesting read and good ground work.. hope to see it in next iteration of Android @google-d0edf217ecc791710e8fa56e4a11b7ef:disqus, i figured out that it was possible to make some income working from your home... Check here to see how i done it... http://neilstips.blogspot.com

  • http://twitter.com/havens1515 Randroid

    This will probably be something that is in Android 5.0, whether that be the next iteration or not. I see multiple user support as a good reason to jump up a major version number. Once that's built-in, you're pretty much ready for desktop support.

  • genialmaniac

    when google listen to his customers, it gives nice new functionalities

  • Yuku Sugianto

    When I upgrade my phone to Jelly Bean, I noticed that the linux user names of the app data have changed:

    drwxr-x--x u0_a278 u0_a278 2012-07-12 15:36 yuku.alkitab

    drwxr-x--x u0_a279 u0_a279 2012-07-12 15:36 yuku.alkitab.kjv

    drwxr-x--x u0_a270 u0_a270 2012-07-23 00:32 yuku.backupfiletime

    drwxr-x--x u0_a280 u0_a280 2012-07-12 15:37 yuku.callcentre

    drwxr-x--x u0_a281 u0_a281 2012-07-12 15:37 yuku.esvsbasal

    drwxr-x--x u0_a283 u0_a283 2012-07-12 15:37 yuku.imagecompacter

    drwxr-x--x u0_a284 u0_a284 2012-07-12 15:37 yuku.infinitepassgen.app

    Previously, all u0_a... was just app_.... Like u0_a278 was previously app_278. Presumably the u0 is the user 0, and the new users will be u1, etc.

  • Brandon Cameron

    This feature is already on some of the custom Jelly Bean roms floating around. AOKP and the CM10 previews for example has this feature and it works.

  • Michael Norelli
Quantcast