Applications distributed via system image are usually updated with a new firmware update but this is more often than not an overhead for the application developers as their update is bottlenecked by device OEM's firmware update schedule and for OEMs who have to factor in extra cycles just to work with independent developers. This was the case with Dolby's services available in Kindle devices. The service was in-built into the system image and applications had to use a thin client jar to talk to the service similar to Google's Play services. The only problem was that any bug fix in the service had to come through a firmware update from Amazon unlike Play services (updated via Play store).
So why would anyone go this route? Why not let the users install the applications from the market? Well, this is a good revenue source for mobile carriers and device OEMs as they promise instant visibility of the application to independent developers. Likewise, its a good sell for the device like LG's G2 distributed by Att having Beats Music and Twitter preinstalled.
Anyways, this being a reality application developers still have to deal with updates and this is where Google's play store comes to the rescue. In fact, this is how Twitter and other preinstalled apps are updated in G2. But what exactly happens behind the screens? How is the device able to restore the original factory version of the application? Is Play store loaded with multiple versions?
Well, G2 had the preinstalled version in the read only system partition so any updates from play store or otherwise can't really update this apk (/system/app/Twitter.apk). Turns out that any updates from the Play store causes it to be installed in the data partition (/data/app/com.twitter.android-1.apk). This had the package name com.twitter.android same as the one preinstalled in the system. So how does Package Manager deal with multiple apks having the same package name? The entire assumption was the that the package name had to be unique. Well, Package Manager has a specific logic to detect this scenario and updates the code and resource path.
PackageManager: Code path for pkg : com.twitter.android changing from /system/app/Twitter.apk to /data/app/com.twitter.android-1.apk
PackageManager: Resource path for pkg : com.twitter.android changing from /system/app/Twitter.apk to /data/app/com.twitter.android-1.apk
This original preinstalled version is what is being referred to as a factory version and is being used when the user uninstalls all updates of the application.
So why would anyone go this route? Why not let the users install the applications from the market? Well, this is a good revenue source for mobile carriers and device OEMs as they promise instant visibility of the application to independent developers. Likewise, its a good sell for the device like LG's G2 distributed by Att having Beats Music and Twitter preinstalled.
Anyways, this being a reality application developers still have to deal with updates and this is where Google's play store comes to the rescue. In fact, this is how Twitter and other preinstalled apps are updated in G2. But what exactly happens behind the screens? How is the device able to restore the original factory version of the application? Is Play store loaded with multiple versions?
Well, G2 had the preinstalled version in the read only system partition so any updates from play store or otherwise can't really update this apk (/system/app/Twitter.apk). Turns out that any updates from the Play store causes it to be installed in the data partition (/data/app/com.twitter.android-1.apk). This had the package name com.twitter.android same as the one preinstalled in the system. So how does Package Manager deal with multiple apks having the same package name? The entire assumption was the that the package name had to be unique. Well, Package Manager has a specific logic to detect this scenario and updates the code and resource path.
PackageManager: Code path for pkg : com.twitter.android changing from /system/app/Twitter.apk to /data/app/com.twitter.android-1.apk
PackageManager: Resource path for pkg : com.twitter.android changing from /system/app/Twitter.apk to /data/app/com.twitter.android-1.apk
This original preinstalled version is what is being referred to as a factory version and is being used when the user uninstalls all updates of the application.
2 comments:
Do you have advice on how you would share the app's private data between the factory version and the updated version of the app? So that the update process appears smooth between the two versions. I'm assuming you can't access the "/data/app/com.twitter.android" folder that the previous (factory) version used?
I'm assuming you meant /system/app when referring to previous factory version. Anyways, are you using official APIs like SharedPreference for app private data? If so, i would assume it would be framework's responsibility to update references just like resource path and code path.
Post a Comment