Updates not only bring new features, but often also solve problems. Or even plug security holes. So it’s surely a good idea to take care for the up-to-dateness of apps and system.
Unfortunately, this often sounds easier than in appears to be in reality: Are all updates really “good updates”? Should we sometimes better skip a version – or even stick to the one installed? Where do updates come from, and how to get them on our “Androids”? What other questions to raise on this topic? I hope this article can shed some light onto these areas.
Updates for Apps
For apps installed from one of the “establihed Market-Apps”1, the “Where” part seems clear: usually, the very same market-apps themselves take care to inform the user on updates, as well as to apply them. Information on available updates are retrieved in different ways – in accordance to the specific structures behind the corresponding market. Two examples to illustrate this:
- Using Google Play Store requires an account. All user data is stored centrally on Google’s servers. Thus Google knows exactly which apps are installed on which device – and sends information per “push message”, whenever an update to any of them is available.
- F-Droid repositories can be used anonymously, so they don’t know what apps are installed where. In this case, their app takes care to keep the repository metadata up-to-date on the device, pulling them from the server in intervals. Aptoide does it in the same manner. This corresponds to the principles behind the APT tool, as used by Debian based Linux systems.
Both variants have their benefits and drawbacks: While with Google Play, only relevant information needs to be transfered (and moreover, almost promptly on their availability), with F-Droid (and Aptoide) all information is available offline, and thus can be searched even without an established internet connection2.
But from the point of security and privacy, Google Play has a serious handicap: starting June 2014, they “simplified” the way permissions an app requests are displayed (see image to the right). No longer each requested permission is shown explicitely, just the corresponding permission group is mentioned. As if it wouldn’t make a difference whether an app only wants to check “which apps are running” – or rather read and write your “browsing history and bookmarks”! Aggravating this situation: does an app on update request another permission covered by the same group it was granted a permission from before, that’s granted implicitly without informing the user. So in the example above, an app could first request access to the list of running apps, and pick “browsing history and bookmarks” with a later update.
While on a first install, one can check the full permission list on e.g. the app’s Playstore page, that doesn’t help for updates (as just described). To protect you against additional permissions sneaking in with updates, you have to disable automatic app updates. Now, whenever there’s a pending update you want to apply, you’ve got to manually match all permissions requested by the updated app version against the version installed on the device.3 An effort almost no user will take upon himself. Not to speak of the impossibility to do so on e.g. a 4 inch smartphone display, even ignoring the fact most of them don’t allow to put the lists next to each other. So the user has to open the permissions of the currently installed version on his Android device4, and in parallel the ones of the “new version” in a web browser on another device (e.g. the PC) – and then check permissions one by one. A tedious job, especially for apps with many permissions. So the only thing they’ve “simplified” is the possibility to “sneak in” additional permissions on updates.
Updates for Services
“Services” are placed somewhere between apps and “the system”. More and more system functionality gets moved into Google Play Services. As the latter are apps available at the Google Play Store, they are updated automatically as described above (usually even if you deactivated “automatic updates”). In this case, the user doesn’t need to care for anything specific – he even can’t. The big advantage of this “outsourcing”: updates are delivered much faster to the target devices, as there’s no detour via manufacturers and providers (see OS Updates below).
But still, there are pitfalls. The first: more and more Open Source components are transferred into proprietary code.5 This ties developers as well as users closer to Google as company: To pre-install Google Play Services on an Android device, a manufacturer has to meet certain requirements – which is why e.g. they are usually not found in Custom ROMs6 by default. Does an app depend on those interfaces for essential functionalities, it cannot be used on devices coming without that “Framework”, and can be made usable with other ”substitutes” only with large effort. The more core functionality is moved that way, the more this “binding” is cemented – and the more apps are “affected automatically”. Especially critical from the point of privacy, if ad-modules get “fixed” into those “services” – as it is the case for the Google Maps API, a developer reported to me. So even if you don’t see any ads in the payed version, who can guarantee no personal data is collected for “profile making and maintenance”? Being an integral part of the host app, the ad module after all has access to everything available to the host.
Furthermore there are devices intended for productive/corporate use only. On those, additional modules like “Games Services” are not only needless, but potentially obstructive (additional resource usage, shorter battery-life), or even an “unnecessary security risk” (what’s not installed, can’t bring in security holes to be exploited). Under these aspects it would be welcomed, if Google at least gave the user the choice. The entire “Google Services” package could be modularized (take the Xposed Framework as example), and “wanted services” managed with the already existing “Google Settings” app: Load and install what is needed, and remove and uninstall what’s not wanted. That would improve the situation – though it would still leave the trouble with proprietarity.
Updates for the Android OS
Here it gets a little complex, as this German article at Heise describes detailled: Android system updates have a long way to go. As each manufacturer is using different hardware components in his devices (which not always have open specs), you can’t simply take an AOSP7 ROM and put it on a device of your choice. First, the corresponding drivers need to be integrated – which is the manufacturers’ task. Is the latter equipping his devices with his own, specifically adapted user interface8, this has to be updated and tested as well. And finally, did you obtain your device from your carrier (usually cheaper and contract-bound), he’s the next one entering the game: those devices usually come with a branding9, which again needs to be updated and tested. So from the AOSP releasing a new Android version, and the very same reaching your device, it can easily take a couple of months or even more than a year – if it’s rolled out to it at all. It’s no great exception that some link in this chain decides to no longer support a certain device.
But even if these obstacles have been overcome, and a new Android version is available for our device: how does it get installed? It’s not always as easy as the image to the left suggests. Of course there are OTA-Updates10 – at least they talk about that at the forums, and even screenshots like the one used here as teaser image do exist. But on none of my devices I have ever seen one: My LG Optimus 4X for example still runs Android 4.0.3, though there’s an official update to JellyBean available. Each manufacturer seems to go it’s own way here: While “minor updates” (e.g. from Android 4.0.3 to 4.0.4), if made, often are shipped via OTA, “major ones” (e.g. from 4.0.4 to 4.1.2) mostly require using the manufacturers specific software – which often is available for Windows only11:
- LG: “Please use our PC Suite” (Windows only)
- Samsung: “That’s what Samsung Kies is for” (only Windows and Mac; thanks to the popularity and widespread use of their devices, there’s also the third-party Heimdall for Linux, Mac, and Windows)
But there are manufacturers doing this differently12 – and let us download and install updates using nothing but our Android devices themselves. As shown in the picture, the device’s “recovery mode” can be used for this: You download the update directly to the device (e.g. using your web browser and the manufacturer’s homepage), save it to the SDCard, and boot into “recovery mode”. Here you select to “apply an update from SDCard”, and there you go. That’s how it should be, and how it works on e.g. my tablets made by Cat-Sound. A co-worker of mine even received his update to Kitkat per OTA – for a Huawei P6, definitely not the newest device of this Chinese company.
The only way to escape this “prison” often is: to root13 the device, if necessary unlock the bootloader14, install a custom recovery, and put a Custom-ROM on. Depending on the device’s popularity, a number of alternative custom ROMs (and several costom recoveries) are available.
Who’s always going with the tide, doesn’t care about privacy, and flout on everything else for a little more comfort: He shalt take a Google Nexus device, keep “automatic updates” for apps enabled, and enjoy swift Android updates. Everybody else nees to apply some handwork to ship around the cliffs. Help is, as usual, available e.g. at bei Stack Exchange, but also in the appropriate forums.
Some of the “App Markets” I’ve introduced in Android Markets: How safe are alternative sources? ↩︎
Apps or their updates can also be marked for later installation – which then of course requires a network connection ↩︎
Also see Stack Exchange: Is there a way to know the actual permissions of an app now before installing? ↩︎
Settings→Apps, scroll to the App, open its details ↩︎
Also see Google’s iron grip on Android: Controlling open source by any means necessary, where the bitter conclusion reads: Android is open—except for all the good parts ↩︎
AOSP stands for the Android Open Source Project, which takes care for the core components of the Android systems. AOSP ROMs, without any modification, usually run fine on Nexus devices. Almost all Custom ROMs available for Android build upon them – directly or indirectly. ↩︎
Branding in this context means the pre-installation of provider specific apps and usually also boot animations ↩︎
An OTA-update brings software updates from the manufacturer/provider directly to the device, using cellular network or WiFi. Sometimes, the more complete term "FOTA" is used, meaning "Firmware Over The Air". ↩︎
Completely incomprehensible that one should need a Windows license for a device based on Linux. Not pointed out explicitly on sale, this most likely is a legitimate reason to return the device. The decline of computers in favor of tablets as predicted by Gartner, on this background feels pretty relative. ↩︎
Here I gladly accept your feedback on how other manufacturers deal with it. I might even create (and publish) results as a list! ↩︎
Using “root” one gains system-level access to the device – comparable to the “Administrator” account on Windows, or the “root” account on Linux/Unix. Help on this can be found e.g. at bei Stack Exchange, but also in other appropriate forums. ↩︎
As security measure against installation of “unauthorized” system software, almost all Android devices ship with their Bootloader locked. In easy terms this means you can only apply system updates the manufacturer “blessed”. Again, for details and help you might want to head over to bei Stack Exchange. ↩︎