This is how BQ devices are updated.

Have you ever asked yourself what happens between when a new version of Android is announced until the update gets to you? It is a complex process made up of various phases. Let us explain it to you.

Frequently asked questions >

1

Google announces a new version of Android.

They start to develop it for their reference terminal.

2

Platform Development Kit (PDK) is released.

When Google finishes development for their terminal, they release the PDK and the source code in Android Open Source Project (AOSP) so that processor manufacturers can decide if they are going to support the new version and start working on it.

3

Work for BQ.

When the processor manufacturer considers that the version is stable, our firmware department now have to develop it. They establish the modifications required so that the version works perfectly in our devices.

At times, support from the processor manufacturer is needed in this phase to ensure the correct operability of all our hardware components. In this phase, all BQ personal features are added and in-house quality control tests are performed.

4

Beta version is launched.

When the firmware is sufficiently stable it is shared with the in-house beta tester team, with MVP program users, and with beta testers who have signed up to the program through the “My BQ and I” community to start the test phase.

If bugs are detected, you need to go back to the previous step so that the Firmware department can resolve them.

5

Tests and certification.

We run more than 700 in-house tests in different phases, and when all work correctly, third-party tests are performed including the quality certification by Google, amongst others (CTS, GMS…).

6

When everything is ready, BQ launches the update via OTA.

The initials OTA stand for “Over-The-Air” and refers to the way in which firmware updates are download onto user devices using mobile data connections or Wi-Fi.

Constant dedication.

The firmware department does not only work on launching new versions. Cross-functional teams of engineers are constantly developing new updates to optimise the performance of our devices and adding new features that also go through various phases of development and testing. We listen to our users and take into account their proposals adapting their experience of use to their needs. In our last two ranges alone we have launched more than 80 OTAs improving software operability and new features such as Dolby Atmos, Beauty Face, and HDR in the camera application.

Useful information about updates.

  • When we refer to the manufacturer of the device, we mean the company responsible for the brand of the smartphone, that is, BQ. We are responsible for developing the new version once the SoC manufacturer has adapted it.

  • When Google releases a new version of Android, it is associated with one or more reference devices, usually terminals from the Nexus family. Google develops this new version over several months exclusively for this terminal and makes sure that the version works correctly on their hardware. The diversity of Android terminals on the market is not considered during this process.
    It is important to understand that, during the period in which this new version is being prepared together with the reference terminal, no other manufacturer has access to said version and cannot start working with it until Google releases the Platform Development Kit (PDK) first, and afterwards the Android Open Source Project (AOSP) source code in the repository. As a consequence, the rest of the developers start with a substantial disadvantage in terms of time-to-market.

  • To be able to start with an update process phase the previous phase need to have been completed. As manufacturers of the device, we can only control the phases in which we are directly involved and not the ones that come before up to when the latest version is released to us. Furthermore, the time that is needed to adapt a new version to our terminals varies depending on the features it includes: if it affects the innermost layers of Android architecture, more development is necessary and perhaps the support of the SoC manufacturer to resolve possible operating errors. However, until we have the new version in our hands we cannot know the extent of the modifications that we have to make on the firmware.

  • When the manufacture of the SoC has worked on their part of the development and, if necessary, has given support to the firmware team on the main drivers. A beta version could be released without this support but the operability of the firmware would be unstable and not fulfil the minimum requirements set by BQ to release the update to everyone.

  • This can happen for different reasons due to the different development phases that could run behind schedule. First, Google developers optimise the Android version for their reference terminal. Once optimised, the SoC manufacturer developers start working on this version. This process can take a long time, and sometimes, the SoC manufacturer can decide not to give support to some processors. If this is the case, the manufacturer of the device with this processor has to discard the update for the terminal. If they decide to give support, they provide the manufacturer of the devices with the drivers needed to start adapting the firmware to the terminal. It is only now that the manufacturer of the device can begin to work on the update. If, in this phase, errors are found in the innermost layers of the Android architecture, the process can be delayed until the manufacturer of the SoC provides support to resolve them. At this point, the manufacturer of the SoC can decide to stop giving support to this terminal. If this is the case, the manufacturer of the device has to discard the update.

  • If the manufacturer of the SoC decides not to develop a new update of Android for a specific platform, the manufacturer of the device cannot implement it. Furthermore, it is possible that, even though they develop it, they give no support to the errors detected at driver level of the component of the version. Their intervention in these cases is essential to launch a stable version to users. If they not supported, the version cannot be launched.

  • On occasions, the community manages to adapt Android versions for devices where the SoC manufacturer has not done so. This is extremely risky because the implementation of Android must always be with the support of the SoC manufacturer. Without it, the resultant versions are unstable and the users are exposed to serious operability errors in the terminals.