Amniote: A User Space Interface to the Android Runtime

Zachary Yannes

and Gary Tyson

Department of Computer Science, Florida State University, Tallahassee, U.S.A.

Keywords:

Android, Zygote, Runtime, Dalvik, Virtual Machine, Preloading, ClassLoader, Library.

Abstract:

The Android Runtime (ART) executes apps in a dedicated virtual machine called the Dalvik VM. The Dalvik

VM creates a Zygote instance when the device ﬁrst boots which is responsible for sharing Android runtime

libraries to new applications.

New apps rely heavily on external libraries in addition to the runtime libraries for everything from graphical

user interfaces to remote databases. We propose an extension to the Zygote, aptly named Amniote, which

exposes the Zygote to the user space. Amniote allows developers to sideload common third-party libraries

to reduce application boot time and memory. Just like the Android runtime libraries, apps would share the

address to the library and generate a local copy only when one app writes to a page.

In this paper, we will address three points. First, we will demonstrate that many third-party libraries are

used across the majority of Android applications. Second, execution of benchmark apps show that most

page accesses are before copy-on-write operations, which indicates that pages from preloaded classes will

infrequently be duplicated. Third, we will provide a solution, the Amniote framework, and detail the beneﬁts

over the traditional Zygote framework.

1 INTRODUCTION

Recent studies have shown that Android devices have

maintained substantially higher market shares com-

pared to iOS, Windows, Blackberry, and other oper-

ating systems (Katariya, 2017). With the increase of

Android devices, application development has also in-

creased. A recent report by AppBrain shows that as of

January 1, 2018, there are roughly 3.5 million appli-

cations in the Google Play Store. The growing trend

of Android development indicates that it is an ideal

candidate for research.

Android applications contain a combination of

Java bytecode, native code, and resource ﬁles. Un-

like traditional Java applications, Android apps exe-

cute in a dedicated virtual machine called DalvikVM.

DalvikVM has several unique features tailored to-

wards mobile devices which have less resources than

those of a laptop or desktop computer. For example,

Dalvik VMs utilize a register-based construct rather

the stack-based execution of traditional Java VMs.

This improves execution speed and reduces the com-

plexity of switching between applications.

The primary difference between DalvikVM and

traditional VMs is the Zygote. The zygote process,

https://orcid.org/0000-0003-3098-0807

which is started after the kernel is loaded, preloads

common runtime classes and resource ﬁles from the

Android and javax packages into a read-only boot im-

age. When a new application is ready to launch, zy-

gote forks a new VM and starts the process. The new

app contains a reference to the boot image rather than

a full copy. This allows multiple applications to share

common classes and resource ﬁles, reducing memory

utilization.

The Android kernel employs a copy-on-write me-

chanism for the boot image. Whenever an application

writes to an address mapped to the shared boot im-

age, the kernel copies that page to that application’s

address space. This allows each application to main-

tain a local copy of written pages.

Since the initial Android version release in 2009,

Google has released 14 versions, with the newest, Pie,

currently in beta (Wikipedia, 2018). This is a rapid

development cycle for a relatively new operating sys-

tem. To keep up with the rapid changes to the An-

droid API, Google released a dedicated integrated de-

velopment environment (IDE), Android Studio. An-

droid Studio provides support for Maven reposito-

ries, which simpliﬁes the process of linking to exter-

nal libraries. This caused a paradigm shift of rely-

ing on third-party libraries for common Android util-

Yannes, Z. and Tyson, G.

Amniote: A User Space Interface to the Android Runtime.

DOI: 10.5220/0007715400590067

In Proceedings of the 14th International Conference on Evaluation of Novel Approaches to Software Engineer ing (ENASE 2019), pages 59-67

ISBN: 978-989-758-375-9

ities such as graphic user interfaces (GUI) (Android,

2018a; Android, 2018e; Android, 2018f), data stor-

age mechanisms (Google, 2018b; Google, 2018c; An-

droid, 2018c), and code annotations (Android, 2018d;

Google, 2018a; Android, 2018b).

There has been widespread adoption of many

third-party libraries which are utilized by a large num-

ber of Android applications. Not only does this re-

duce coding time but it also provides an opportu-

nity optimization. Just as the Android/javax runtime

classes and resource ﬁles are referenced by many ap-

plications, so are the classes and resource ﬁles in a

number of third-party libraries.

The other option is to extend the functionality of

the zygote process to the user space. The ability to ap-

pend classes and resource ﬁles to the zygote process’s

memory space from user space would open up many

avenues for optimization. Therefore, we introduce a

framework called Amniote which provides methods

of managing the zygote’s boot image from the user

space. The Amniote framework also contains utilities

for calculating common classes between a large set of

applications.

The Amniote framework could also beneﬁt mo-

bile device vendors and Android Things developers.

Mobile vendors often fork Android with customized

launchers, stock applications, and power monitoring

(Peters, 2017). The applications in these forked An-

droid versions likely share proprietary code which

would beneﬁt from adding to the boot image. An ad-

ditional beneﬁt would be quicker deployment of new

Android version. Instead of vendors implementing

optimizations on the operating system, “proﬁle” ap-

plications could be written which optimize the zygote

boot image depending on the type of applications the

user will be running. Similarly, Android Things de-

velopers deploy applications with a speciﬁc suite of

required libraries.

The remainder of this paper is organized as fol-

lows. In sections 2 and 3 we describe Java’s Class-

Loader and how it can beneﬁt from prefetching in

both traditional Java VMs and in Android’s Dalvik

VMs. In section 4, we further explain the zygote pro-

cess. In section 5, we analyze the commonly used

third-party classes across a large sample of open-

source applications. In Section 6, we evaluate the

executions of applications in the Agave benchmark

suite and stock Android applications. In Section 7,

we describe the Amniote framework. In Section 10,

we conclude our ﬁndings and discuss future work on

this topic.

2 THE JAVA ClassLoader

Java VMs rely on a boot classpath which con-

tains paths to all Java class ﬁles. This allows Java

to support lazy loading, where classes are loaded

on-demand via a ClassLoader (Liang and Bracha,

1998). ClassLoaders also provide support for mul-

tiple namespaces, which allows a VM to have non-

unique class names which are resolved by unique

package namespaces. For example, the Android SDK

provides the class android.app.Application contain-

ing generic app data that is frequently extended to

contain app-speciﬁc data. In this case, the system

ClassLoader will resolve the Android SDK’s Appli-

cation while a second application ClassLoader will

resolve the

As shown in (Liang and Bracha, 1998), Class-

Loaders are typically implemented with a cache of

loaded class data referenced by the class name. For

example, when the application requires a speciﬁc

class for the ﬁrst time, a ClassLoader searches the

classpath for the class ﬁle, loads the class ﬁle into

memory, and adds an entry into the ClassLoader’s

cache. Each subsequent use of that class then utilizes

the class data found in the ClassLoader’s cache.

3 PREFETCHING

ClassLoaders demonstrate a common cache problem

where compulsory (or cold) misses accumulate since

the cache is initially empty and the ﬁrst reference of

a class results in a cache miss. To circumvent this

problem, prefetching ﬁlls the cache with classes it will

likely access to avoid costly searches and disk I/O op-

erations. Cache prefetching is not a new solution. In

fact, preloading process works for both hardware and

software caches. Yet we limit the scope of this paper

to software caches.

3.1 Java VM Prefetching

An early approach, greedy prefetching, was used in

(Luk and Mowry, 1996) for recursive C program

data structures. This was later extended in (Cahoon

and McKinley, 1999) to Java programs, using intra-

procedural data ﬂow analysis to detect objects to

prefetch. Their approach demonstrates the effective-

ness of greedy prefetching which relies upon inlining

to remove unnecessary method calls. We will use a

similar approach in Amniote to prefetch third-party

library classes.

Zaparanuks et. al present a Markov predictor

for speculative class-preloading (Zaparanuks et al.,

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

2007). Using a Markov predictor allows accurate

prediction of which classes should be preloaded and

when is the best time to do so. A similar approach is

taken by (Fulton, 2016). While these are novel and

robust methods, they only preload classes available

in the application. Android apps have the capability

of linking to third-party libraries in external jar ﬁles

which would have to be located and extracted ﬁrst.

3.2 Dalvik VM Prefetching

In Android’s Dalvik VM, the class ﬁles are precom-

piled into bytecode or native code and packaged into

DEX, OAT, APK, or JAR ﬁles. This provides the ex-

ecutable resources in a compressed format that saves

space on resource-limited mobile devices.

The Android Runtime (ART) executes Android

apps quite differently from traditional Java applica-

tions. Primarily, ART is typically executing many

apps, via Dalvik VMs, concurrently. Each time an

app references a new class it results in a compulsory

miss, requiring all needed class data to be copied into

the process’s virtual memory.

Unlike the previous implementations the Dalvik

VM contains a naive prefetching mechanism, initiated

by the zygote process, to mitigate these compulsory

misses. A ﬁle containing common Android and javax

runtime classes, preloaded-classes is read by the zy-

gote when preloading. The preload-classes text ﬁle

is created by running class dependency analysis on a

stock set of applications. These preloadable classes

are contained in a precompiled system boot image,

boot.art. While this sufﬁces for executing stock apps,

it does not fully exploit the frequency of third-party

library classes.

ClassLoaders provide the opportunity to load fr-

om third-party libraries dynamically. Maly et. al uti-

lized ClassLoaders to dynamically load modules in

Android apps (Maly and Kriz, 2015). They posit that

Android apps can contain the main application logic

while business logic, which is often changing, can be

dynamically loaded in a context-aware adaptable en-

vironment. This allows changes to be continuously

deployed on the device without any user interaction,

such as through manually upgrading the application

through the Play Store.

These previous works demonstrate preloading and

dynamic loading of Java libraries via ClassLoaders.

Yet there is an untapped opportunity for optimization

with third-party libraries. This paper is an attempt

to address this issue by employing a novel frame-

work, Amniote, which decreases overall cache com-

pulsory misses by preloading commonly used library

classes. But since the number of overlapping libraries

is constantly changing based on the user’s application

preferences, it is difﬁcult to determine which library

classes should be preloaded. Therefore, Amniote pro-

vides a dynamic preloading mechanism to user space

so developers can exploit app category proﬁles. Our

proﬁles are constructed based on app categories such

as games, internet, and navigation, but could be based

on any suite of apps.

4 ANDROID ZYGOTE PROCESS

The Android Runtime (ART) uses Dalvik VMs to

execute application code. When the device ﬁnishes

booting, the ﬁrst process to start is the Zygote process.

The zygote process then starts the preloading mech-

anism discussed in section 3.2. The zygote process

then acts as a server, responding to incoming requests

to launch applications, and forking virtual machines

to fulﬁll the requests.

When a new process is forked, the boot class-

path contains the app code along with the zygote’s

boot.art. Since applications are stripped of the com-

mon Android runtime libraries, they are instead found

in boot.art when an Android runtime class is refer-

enced.

Android’s Linux kernel is responsible for per-

forming the copy-on-write when an application tries

to write data to the boot.art space. Since the virtual

memory address (VMA) of the boot.art data is marked

as read-only, a write is redirected to an anonymous

VMA owned by the application. Any consecutive

reads would then be performed with the anonymous

VMA instead of the zygote’s boot.art VMA.

Using a copy-on-write mechanism allows the co-

mmon classes to be initially shared by any applica-

tions, at the expense of copying a page when a write

occurs. Initially, this requires a much lower amount

of memory for all the applications to access these

classes. However, as the number of unique page

writes increases, the memory required will increase

since each application maintains its own copies. The

worst case scenario is every application performs a

complete copy of the entire class. Then the read-only

copy managed by the zygote is eventually useless and

still held in memory. Therefore, copy-on-write must

be used carefully to avoid such a scenario.

Amniote: A User Space Interface to the Android Runtime

Figure 1: Distributions of Third-Party Classes across App Categories.

5 THIRD-PARTY LIBRARY

ANALYSIS

The Amniote framework operates on the basis that

many third-party libraries are depended on by many

different applications. In order to determine this, we

analyzed a large dataset of open-source apps pulled

from fdroid.org (fdr, 2018). Each app was sorting

into one of the following 16 categories: Connectiv-

ity, Games, Graphics, Internet, Money, Multimedia,

Navigation, Phone & SMS, Reading, Science & Edu-

cation, Security, Sports & Health, System, Theming,

Time, and Writing. Using the AOSP tool, dexdump,

we determined the third-party library classes required

by each app. Each library class was counted over all

apps in each category.

Figure 1 shows the resulting probability distri-

butions of third-party library classes being refer-

enced in apps across 16 app categories. While

a third-party class is only used by 17.8% of ap-

ps in each category on average, several classes

are used by the majority of apps in a category.

For example, the android.support.v4.app.Fragment

class is reference by 66% of the apps in the In-

ternet category. This class provides functional-

ity for displaying a portion of an Activity’s user

interface (Android, 2018g). Additionally, the

android.support.v4.view.ViewPager$SavedState class

has a probability of 64% being referenced in Sports

& Health apps.

By splitting the apps into categories, we can create

app category “proﬁles”. These proﬁles will contain

a precompiled list of classes with a high-probability

of reference for a given category. Category pro-

ﬁles could be used by vendors or developers to cre-

ate app launchers or lock screens that preload com-

mon classes. For example, a user frequently uses

Internet-based applications such as Google Chrome

and Gmail. The user could then switch to an Inter-

net app launcher that preloads the Internet category

proﬁle. The categories do not necessarily have to be

exclusive either. A category could pertain to a speciﬁc

user’s morning routine. For example, checking a mes-

saging app, followed by an email app, followed by a

news feed app. Since the app classes are available

before runtime, the preload classes candidates can be

selected ahead-of-time either ofﬂine or on the device.

6 APPLICATION EXECUTION

ANALYSIS

The current Dalvik VM utilizes copy-on-writes to du-

plicate modiﬁed pages to the app’s virtual address

space before applying changes. While preloading

classes reduces compulsory cache misses, there is a

tradeoff with memory consumption as the ratio of

CoWs to page accesses increases. The greater the ra-

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

Figure 2: Ratio of Page Access and CoW Operations Per Benchmark.

tio, the more apps will produce local page copies and

less references will be made to the shared page. In

order to evaluate the CoW-to-page access ratio, we

analyze the execution of apps in the Agave Android

benchmark suite (Brown et al., 2016). The Agave

benchmark suite provides 14 apps across multiple app

categories.

The Agave benchmarks were executed on Android

with a modiﬁed Linux kernel 3.14 using a modiﬁed

Gem5 simulator (Binkert et al., 2011). The Linux ker-

nel was modiﬁed to support gem5 operations and pro-

vide size information for different kernel structures.

The gem5 simulator was modiﬁed to monitor for page

access and CoW operations.

The total number of page access and copy-on-

write operations were calculated for each benchmark.

Figure 2 shows the ratio of the page access operations

to CoW operations per Agave benchmark app. The

percentage of CoW operations is consistent in each

benchmark at roughly 10%. This indicates that on av-

erage an app only copies 10% of the memory from the

shared boot classpath. Clearly the remaining 90% of

shared memory accesses can be exploited by preload-

ing the shared memory. The app category proﬁles dis-

cussed in Section 5 can be used to determine which

classes to preload into shared memory.

7 THE AMNIOTE FRAMEWORK

In this section, we describe the implementation and

capabilities of the Amniote framework.

Amniote is implemented as a userspace layer over

the Zygote

. The Amniote framework is implemented

over the AOSP Android 6.0.1 written primarily in

C++, with the userspace library implemented in Java.

The purpose of the Amniote framework is to man-

age a secondary shared address space that can be ma-

nipulated from userspace, unlike the Zygote shared

address space which is read-only after the Zygote pro-

cess is initialized. From the perspective of the Dalvik

VMs, there will still be a single boot classpath to

ﬁnd system libraries. Amniote modiﬁes the secondary

address space by communicating with the Zygote’s

socket. When Amniote sends an add image or remove

image command to the Zygote socket, it also sends

the path to the image ﬁle. The Zygote process has

been modiﬁed to append this image to the secondary

boot classpath. Similarly, when a preload or unload

command is sent, the classSignature is also sent, and

then either preloaded or unloaded, respectively, using

the method currently available for the ﬁrst boot class-

path.

Amniote is initialized as the system server is

started by the Zygote. Upon creation, a secondary

shared address space is created and added to the de-

fault bootpath. Figure 3 shows the basic Amniote

framework ﬁelds and methods. From user space,

apps can get an instance of Amniote by executing

Amniote.getInstance(). Then an app can add or re-

move a DEX, JAR, APK, or OAT image to Amniote’s

classpath with addImage(..) or removeImage(...), re-

spectively. Adding an image checks that the image

The Amniote framework is named after the biological

term amniotic sac which contains the embryo after the zy-

gote implants in the uterus.

Amniote: A User Space Interface to the Android Runtime

Figure 3: Amniote Framework.

ﬁle exists before appending to the classpath. Next,

preload(...) or unload(...) can be called to preload or

unload a speciﬁc class, respectively. Once a class is

preloaded, a reference from any app will ﬁnd the class

in the shared address space as if it were preloaded by

the zygote process. If an application makes a write to

a page in the shared address space, it will perform a

copy into the apps’s address space through the Linux

copy-on-write mechanism.

Figure 4: Example of the Amniote Framework.

Figure 4 shows an example usage of the Amniote

framework. In step 1, the device boots up, starting

the zygote process. The zygote process initializes the

bootclasspath and preloads the default classes. In step

2, two different apps are launched, each containing

their own classpaths, but also sharing the bootclass-

path. In step 3, App 1 adds a local apk to the shared

bootclasspath. Next, the Fragment class is preloaded.

In step 4, a third app is launched. Three running

apps can reference any of the preloaded classes in the

shared bootclasspath, including the Fragment class

preloaded by App 1. Additionally, each app can still

access their private classpaths. Finally, in step 5, App

1 removes the Fragment class the local apk. Note that

App 1 adds and removes the local image ﬁle because

the image is in a private directory. However, if the im-

age is in a directory readable by any process, such as

on the sdcard, then any app could add or remove the

image to the bootclasspath.

One side effect of using Amniote is that APKs

do not need to include external libraries. Com-

mon libraries such as com.android.support.* and

com.google.android.material.* which are frequently

utilized in applications need only be stored on the de-

vice once. This greatly reduces APK code size and

disk utilization on the device. Furthermore, it solves

the common method count limit when targeting older

APIs. In order to support this, libraries are stripped

out from the APK via Proguard during packaging and

deployed through the mechanisms discussed in Sec-

tion 9.

8 AMNIOTE ANALYSIS

The beneﬁts of the Amniote Framework are most

prevalent when multiple apps are running that utilize

the same classes. Amniote can preload the overlap-

ping classes to reduce memory usage.

In order to test the effectiveness of the Amniote

Framework, we evaluated the third-party library us-

age across 9 apps which were hand-classiﬁed into

three different categories (TeamAmaze, 2019; fed-

ericoiosue, 2019; k9mail, 2019; byoutline, 2018;

TeamNewPipe, 2019; nickbutcher, 2019; Antenna-

Pod, 2019; esoxjem, 2018; videolan, 2019). Ta-

Table 1: A suite of benchmarks classiﬁed into categories.

Category Benchmark Description

Phone & SMS

AmazeFileManager

Show ﬁles and directories

in root directory of sdcard.

Omni Notes

Create and save new

checklist with a single item.

K9 Mail

Attempt to login with

sample username and password.

Internet

Kickstarter

Display list of sample

kickstarter campaigns.

NewPipe

Fetch and display list

of recent Youtube videos.

Plaid

Fetch and display recent

blog posts about material design.

Multimedia

AntennaPod

Fetch and display list of available

podcasts and select an item.

MovieGuide

Fetch and display list of recent

movies and select an item.

VLC Play sample 5 second video.

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

Table 2: The total and overlapping library class count for

each category and the total size of the duplicated classes in

bytes.

Category

Total Library

Class Count

Overlapping Library

Class Count

Size of Duplicated

Classes (in B)

Productivity 2318 27 126054

Social 5014 97 3388

Media 2451 205 6986

ble 1 shows the benchmark apps in each category

and provides a description of each benchmark. The

benchmarks were selected based on releasing versions

within the last year and utilizing third-party libraries.

Additionally, we only chose apps for a category that

provide unique functionality and would likely be run

sequentially by the user. For example, consider the

Productivity category consisting of AmazeFileMan-

ager, Omni Notes, and K9 Mail. A user might cre-

ate a todo list with Omni Notes, and then open a ﬁle

in AmazeFileManager, and ﬁnally share that ﬁle over

email via K9 Mail. When a user sequentially runs

apps, the Android Runtime maintains the virtual ma-

chine running each app unless the user explicitly exits

the app or the device runs out of resources required to

run the app. Therefore, it is probable to have multiple

running apps in the same category.

Since the effectiveness of Amniote is determined

by the number of accesses to overlapping third-party

libraries, we modiﬁed the Android OS to log every

access to a library class.

Each benchmark app was executed on the modi-

ﬁed Android OS using the Android Emulator. Then,

for each category, the total set of third-party library

classes and the union set of third-party library classes

were determined. Table 2 shows the total third-party

library class count and the overlapping third-party li-

brary class count for each category. The table shows

between 1.9% and 8.3% of third-party classes are du-

plicated across each category. The more interesting

result is the amount of memory consumed by dupli-

cate classes. For example, in the Productivity cate-

gory, the 27 classes that overlap result in 123 KB of

unnecessary memory consumption that would be pre-

vented by Amniote.

While the results of our experiment demonstrate

a beneﬁt for employing the Amniote Framework, our

benchmarks were designed to perform a single task.

Real-world users are likely to use an app to do more

than one task. In fact, as a user runs more concur-

rent apps, the Amniote Framework could potentially

reduce total memory usage even further.

9 DISCUSSION

In section 2, we discussed how Java ClassLoaders can

load non-unique classes as long as they are contained

in different package namespaces. This produces a

unique ClassLoader entry for each class in each pack-

age namespace. However, since third-party libraries

are compiled directly into Android apps, the apps on

a device may depend on conﬂicting library versions.

Since each Dalvik VM uses an local app ClassLoader

to resolve these library classes, there are currently no

issues. But when the library classes are linked via the

system ClassLoader instead of the app ClassLoader,

non-unique classes will produce a conﬂict.

The current Amniote implementation has no ver-

sion control for libraries. In other words, it is assumed

that the libraries shared amongst applications are all

using the exact same version. Yet this is rarely the

case. We present three possible solutions to the ver-

sioning problem, each putting the responsibility on a

different party with different levels of practicality.

The ﬁrst possibility is for the Play Store to per-

form library dependency analysis and to hold or lock

new app versions until all the apps using a speciﬁc li-

brary use the same version. This puts the onus of ver-

sion control on the Google Play Store. For example,

App A and App B rely on a library. App A releases a

new version that depends on library version 2.0, while

App B depends on library version 1.0. The Play Store

would hold App A until App B releases a new version

depending on library version 2.0. Clearly this would

cause many problems. If the developers for App B

never released a new version, App A would never be

released. It is simply too impractical to rely on the

continuous deployment cycles of apps.

The second possibility is for Amniote to perform

the library dependency analysis to ﬁnd the great-

est overlapping version numbers of each library and

only include those library versions when prefetching.

While this solves the problem of library compatibility

and eliminates any responsibility from app and library

developers, it signiﬁcantly decreases the effective-

ness and greatly increases the complexity of Amniote.

Every image that is added to Amniote requires re-

running dependency analysis, adding additional run-

time and memory requirements. Furthermore, many

potential libraries could be excluded due to a version

mismatch. In extreme cases, an image may contain all

version mismatches and be completely incompatible.

The ﬁnal and most practical solution is to provide

library support in the Google Play Store. Having the

Play Store support libraries would share the responsi-

bility between the library and Google Play Store de-

velopers, instead of the app developer. As long as the

Amniote: A User Space Interface to the Android Runtime

library has backwards compatibility, new versions can

be deployed on the Play Store and automatically up-

dated via the Play Store update protocol. The Google

Play Store could also provide support for live updates

by simply having Amniote reload any classes imple-

mented by the new library, which would be immedi-

ately reﬂected in individual apps. Linking libraries

through the Google Play Store has the added bene-

ﬁt of security. Since all applications now utilize the

same library version, it is easier to ensure the library

is directly from the vendor and has not been tampered.

10 CONCLUSION AND FUTURE

WORK

In this paper we discussed the growing dependency

of third-party libraries in Android apps. We demon-

strated that many third-party library classes are ref-

erenced by the majority of apps in their speciﬁc app

category. We then showed that the probability distri-

bution of third-party classes can be used to construct

an app category proﬁle which statistically informs our

decision to preload a given class.

Next we evaluated the execution of apps in the

Agave benchmark suite on a modiﬁed gem5 simu-

lator. The simulations demonstrated that only a rel-

atively small proportion of operations are copy-on-

writes compared to page accesses.

Finally we introduced the Amniote framework, a

user-space interface to the Dalvik VM. Amniote pro-

vides a simple interface for dynamically adding and

removing a variety of image ﬁles to the shared boot

classpath, as well as preloading or unloading spe-

ciﬁc classes. This framework provides developers and

vendors greater opportunity for ﬁne-tuning a device

based on user preferences.

In the future we plan to extend the Amniote frame-

work with several additional features.

First, we will deﬁne a ﬁle format for the app cate-

gory proﬁles and provide direct support for these ﬁles.

Then the preloading would be performed automati-

cally by providing the image ﬁle and the proﬁle ﬁle.

Second, we plan to provide support for resource

ﬁles in addition to classes. The naive preloader in the

Dalvik zygote process preloads classes and resource

ﬁles, which Amniote can easily extend.

Third, our evaluations used a large, but static

dataset of benchmark apps for selecting preloading

class candidates. In reality, a user may have more

variability in the apps executed such that the user may

run apps across multiple categories in a single session.

In order to target this use case, machine learning could

be utilized to dynamically build the category proﬁles.

Finally, we plan to develop the Library Play Store

discussed in Section 9. One beneﬁt of Amniote is that

app developers no longer need to focus on third-party

libraries. Library version updates and library version

interdependencies are no longer a concern since the

libraries are stripped from the APK and installed in-

dependently.

The Library Play Store would provide a single

repository for libraries which would additionally add

security and a possibility for live updates. This would

move Android development one step closer to liquid

software deployment, a conceptual goal of continuous

deployment proposed by Gallidabino et. al (Gallid-

abino et al., 2017). Each entity involved in the ﬁnal

product, the app developers and the library develop-

ers, could independently deploy updates without con-

cerning themselves with the updates of dependencies.

REFERENCES

(2018). F-droid. https://f-droid.org/en/. Online; accessed

30-April-2018.

Android (2018a). Android AppCompat Library V7.

https://mvnrepository.com/artifact/com.android.

support/appcompat-v7. Accessed: 2018-11-26.

Android (2018b). Android Room Compiler.

https://mvnrepository.com/artifact/android.arch.

persistence.room/compiler. Accessed: 2018-11-26.

Android (2018c). Android Room Runtime.

https://mvnrepository.com/artifact/androidx.room/

room-runtime. Accessed: 2018-11-26.

Android (2018d). Android Support Library Annotations.

https://mvnrepository.com/artifact/com.android.

support/support-annotations. Accessed: 2018-11-26.

Android (2018e). Android Support Library V4.

https://mvnrepository.com/artifact/com.android.

support/support-v4. Accessed: 2018-11-26.

Android (2018f). Android Support RecyclerView

V7. https://mvnrepository.com/artifact/com.android.

support/recyclerview-v7. Accessed: 2018-11-26.

Android (2018g). Fragments — Android Developers.

https://developer.android.com/guide/components/

fragments. [Online; accessed 2018-11-26].

AntennaPod (2019). AntennaPod. https://github.com/

AntennaPod/AntennaPod. [Online; accessed 20-Feb-

2019].

Binkert, N., Beckmann, B., Black, G., Reinhardt, S., Saidi,

A., Basu, A., Hestness, J., Hower, D., Krishna, T., Sar-

dashti, S., Sen, R., Sewell, K., Shoaib, M., Vaish, N.,

Hill, M., and Wood, D. (2011). The gem5 simula-

tor. ACM SIGARCH Computer Architecture News,

39(2):1–7.

Brown, M., Yannes, Z., Lustig, M., Sanati, M., McKee,

S., Tyson, G., and Reinhardt, S. (2016). Agave: A

benchmark suite for exploring the complexities of the

android software stack. In Performance Analysis of

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

Systems and Software (ISPASS), 2016 IEEE Interna-

tional Symposium on, pages 157–158. IEEE.

byoutline (2018). Kickmaterial. https://github.com/

byoutline/kickmaterial. [Online; accessed 20-Feb-

2019].

Cahoon, B. and McKinley, K. S. (1999). Tolerating latency

by prefetching java objects. In Workshop on Hard-

ware Support for Objects and Microarchitectures for

Java. Citeseer.

esoxjem (2018). MovieGuide. https://github.com/

esoxjem/MovieGuide. [Online; accessed 20-Feb-

2019].

federicoiosue (2019). Omni-Notes. https://github.com/

federicoiosue/Omni-Notes. [Online; accessed 20-Feb-

2019].

Fulton, M. S. (2016). Conservative class preloading for real

time java execution. US Patent 9,477,495.

Gallidabino, A., Pautasso, C., Mikkonen, T., Syst

a, K.,

Voutilainen, J.-P., and Taivalsaari, A. (2017). Archi-

tecting liquid software. J. Web Eng., 16(5&6):433–

470.

Google (2018a). Dagger. https://mvnrepository.com/

artifact/com.google.dagger/dagger. Accessed: 2018-

11-26.

Google (2018b). Firebase Database.

https://mvnrepository.com/artifact/com.google.

ﬁrebase/ﬁrebase-database. Accessed: 2018-11-26.

Google (2018c). Firebase Firestore.

https://mvnrepository.com/artifact/com.google.

ﬁrebase/ﬁrebase-ﬁrestore. Accessed: 2018-11-26.

k9mail (2019). K-9. https://github.com/k9mail/k-9. [On-

line; accessed 20-Feb-2019].

Katariya, J. (2017). Apple Vs. Android.

https://android.jlelse.eu/apple-vs-android-a-

comparative-study-2017-c5799a0a1683. [Online;

accessed 1-August-2018].

Liang, S. and Bracha, G. (1998). Dynamic class loading

in the java virtual machine. Acm sigplan notices,

33(10):36–44.

Luk, C.-K. and Mowry, T. C. (1996). Compiler-based

prefetching for recursive data structures. In ACM

SIGOPS Operating Systems Review, volume 30,

pages 222–233. ACM.

Maly, F. and Kriz, P. (2015). Techniques for dynamic de-

ployment of modules in context-aware android appli-

cations. In Computational Intelligence and Informat-

ics (CINTI), 2015 16th IEEE International Sympo-

sium on, pages 107–111. IEEE.

nickbutcher (2019). Plaid.

https://github.com/nickbutcher/plaid. [Online;

accessed 20-Feb-2019].

Peters, A. (2017). How Android Differs De-

pending on the Hardware Manufacturer.

https://www.makeuseof.com/tag/android-differs-

hardware-manufacturer/. Accessed: 2018-11-26.

TeamAmaze (2019). AmazeFileMan-

ager. https://github.com/TeamAmaze/

AmazeFileManager. [Online; accessed 20-Feb-

2019].

TeamNewPipe (2019). NewPipe. https://github.com/

TeamNewPipe/NewPipe. [Online; accessed 20-Feb-

2019].

videolan (2019). VLC. https://github.com/videolan/vlc.

[Online; accessed 20-Feb-2019].

Wikipedia (2018). Android version history.

https://en.wikipedia.org/wiki/Android version history.

[Online; accessed 2-April-2018].

Zaparanuks, D., Jovic, M., and Hauswirth, M. (2007). The

potential of speculative class-loading. In Proceed-

ings of the 5th international symposium on Principles

and practice of programming in Java, pages 209–214.

ACM.

Amniote: A User Space Interface to the Android Runtime