Cells runs multiple VPs on a single hardware phone. Each VP runs a standard Android environment capable of making phone calls, running unmodified Android applications, using data connections, interacting through the touch screen, utilizing the accelerometer, and everything else that a user can normally do on the hardware. Each VP is completely isolated from other VPs and cannot inspect, tamper with, or otherwise access any other VP.

While VMs are useful for desktop and server computers, applying these hardware virtualization techniques to smartphones has two crucial drawbacks. First, smartphones are more resource constrained, and running an entire additional operating system (OS) and user space environment in a VM imposes high overhead and limits the number of instances that can run. Slow system responsiveness is less acceptable on a smartphone than on a desktop computer since smartphones are often used for just a few minutes or even seconds at a time.

Second, smartphones incorporate a plethora of devices that applications expect to be able to use, such as GPS, cameras, and GPUs. Existing approaches provide no effective mechanism to enable applications to directly leverage these hardware device features from within VMs, severely limiting the overall system performance and making existing approaches unusable on a smartphone.

Cells meets all three requirements in the tightly integrated, and often proprietary, smartphone ecosystem. It does so by integrating novel kernel-level and user-level device virtualization methods to present a complete virtual smartphone OS environment. Kernel-level mechanisms provide transparency and performance. User-level mechanisms provide portability and transparency when the user space environment provides interfaces that can be leveraged for virtualization. For proprietary devices with completely closed software stacks, user-level virtualization is necessary.

The entire radio baseband system is proprietary and closed source, starting from the user-level RIL vendor library down to the physically separate hardware baseband processor. Details of the vendor library implementation and its communication with the baseband are well-guarded secrets. Each hardware phone vendor provides its own proprietary radio stack. Since the stack is a complete black box, it would be difficult if not impossible to intercept, replicate, or virtualize any aspect of this system in the kernel without direct hardware vendor support. Furthermore, the vendor library is designed to be used by only a single RilD and the radio stack as a whole is not designed to be multiplexed.

While some smartphones support multiple SIM cards, which makes supporting multiple phone numbers straightforward, most phones do not provide this feature. Since mobile network operators do not generally o↵er multiple phone numbers per SIM card or CDMA phone, we o↵er an alternative system to provide a distinct phone number for each VP on existing unmodified single SIM card phones, which dominate the market. Our approach is based on pairing Cells with a VoIP service that enables telephony with the standard cellular voice network and standard Android applications, but with separate phone numbers.