http://possiblemobile.com/2013/12/investigaTing-launcher-changes/

The ability to create a new Home/Launcher application for your Android device is not a new concept.  There’s even asample application in the SDK that shows you exactly what needs to be implemented in a 3rd party application that wishes to act as the Home/Launcher of the device.  The basic recipe is as follows:

1. Provide an exported Activity in the AndroidManifest.xml that filters for an Intent withandroid.intent.action.MAIN and android.intent.category.HOME

2. Use a launch mode like singleInstance or singleTask,so multiple Home button presses get delivered to your exisTing Activity,rather than making new ones each time.

Until Now,we Could expect that the Home/Launcher application on the Android images for the Nexus devices would be the open sourced Launcher package in AOSP (Launcher,Launcher2,or Launcher3 depending on Android version).  But,when the Nexus 5 device shipped recently (and subsequently factory images for the rest of the Nexus line to get Android 4.4),all of that changed.

Suddenly,people realized that the Home application they were seeing on the Nexus 5 wasn’t the same on other Nexus devices… and it certainly wasn’t the app from AOSP.  This led those of us interested in finding out more on a bit of a goose chase to track down what Google was doing in the latest release.

The New Launcher App

The first trick is finding which application on the device is Now acTing as the Home application.

As platform developers started pouring through /sy@L_489_7@/app on the Nexus 5,(the go-to LOCATIOn for sy@L_489_7@ applications on the devicE) they discovered “GoogleHome.apk”,which seemed promising given its name.  However,a simple inspection of this application’s manifest inDicates that it only has one Activity inside,and it does not have the HOME intent filter we described above,that is necessary for Android to trigger an application as the Launcher.  In fact,the Activity looks to be a stub with little functionality included.

Someone with enough time on their hands to go through and dump the manifest files of each APK on the device would find that a file name “Velvet.apk” located in/sy@L_489_7@/priv-app (a new directory in Android 4.4 for sy@L_489_7@ applications) does in fact include an Activity in its manifest,namedcom.google.android.launcher.GEL,that filters for HOME.  A closer inspection of the other published Activity elements in this application inDicate fairly quickly that it is the official Google Search application,which is also available in Google Play.

In Android 4.4,if you have more than one Launcher application installed (e.g. a 3rd party application downloaded from Google Play in addition to the bundled Home application on the devicE),you can control which application is the default/preferred Home application (it’s not visible unless you have more than one installed Launcher application,so don’t go looking for it unless you do).

On a Nexus 5,the “Launcher” application represented by GoogleHome is visible in this list,NOT the “Google Search” application represented by Velvet,which has the HOME filter.  In addition,devices like the Nexus 4 or Nexus 7,that have BOTH Launcher2 and Velvet,never provide the option to set the new Google Search application as Home (why these devices have Launcher2 instead of Launcher3 on Android 4.4 is beyond mE).

So what gives?  How is Google bypassing this filter for their own apps and hiding it in certain situations?

If we look again at the manifest for Velvet,the GEL Activity is actually disabled by default (theandroid:enabledattribute is set to a @R_772_8487@an resource that is falsE).  That explains half of the issue; a disabled Activity will not show up in filter queries,so even with Velvet installed,and Home Activity component is not active.  Then,the question becomes “how do they turn it on?”

A Hidden trigger

A combination of the manifest entries for Velvet and some logging provides the answer,and it reveals an interesTing pattern that platform developers Could Leverage as well.  When GoogleHome.apk is installed onto a device (e.g. a Nexus 7) that has the @R_450_9531@ed Search application,the following will spit out logcat (emphasis added):

V/GelstubAppWatcher﹕ onReceive: android.intent.action.PACKAGE_ADDEDV/GelstubAppWatcher﹕ stub is enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.android.launcher3.LauncherProvider}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.android.launcher3.PreloadReceiver}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.android.launcher3.InstallShortcutReceiver}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.android.launcher3.UninstallShortcutReceiver}) enabledV/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.android.launcher3.UserInitializeReceiver}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.android.launcher3.PackageChangedReceiver}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.android.launcher3.WallpaperCropActivity}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.google.android.launcher.GelWallpaperPickerActivity}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.google.android.launcher.Market@R_450_9531@eReceiver}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.google.android.velvet.tg.SetupWizardopTinIntroactivity}) enabled

V/GelstubAppWatcher﹕ setTing GEL component (ComponenTinfo{Com.google.android.googlequicksearchBox/com.google.android.launcher.GEL}) enabled

A combination of the manifest entries for Velvet and some logging provides the answer,the following will spit out logcat (emphasis added):

BACk in the Velvet manifest,we can find a receiver element named com.google.android.googlequicksearchBox.GelstubAppWatcher that is registered for events when packages are added/removed/changed.  Therefore,we have a search application that lies in wait until GoogleHome.apk is found or installed.  When that event occurs,the GEL Activity is enabled and becomes a viable target as the Home application of the device.  If GoogleHome is then later removed,the search application disables this element again.

Okay,but then how did they get the Google Home Launcher to show up in the new Default Home SetTings?  Shouldn’t it be Google Search?

Home App Proxies

To answer this question,we take a quick detour to some of the framework changes made in Android 4.4,specifically a new manifest Meta-data constant called Meta_HOME_ALTERNATE, added for API Level 19.  As the documentation states:

Adding this Metadata to an Activity allows that application to proxy what application should be displayed as the Home application to display in Home SetTings as the option to SELEct or uninstall.  The Velvet Home Activity has this Metadata element defined…and it points to the package of Google Home.

A quick search through the AOSP sources inDicates two places in the sy@L_489_7@ SetTings application where this Metadata is observed.  Inpackages/apps/SetTings/src/com/android/setTings/applications/InstalledAppDetails.java (which is the screen where the Force Stop,Uninstall,and Disable buttons are for an application),the value is used to determine whether the current application is a Home app or the proxy of a Home app.  Apps in this category can’t be disabled,so the user can’t accidentally kill the only Launcher.

Additionally,packages/apps/SetTings/src/com/android/setTings/HomeSetTings.java (which is the new Default Home Application option) uses this element to determine if a Home application declares a proxy,and overrides the values it uses for these setTings with that package.  This is how the Google Search application shows Google Home instead as a target in SetTings.

Proxy Example

The following is an example of an application that would use this same technique to define a Launcher application but hide it until the time is right.