Thursday, July 25, 2013

Explaining the software upgrade process and its improvements for Android™ 4.3

Yesterday was a big day for all Android fans, as Google released the source code for Android 4.3. This means that manufacturers now are getting busy preparing software upgrades. From Sony’s side, you can already read about some of our software upgrade plans on the Sony Xperia News room blog. Software upgrades are an important asset for a device, and we are continuously working to improve the process and lead times. Learn more about how the process works, and what improvements you will see going forward in the full post. Read more after the jump!
During our work with the Ice Cream Sandwich (ICS) software upgrade back in 2011, we made a post called Ice Cream Sandwich – from source code release to software upgrade, which explained the steps it took at the time to get the ICS software upgrade out to our users. But quite a few things have actually changed for the better since then. So in this post, we will share how that process has been further fine tuned in order to cut lead times, while keeping quality and stability intact on a top level.
Overall, the software upgrade process consists of two main phases: the Bring up phase and the Test, certification and approval phase. During the Bring up phase, we make sure that the software works and is stable on our devices, and we also integrate new and existing Sony features on the new software.  Compared to the ICS release, this work is now more efficient thanks to closer cooperation with Google and Qualcomm Technologies, Inc., which we write more about below. And because of our work with Android Open Source Project (AOSP) for Xperia devices, the feature upgrade part of the Bring up phase can now run in parallel to the initial bring up activities.  We’ll tell you more about this further down under “Adding Sony features and applications“.
Then in the Test, certification and approval phase, we make sure we comply with technology standards and regulatory requirements. This ensures that the software we roll out is tested thoroughly, and that it complies and works well with all technologies and components included on the device.
Software upgrade
Illustration showing activities from source code to software upgrade.
The Bring up phase: making the software run on Xperia™ devicesThe first thing we do when starting the Bring up phase is to make sure to get the core Android operating system (boot, kernel, all hardware components) running and stable, since this is a prerequisite for all further integration.
Fredrik Ekstrand, Head of Software Product Management at Sony Mobile.
Fredrik Ekstrand, Head of Software Product Management at Sony Mobile.
Fredrik Ekstrand, Head of Software Product Management, and responsible for the overall planning of software upgrades, explains more:
 – During the Bring up phase, we now have a much closer collaboration with Qualcomm Technologies than we had at the time of the ICS release. This makes the Bring up phase much more efficient, as we can use a lot of the work they do on their reference design for our integration. This is also something we are constantly working to improve even further, says Fredrik.
Another change in how we work is that we now get some pre-release information from Google through the Platform Development Kit (PDK). The PDK is distributed to selected device manufacturers and chipset vendors a few weeks before the public release of a new Android version.
– Since the ICS days, we have improved our cooperation with Google. Even though we haven’t seen the new Android 4.3 source code until it’s publicly released, we now get some information from Google about what areas will be updated before the public push through the PDK. The PDK was introduced by Google to help us and other manufacturers speed up the upgrade process. This means that we can plan our software upgrade projects more in advance, as we know roughly what parts of the Hardware Abstraction Layer (HAL) we need to update, says Fredrik.
The PDK is a collection of source files and software binaries that enable device manufacturers and chipset vendors to port their drivers, develop, optimise and test against a new Android release before it is publicly released. The Android PDK includes a set of interfaces for the Android hardware abstraction layer (HAL), platform sources for integration, and a binary system image. The PDK also includes HAL and integration documentation and the Android Compatibility Test Suite (CTS).
Illustration showing how the software upgrade process has been improved by using the PDK and AOSP. By getting access to the PDK before the Android source code is available, we can start the initial phase of bring up earlier. And by having Xperia™ devices running AOSP, the feature upgrade work can start immediately when the Android source code is available. Note that this picture is for illustrative purposes. It does not reflect actual lead times and timings.
Illustration showing how the software upgrade process has been improved by using the PDK and AOSP.
By getting access to the PDK before the Android source code is available, we can start the initial phase of bring up earlier. And by having Xperia™ devices running AOSP, the feature upgrade work can start immediately when the Android source code is available. Note that this picture is for illustrative purposes. It does not reflect actual lead times and timings.
Updates in the Hardware Abstraction Layer (HAL)Another important part of the work in the Bring up phase is the component configuration in the HAL. This work is done since we don’t use exactly the same components in our devices as Qualcomm Technologies is using in their reference design. For example, we are using different cameras, displays, memory chips and sensors. All of these components need to be integrated with the new software, so this is work that we need to do ourselves. Some of these components also vary between our own models.
An important part of the HAL is the sensor HAL, which implements support for the sensors on the device. At Sony, we have developed a dynamic HAL for the sensors, called DASH, which is also available as open source onGitHub. The changes we make in DASH for Android 4.3 will be pushed to GitHub, including the sensor configuration files.
Illustration showing a simplified Android architecture.
Illustration showing a simplified Android architecture.
Getting basic functionality in placeWhen the Android kernel and the HAL are in place and reasonably stable, then all the basic functionalities (such as phone calls, messaging and internet connectivity) are next in turn.
At this stage, we usually start “dogfooding” which means that we distribute the new software builds internally to users not directly involved in the bring-up activities. At this stage the new release is working reasonably for daily use, even though a lot of functionality is not in place and stability is not ideal yet. This wider use of the software gives us a lot of valuable feedback, and helps pinpoint defects as early as possible.
– There is rule of thumb in software development, which says that when a piece of software is complete and stable enough to be demonstrated, then about 90% of the work is still left, before it can go into production. In fact, with IceCream Sandwich, we reached the “demo stage” and began the “dogfooding” process in less than two weeks. At that time, ICS was good enough for daily use as long as you could live with occasional crashes during the day, but at the same time, there was still many weeks of hard and daily grind to add Sony features, improvements, and operator customizations, and squash out the bugs from all the different corners of the operating system, Fredrik Ekstrand explains.
 Integrating Android patchesIn the Bring up phase, another task for us is to integrate a number of software patches and improvements that Sony makes compared to standard Android, to improve stability and performance. More than half of all the changes we make in Android are on this basic level. And to avoid fragmentation of the Android code base, most of these patches and improvements are actually contributed back to the Android Open Source Project (AOSP), so that they are included in the default Android source code for the next software release.
 - The fact that we now have AOSP running on our devices (through the work with AOSP for Xperia) makes it easier for us to contribute our fixes and patches back to Android, which in the long run will mean that we will have fewer patches to integrate the next time Android is updated, says Fredrik.
 At this stage, we also integrate our own feature upgrades, such as customised graphics and UI components, a few proprietary APIs to enhance the Sony experience, and additions like improved text input and localisation. We also add functionality requested by different operators and regions. This is something that we have to do in order to receive all approvals in the Test, certification and approval phase (see below).
Continuous testing to ensure good qualityAs we incorporate these patches, improvements and customisations, we have a continuous test process ongoing to confirm that all the changes meet the required quality level. Initially, tests are focused on specific new patches and improvements. But as the integration proceeds, our focus moves to the validation of complete use cases, both those previously supported and those added by us or Google in the new release.
Adding Sony applications and featuresAs mentioned before, the Bring up phase is also when we add our unique Sony features and make sure they work well with the updated software. Compared to vanilla Android, we are for example improving or adding the following functionalities:
  • Lockscreen
  • Home
  • Phonebook
  • “WALKMAN” application
  • Movies application
  • Album application
  • Messaging
  • Quick settings
  • Text input
  • UI components
  • Localisation
  • Calendar
  • Email
Fredrik Ekstrand sees a lot of improvements in the way we will work with this for Android 4.3:
Since we have Android 4.3 running on Xperia devices already now, our software developers can start to verify the Sony applications and other functionality directly on AOSP. This makes it possible to start testing the features that are not dependent on Qualcomm Technologies or Sony SW components against the new software release before the initial integration is finalised, he says.
Furthermore, we also get the chance to start the adaptation to different regions, networks and operators at the same time as we do the feature upgrade work, Fredrik continues.
Getting the software stableWhen all functionalities have been merged together, we start on the stability tests to make sure the software runs stable in all sorts of use cases. Besides pure lab testing, and the “dogfooding” described earlier, we rely on a number of live users from within and outside the company to test and report defects. Along with pure stability testing, we also run other quality tests. For example, we perform power consumption tests to improve the power consumption in different user scenarios.
Once the software is stable and tested, it’s ready to be submitted for various certifications. However, the Bring up phase is overlapped by the Test, certification and approval phase, as some parts of the software are ready for certification earlier than others. As soon as a specific software module is ready, it’s sent for certification. So while one module can be in the Test, certification and approval phase, others are still in the Bring up phase.
The Test, certification and approval phaseIn the Test, certification and approval phase, we make sure that all the software and hardware parts comply with technology standards like Bluetooth™, Wi-Fi® and others. One of the main purposes with this is obviously to ensure that quality and conformance is at a top level, in benefit for all consumers worldwide. It is also necessary in order for us to be allowed to use these technologies in our products, and to ensure that they work well together with other certified devices. We must also ensure that everything we’ve updated follows the necessary legal requirements, such as Intellectual Property Rights (IPRs).
To a great extent, we try to get global certifications, but in many cases there are specific tests required in certain countries. For a global, worldwide product, we need local certifications in up to 80 countries. For all these certifications we are either allowed to do the tests ourselves, and submit evidence that we passed, or we can get external test houses to perform the tests.
Since our last post for ICS, I’ve seen comments on the News blog and on Developer World that we have been late with software upgrades due to slow software development. But actually, we have very knowledgeable and experienced developers who all work really hard to get the software upgrades out.But contrary to what people may think, it is not the Bring up phase, but the Test, certification and approval phase that is the most time consuming process when it comes to getting a new software release out on our phones, Fredrik says.
When all the certifications and approvals are in place, we are finally ready to roll out the software upgrade to Xperia™ users around the world.
Large companies can sometimes be less agile than we wish to be, but we now have reshaped how we work and have an improved upgrade process in place. With each improvement we make, our software is delivered quicker and to a higher standard. Sometimes decisions can be complex with several products and projects involved and we have to divide our efforts and resource between new products on the way to market and upgrades of several existing products which use different platforms and software versions. However, this is something we have worked hard to improve over the last year, and we are constantly working on optimising it even further, says Fredrik Ekstrand.
 Obviously everyone will now wonder how much faster the upgrades will come, and that we cannot exactly say right now since we are just getting started. But what we can say, is that we now have improvements in place and it should have a significant effect on the lead times”, Fredrik concludes.
 ***
As you might understand, this is a somewhat simplified description of the software upgrade process, but hopefully it gives some understanding of how it works, and how it has been improved. If you have any questions about how the software upgrade process works, drop us a line in the Comments section and we’ll do our best to answer. However, for the latest news about software upgrades and timings, please stay tuned to the Sony Xperia News room blog, where the information will be posted as soon as we can share it.

No comments:

Post a Comment