Activity/Service as a Dependency: Rethinking Android Architecture for the Uber Driver App

This article is the tenth and final in a series covering how Uber’s mobile engineering team developed the newest version of our driver app, codenamed Carbon, a core component of our ridesharing business. Among other new features, the app lets our population of over three million driver-partners find fares, get directions, and track their earnings. We began designing the new app in conjunction with feedback from our driver-partners in 2017, and began rolling it out for production in September 2018.

Many mobile apps are used for specific, user interaction-based tasks, such as sharing a photo, sending a message, or browsing information. Uber’s driver-partners, on the other hand, keep the Uber driver app running for hours at a time on their phones, finding fares, getting route guidance, and checking their earnings. Most of these features require users to open the app and keep it in the background on their phones.

We designed our original driver app to use Services in accordance with best practices for general use Android apps. Over time, however, we found that this approach was not the best fit for an app that needed to be kept running, resulting in overly complex code with duplicative features and unexpected behaviors.

As we began the process of rewriting our driver app, we were afforded the opportunity to rethink this architecture, and mitigate the issues we found with the previous app.

Traditionally, engineers develop feature code in Android apps with an Activity or a Service as an anchor. Our novel solution, built on the open source RIBs cross-platform mobile architecture we previously developed for our new rider app, centered around the idea that Activities and Services did not have to be a structural foundations of the app. Instead, RIBs let us build an architecture for the app where Activities and Services are not part of the core components, simplifying the business logic and streamlining the code.

While our approach is not directly applicable to most classes of mobile apps, it should serve as a new perspective on how to write apps, such as navigation services and geo-based games, that often run for many hours.

When writing our previous driver app, we followed a common pattern among Android developers: create an Activity and run logic related to its UX as part of it, while creating Services to run non-UX related logic. Depending on whether the driver-partner is online or offline, we also need to start a foreground Service to keep the app alive even when there is no Activity in the foreground.

Many features need to be available when the app is in either the background or the foreground. For example, while a driver is waiting for their next trip, they might put the app in the background, but we still need to display the dispatch offer when it arrives.

Our old application structure, shown in simplified form in Figure 2, below, made use of multiple Services to build background features:

Let’s identify a few of the symptoms caused by the structure or our previous driver app:

In addition to all the above, working with Services can be difficult. For example, on a tiny percentage of Android OS variants, the Service lifecycle methods are invoked in the wrong order. On another tiny percentage of devices, foreground Services don’t keep the app alive consistently without bizarre workarounds.

We wanted to structurally mitigate these issues in the new version of our driver app.

The core of our approach to re-architecting the Android driver app boils down to two principles:

The new driver app was developed using RIBs (Router Interactor Builder). In summary, RIB architecture allows us to create modular, business logic-focused components. Each RIB is an independent component comprised of an Interactor (business logic), Router (navigation), and Builder (dependency) that can be added as a child to another RIB. (Read Architecting Uber’s New Driver App in RIBs for an overview of how we used RIBs to rewrite our driver app.)

We wrote the core hierarchy of our application independently of the existence of an Activity. For example, in Figure 3, below, the Online RIB is attached when the driver is online regardless of whether the application has an Activity. Similarly, the Navigation RIB runs whenever a user opts into using Uber’s navigation, regardless of whether there is an Activity to visually display navigation directions or not.

In other cases, some RIBs are written once and re-instantiated when switching between Activity and non-Activity cases. For example, when the driver app receives a rider offer, the Online RIB attaches the Offer RIB to a window if no Activity exists, and attaches the Offer Screen to the OnlineView if an Activity does exist. The Online RIB observes a stream of View objects emitted when an Activity is attached to the App Root RIB so it knows when to switch between the two variants. The Offer RIB itself operates independently, unaffected by whether it is attached to a window or to an OnlineView.

All of the Service code in our app is written in a single 100-line file. This Service’s sole job is to keep the app alive in the background and restart the app when the OS temporarily kills it to free up memory. The rest of the application requests this behavior by incrementing or decrementing a KeepAliveCount. When the count is greater than zero the app is kept alive with a sticky foreground Service. When the count is decremented below zero the foreground Service is killed.

For example, in Figure 3, the KeepAliveCount is incremented when the application starts the Online RIB.

We can easily monitor this single Service to ensure it isn’t misused in production or doesn’t cause battery drain. Furthermore, there is only one location where we need to work around bugs in the Service framework.

Our solution doesn’t come without costs. In addition to the benefits our approach provides, it also creates some downsides:

Services and Activities don’t need to be an architectural component of your app. The Android community contains a lot of ideas and philosophies for structuring apps that work for many cases. Our paradigm fits our architectural principle of focusing on the business logic and keeping View as a peripheral component in the app’s RIBs structure. This paradigm works well for apps like ours that frequently need to be switched between the background and foreground and be kept running for many hours.

Interested in developing mobile applications used by millions of people every day? Consider joining our team as an Android or iOS engineer!