Tuesday, July 31, 2012

Multiple User Accounts Are Coming To Android: Miles Of Code Is Already In AOSP, And Some Of It Is Quietly Working On Devices Right Now


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 islistening. 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 interestingsounding methods named "SetCurrentUser" and "onUserChanged." These methods were found inLockPatternKeyguardView.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"

  • 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 inAndroid 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.

Monday, July 30, 2012

Apple vs Samsung: What the big fight is all about


Apple-Samsung are set for a showing in one of the most watched patent trials today in San Jose, California. The trial could decide the future of the smartphone and tablet industry as Apple has accused Samsung of slavishly copying the design of its prized iPad and iPhone.
Both sides have engaged in allegations and counter-allegations in courts across the world. A German court has already banned Samsung’s Galaxy Tab 7.7 in Europe while a UK court ruled that the Samsung Galaxy Tab 10.1 was not as a cool as the iPad and therefore not a copy. Apple was asked to publish an ad on its site stating the same.
Here’s a look at what each side is accusing the other of:
Apple’s arguments
Apple claims that Samsung has violated three of its patents: actionable linking, slide-to-unlock, and touchscreen word suggestion. If found guilty, Samsung would be forced to remove these features from its devices.
Apple also claims that Samsung ripped the ‘feel’ of the iPhone, meaning the rectangular shape with rounded corners. The Cupertino-based, giant wants more than $2.5 billion in damages from Samsung for these alleged violations.
Apple has more arsenal to back up its claims  that Samsung ripped off its designs intentionally. According to tech website, AllThingsD  it seems Apple is going to use Samsung’s own office documents to prove that Google had told them that the design was too close to the iPad.
The report states,
In February 2010, Google told Samsung that Samsung’s “P1” and “P3” tablets (Galaxy Tab and Galaxy Tab 10.1) were “too similar” to the iPad and demanded “distinguishable design vis-à-vis the iPad for the P3.”
In 2011, Samsung’s own Product Design Group noted that it is “regrettable” that the Galaxy S “looks similar” to older iPhone models.
Essentially Apple claims to be the original inventor behind the idea, the design and the features of the iPhone. Samsung in Apple’s eyes is just a rip-off and needs to be banned. US judge Lucy Koh has already granted Apple a pre-trial injunction banning the sales of Samsung Galaxy Tablets 10.1 in the US. The Galaxy Nexus smartphone has also been pulled of the shelves. There’s a very strong indication that the trial could go Apple’s way.
Apple vs Samsung today. AP
Samsung’s Argument
The South Korean tech giant is not going to give up without a fight.

Samsung has accused Apple of copying the design for the iPhone from Sony.MacWorld reports that according to internal Apple documents submitted to a California court on Wednesday, these reveal that Apple relied heavily on Samsung’s design. The documents were filed to the US District Court in San Jose by lawyers for Samsung as part of an ongoing lawsuit with Apple over patent infringement. 
Samsung has also claimed that Apple violated patents on mobile communications systems, as well as features like taking a photo on a phone and seamlessly emailing it.
The Apple-Samsung trial might look like a fight between two big, bad corporate kings who are unwilling to compromise, but the truth is that if either side gets a win, the people who will suffer the most will be consumers. If Samsung’s devices are banned, consumers can say goodbye to choice.

Saturday, July 28, 2012

Google‘s 1Gbps internet: 10 things to know

Google made its foray into the market for bundled internet and television services on Thursday, promising access speeds more than 100 times faster than those of traditional US cable and telecommunications companies.

The web search leader unveiled its ultra-high speed Google Fiber service in Kansas City, Missouri, and could start installations in September, executives said. Google hopes to roll out the service to other cities later.

Here is a look at 10 ten things you would want to know about Google Fiber:

1) Google Fiber's ultra high-speed connections and television offerings are aimed at surpassing those of current providers, allowing users to search live channels, Netflix, YouTube, recorded shows and tens of thousands of hours of on-demand programming. However, no phone service is available.

2) Google said it also intends to roll out product packages for businesses, but would not provide details.

3) Google Fiber includes more than 100 networks and costs $120 a month for a package of TV, 1Gbps internet speeds and 1Tb of cloud storage.

4) Google is also offering an internet-only package priced at $70 a month. The download speeds would be around 1Gbps, according to Google executives.

5) The package includes popular networks owned by major media companies such as Comcast Corp's NBC Universal, Discovery Communications and Viacom. Premium movie networks are available from Liberty Media's Starz for an extra fee. But it excludes several major TV names, such as News Corp's Fox cable channels; Time Warner networks like CNN, TNT and TBS, as well as Walt Disney cable channels like ESPN and Disney children networks.

6) Google is charging a $300 installation fee, saying consumers should treat it as a 'home improvement' cost.

7) The initial service area includes central Kansas City, Missouri and the entire city of neighboring Kansas City, Kansas.

8) Consumers must pay $10 to register their household online for service. About 50 'neighbors' will need to register in order for their area to be eligible for installation services, according to Google executives.

9) Google Fiber includes such features as the ability to record eight TV shows at a time and store up to 500 hours of high definition programming. Users can choose to use a tablet or smartphone as a voice-activated remote control.

10) Google is offering its Nexus 7 tablet with the Google TV app to early users of the service.

Source: Techgig

Friday, July 27, 2012

Handwriting Recognition Comes To Google Mobile Search For Smartphones And Tablets


Google just announced it is rolling out the ability to handwrite using your finger on mobile devices for search queries. The new feature, which Google warns is still in beta, works on most smartphones and tablets and is activated from within mobile search settings. After the feature has been enabled, a small “g” icon on Google search pages allows you to enable the handwriting mode, and disable to resume normal touchscreen functionality. You’ll also be provided with the necessary “Space” and backspace buttons when the mode is activated.
It’s not always easy to use the keyboard on your phone or tablet, especially when you’re on the go. Instead, try Handwrite (beta) on Google.com to write your search terms with your finger rather than typing the words on the keyboard. As you write, your handwritten text converts into words in the search box.



Enable the feature

1.Turn the feature on or off in your search settings. Touch Settings at the bottom of the Google homepage or a search results page, or visit google.com/preferences.

2.Go to the Handwrite section, select Enable to turn on the feature, and then touch Save.

Thursday, July 26, 2012

Best SEO Practices: Black Hat vs. White Hat Techniques and the Gray Hat Area

Let’s take a look at a few of the basics of white hat content: quality content, site optimization, link baiting, guest blogging, internal linking, and semantic markup. The differences between white, gray and black hat marketing efforts are described to perfection in the form of a clever picture titled SEO Wars: What Color is Your Lightsaber.







The definitions of gray and black hat seo practices are also made more clear by this picture. The gray hat area of SEO techniques include: spinning/rewriting articles, reciprocal links, buying old/expired domains, and Google bombing/washing. Black hat techniques include: keyword stuffing, link farms, hidden text, cloaking, scraping, doorway pages, comment spam, and paid links/content+.
Keep in mind that both gray hat and black hat areas will hurt you in the long run, according to Ali Husayni, the CEO of the SEO service company, Master Google. Heed the warning of Google’s anti-spam strategy: they can distinguish between black hat and white hat SEO techniques, and your rank will rise and fall accordingly.
“The only thing not changing with SEO is that it’s always changing,” Husayni says. “Be diligent in keeping up with those changes as [you handle your] site’s SEO, or partner with a qualified SEO provider to handle that task.”
After all, the battle lines between white hat, gray hat, and black hat techniques are drawn quite clearly, so pick an SEO practice and stick with it, urges Schottmuller, using Star Wars as an analogy.
“Will you uphold the righteous values of quality content and serve as a SEO Light Jedi, or do you long to be a master of deception as a SEO Sith Lord?” Schottmuller says. “Perhaps you’re a SEO Dark Jedi – once believing in white hat tactics and now thirsting for the dark side. Or perhaps you’re a SEO Jedi Fashionista – knowledgeable of both sides, but discreet in practices to keep up appearances.”

Wednesday, July 25, 2012

How does a search engine fetch answers to your queries in less than second?

Ever wondered how does a search engine fetch answers to your queries in less than second? Google says it's a mixture of science, creativity, experimentation and cold, hard maths. This is how it works: