It is not an app update (though it can update apps), it is a system update Means Over-the-air It’s an update that you receive by the Internet It doesn’t - and shouldn't - require any technical manipulations by an end-user Means you don’t have to plug your Android Means it costs less in logistics

We are not advertising any of theses companies, but this is an example of a few ones who are using or could benefit from a well designed OTA update system You are a mobile carrier : you may be distributing a specific version of an android phone You are a cable operator : your Set Top Box is running Android You are a device maker Phones & tablets Other Android devices (like the Neptune watch) (and basically any connected device) You are a large corporation and you have custom devices for your employees (HydroQuébec, UPS, Amazon, …) You are a an independant ROM maker So if you recognize your logo (or one of your competitors), you can come and meet us at the end of this presentation ;)

This activity can be started with the intent filter you can see on this screen. You need to include it in your Manifest to make sure the Settings app will find your activity.

Make also sure the priority is high, or the Google Play Services will be used instead of your application. The last important step is to put your application in the /system/priv-app so it will gain the necessary permissions.

(parenthèse chinois)

This is a pretty usual process to download the update, though you have to ensure a few things : use the appropriate connectivity, as mobile users will not like to see their data plan being killed download in background, make sure you can restart the download if the connection is lost

Here is an exemple using the download manager natively available in the OS, which supports most of the features needed : background wifi only not disturbing the user The only drawback is that you will be forced to download the update on a publicly accessible data partition. (you can create you own version of the DL manager in order to avoid that)

(Parenthèse chinois)

Do not forget a few things such as permissions and a broadcast receiver which will be notified when the download finishes.

Make sure you perform some kind of integrity check after the download is complete : double checking doesn’t cost much and can prevent your device from becoming a nice brick storage may be defective and your file corrupted

Again, make sure this is well tested and nothing wrong may happen here !

Once the update was downloaded, you have to perform a few operations : check the validity of the update package reboot the system in order to install the update package => this is why your application needs to be privileged (ie. installed in /system/priv-app)

Easy to say … and easy to do ! There is no hidden API, though it is not the most documented one…

(parenthèse chinois)

Do you know that Android is not the only OS on your device ? The other one is called the recovery.

In order to load each of the OS, the bootloader is used (see it as the BIOS of your device) The bootloader is always loaded on boot, it is responsible for loading the OS which will be used on the device. In our case, it will either load the recovery or Android.

There is no action required here, but it is still interesting to know what's going on when your device reboots : the bootloader starts as usual it checks the reason for which the device is restarted as we need the device to install the update, recovery is the reason recovery is started !

Once recovery is loaded, it will read commands from a set of files in the cache partition, and will start the update process : Check (again !) the file signature Decompress the update Run the updater script, which will perform the specifics of the update

This screen is not the one the user will see during the update, although, it reflects the available functions in the Recovery.

The updater script will perform various operations, such as mounting file system - even formatting them installing new apks or binaries setting new system properties updating rights … Depending on the content of the update, the duration may change.

Make sure your updater is notified when the device boots up, it will help you perform a few basic tasks : Delete update from storage, as you do not want the user to see its storage filled with update packaged Call the back-end which will keep track of a successful update ! … and you are done with the update !

How can we do this ? It is pretty straightforward : we use a simple broadcast receiver to start our service on boot.

Now that we have seen how the update process works on the device; we will explain how we worked on the back-end.

You may want to host a simple back-end with a description file and the updates. It may be useful if you are an independent developer, and provide your ROM to a few users.

Pretty straightforward, but it will not fit the needs of a larger distribution

If you are distributing ROMs to a various range of devices, you may have to go for a solution which will help you doing so.

Here are a few things we took in consideration while designing ours : Make sure you can distribute large files to a large number of devices Create a simple yet efficient API which will provide the devices with the correct updates Allow the possibility of a multitude of devices Handle multiple distribution branches Give feedback (statistics) about installation and requests

Soooooo let’s talk about the challenges we are facing.

This is our device, it has its own characteristics.

Hourray, I sold lots of it !

And I start to sell new models, and different kinds of devices : phones, tablets, smartwatches, thermostats, smoke detectors, ...

you may want to grab some of dev, like the one you have for dev purpose, and update them over the air without affecting the rest of the users Another use case: sometimes you don’t have the choice, your terminal are sent to your support team. Those guys also have the right to test your corrective maintenance easily.

Specific information makes it possible to create groups which will be provided with specific versions of the ROM while using the same devices : developers, who'd like to have the latest version of an OS in order to test their applications, beta users, who will provide feedback to your company, enterprise users, who may have specific use cases with dedicated ROMs, support centers, who will need to be trained before the official release, … basically any kind of group you could think of !

In order to make sure we can identify a device specifically, we send as many information as possible to our back-end : model, IMEI, MAC address, serial number, ROM version, etc. All this data allows us to determine if the device has to be updated, and which version is to be used.

=> Passe la main à Simon Time goes by, users will update - or not - their devices, which will lead to fragmentation.

Compatibility awareness is a pain in the ass:

A version you distribute can be compatible with just one other version or with several version. You don’t really want to force a non updated tablet through all incremental versions you manage until the very last one. Maybe just serving the last full compatible version does a better job.

Here is a screen capture of the main dashboard of our solution running, which reflects everything we said before. Because of the fine granularity we use, we can quickly and easily picture the state of a fleet of devices.

Our main sources of information are the following : Android's source code : when you are working on a ROM, just keep reading AOSP's code and you'll find what you want ! StackOverflow and Google : sadly / luckily, we were not the first people to look into this, so you may find a nice amount of information about OTA using the usual tools Reverse Engineering the Play Services : have a look at what Google does !

As we now have a nice way to update Android-based devices, we work on updating other devices : wearables, camera, beacons, home automation, ...

[Questions]

Thank you for your attention, if you want us to help you providing updates to your devices, feel free to meet us at our booth after this talk. Enjoy the rest of the Droidcon, and we look forward to drink a beer with you after the event !