Category : Best Practices

Posted by Peter Armitage, Software Engineer, Google Play

Releasing a new version of your app is an exciting moment when your team’s hard work finally gets into the hands of your users. However, releasing can also be challenging – you want to keep your existing users happy without introducing performance regressions or bugs. At Google I/O this year, we talked about staged releases as an essential part of how Google does app releases, allowing you to manage the inherent risks of a new release by making a new version of your app available to just a fraction of your users. You can then increase this fraction as you gain confidence that your new version works as expected. We are excited that starting today staged releases will be possible on testing tracks, as well as the production track.

We will take a closer look at how staged releases work, and how you can use them as part of your release process.

Advantages of a staged release

The first benefit of a staged release is that it only exposes a fraction of your users to the new version. If the new version contains a bug, only a small number of people will be inconvenienced by it. This is much safer than releasing a new version to all of your users at once.

Another benefit is that if you discover a bug, you can halt the rollout, preventing any new users from downloading that version. Instead, they will receive the previous version.

These capabilities should relieve a lot of the uncertainty of rolling out a new version. And that will allow you to do it more often. We encourage releasing versions of a server more often because it reduces the number of changes between each release, allowing you to more easily test and troubleshoot. The same principle applies to apps, though there will be a delay before most of your users upgrade to the latest version.

Staged releases as part of your normal release process

Let’s look at a typical release process for an app with 100,000 users.

  1. Every Monday the developer builds a new version of the app from the latest version of the code that passes the automatic tests. They push the new release to Google Play’s internal test track, and their QA team immediately starts testing it manually. Any bugs they find can be fixed and a new version can be built and pushed for them to re-check.
  2. On Tuesday, if the QA team have approved the latest release, it can be promoted to the app’s alpha track. All the employees at the company have opted in to testing. Once the new release is pushed to the alpha track, the employees can download the new version. They can do this manually, or they may have auto-updates enabled, in which case they will probably update within a few hours.
  3. On Wednesday, if there are no reported issues with the release, they can promote the release to the production track and start a rollout at 10%. This means 10,000 users will have the opportunity to upgrade. Some will upgrade immediately, others will wait. The 10% of users that receive the app first are randomly selected, and the users will be randomly chosen each week.
  4. On Thursday, the developer checks the Play Console to see their crash reports, Android vitals, and feedback. If these all look good they can increase the rollout to 100%. All users will be able to upgrade to the new version.
  5. On Friday, the developer doesn’t change anything, to ensure a stress-free weekend!

For big apps and small apps

Some apps are just starting out, and although there’s no QA team, it’s still worth testing the app on a few different devices before releasing it. Instead of having a track for employees, the developer has added their friends and family, who can contact them if they see an issue.

When an app gets larger and uses the open testing track, it may have 5,000 testers. These testers won’t give public feedback on the Play store, but will be able to give feedback to the developer directly. If this app has 1 million users, they may first release to 1%, before going to 10%, then 100%.

Once an app becomes very popular, it could have over 100,000 testers. In that case the developer is now able to do a staged release on their testing track.

How to bounce back from issues

Bugs happen, and if you discover a problem with your new version you may want to halt the release. This will stop users from getting the new version, either by upgrading or installing for the first time. However, those who have already got the new version will not downgrade.

If the issue was not in the app itself, but on a server that the app communicates with, it may be best to fix the issue in the server, then resume the release. Resuming it allows some fraction of your users to access the new version again. This is the same set of users that were able to download the release before it was halted.

If the issue was in the app, you will have to fix it and release a new version. Or alternatively, you may choose to rebuild the previous version with a higher version code. Then you can start a staged release to the same set of users that the previous release went to.

API support

Staged releases are supported in v3 of the Play Console API on all tracks. Mark a release as “inProgress” and set a fraction of the population to target. For instance, to start a staged release to 5%:

{
  "releases": [{
      "versionCodes": ["99"],
      "userFraction": 0.05,
      "status": "inProgress"
  }]
}

Alternatively, if you release using the UI, it will suggest a fraction.

What next?

We hope you find these features useful and take advantage of them for successful updates with Google Play. If you’re interested in some of the other great tools for distributing your apps, check out the I/O 2018 sessions, and learn more about test tracks and staged updates.

How useful did you find this blogpost?


Read more

Posted by Lukas Bergstrom, Product Manager, Android Developer Frameworks Team

Android runs on billions of devices, from high-end phones to airplane seatbacks. The Android OS manages resources aggressively to perform well on this huge range of devices, and sometimes that can make building robust apps complicated. To make it easier, we launched a preview of Architecture Components at Google I/O to provide guidance on app architecture, with libraries for common tasks like lifecycle management and data persistence. Together, these foundational components make it possible to write modular apps with less boilerplate code, so developers can focus on innovating instead of reinventing the wheel – and we hope to keep building on this foundation in the future.

Today we’re happy to announce that the Room and Lifecycle Architecture Components libraries have reached 1.0 stable. These APIs are ready for production apps and libraries, and are our recommendation for developers looking for help with app architecture and local storage (although they’re only recommended, not required.) Lifecycles are now also integrated with the Support Library, so you can use them with standard classes like AppCompatActivity.

Although we’re declaring them stable today, the beta components are already used in apps that together, have billions of installs. Top developers, like Zappos, have been able to spend more time on what’s important thanks to Architecture Components:

Prior to the release of Android Architecture Components we had our own ViewModel implementation. We used Loaders and Dependency Injection to persist our ViewModel through config changes. We recently switched to the Architecture Components ViewModel implementation and all that boilerplate went away. We found that we were able to spend more time on design, business logic and testing, and less on writing boilerplate or worrying about Android lifecycle issues.

We’ve also started to use LiveData which hooks directly into the Activity lifecycle. We use it to retrieve and display network data and no longer have to concern ourselves with ​network call subscription management.

– David Henry, Android Software Engineer, Zappos

Architecture Components provide a simple, flexible and practical approach that frees developers from some common problems so they can focus on building great experiences. This is based on core building blocks tied together by guidance on app architecture.

Lifecycles

Every Android developer has to deal with the operating system starting, stopping and destroying their Activities. That means managing the state of components – such as observables used to update UI – as you move through the lifecycle. Lifecycles enables the creation of lifecycle-aware components that manage their own lifecycles, reducing the possibility of leaks or crashes. The Lifecycle library is the foundation for other Architecture Components like LiveData.

LiveData

LiveData is a lifecycle-aware observable that holds data and provides updates. Your UI code subscribes to changes and provides LiveData a reference to its Lifecycle. Because LiveData is lifecycle-aware, it provides updates when its Lifecycle is started or resumed, but stops providing updates when the LifecycleOwner is destroyed. LiveData is a simple way to build reactive UIs that are safer and more performant.

ViewModel

ViewModel separates ownership of view data and logic from lifecycle-bound entities like Activities and Fragments. A ViewModel is retained until its associated Activity or Fragment is disposed of forever – that means view data survives events like a Fragment being recreated due to rotation. ViewModels not only eliminate common lifecycle issues, they help build UIs that are more modular and easier to test.

Room

Nearly all apps need to store data locally. While Android has bundled SQLite with the platform since version 1, using it directly can be painful. Room is a simple object-mapping layer that provides the full power of SQlite with less boilerplate. Features like compile-time query verification and built-in migration make it easier to build a robust persistence layer, while integration with LiveData lets Room provide database-backed, lifecycle-aware observables. Room blends of simplicity, power and robustness for managing local storage, and we hope you give it a try.

Guide to App Architecture and more

Last but not least, we created a Guide to App Architecture that provides core principles applicable to all developers, and specific guidance on using Architecture Components together. Because we’ve heard from you that clear and consistent guidance is important, today we’re updating developer documentation to point to Architecture Components where appropriate. We also have a rich set of videos, codelabs and sample apps available at the Architecture Components site, with more to come.

Watch this space

Although the first set of Architecture Components is now stable, we know there’s more work to do. Over the last few months, we’ve listened to your feedback and made improvements. We also recently launched a new Architecture Component, PagedList, to alpha, in response to your feedback that handling large datasets with RecyclerView is too difficult. This is just the beginning – we have more major components under development that we’re looking to announce in the upcoming months.

Our hope with Architecture Components is to free developers to focus on providing unique new experiences for mobile devices. We’re glad we can finally announce them as stable for production use. We’d like to thank the community, which has given such great feedback along the way, and we look forward to continuing the discussion in the comments of this post. Finally, for those of you who’ve been waiting for this stable launch, get started today.