
NSF Org: |
CNS Division Of Computer and Network Systems |
Recipient: |
|
Initial Amendment Date: | August 2, 2016 |
Latest Amendment Date: | May 29, 2018 |
Award Number: | 1618531 |
Award Instrument: | Standard Grant |
Program Manager: |
Marilyn McClure
mmcclure@nsf.gov (703)292-5197 CNS Division Of Computer and Network Systems CSE Directorate for Computer and Information Science and Engineering |
Start Date: | August 1, 2016 |
End Date: | July 31, 2020 (Estimated) |
Total Intended Award Amount: | $472,444.00 |
Total Awarded Amount to Date: | $486,444.00 |
Funds Obligated to Date: |
FY 2018 = $14,000.00 |
History of Investigator: |
|
Recipient Sponsored Research Office: |
520 LEE ENTRANCE STE 211 AMHERST NY US 14228-2577 (716)645-2634 |
Sponsor Congressional District: |
|
Primary Place of Performance: |
NY US 14260-2500 |
Primary Place of
Performance Congressional District: |
|
Unique Entity Identifier (UEI): |
|
Parent UEI: |
|
NSF Program(s): |
Special Projects - CNS, CSR-Computer Systems Research |
Primary Program Source: |
01001819DB NSF RESEARCH & RELATED ACTIVIT |
Program Reference Code(s): |
|
Program Element Code(s): |
|
Award Agency Code: | 4900 |
Fund Agency Code: | 4900 |
Assistance Listing Number(s): | 47.070 |
ABSTRACT
Openness is a key to innovation. Numerous areas in computer science and other disciplines have embraced openness and witnessed an explosion of new technological advances. This proposal argues that mobile platforms (such as Android and iOS) need to embrace openness as well. This is motivated by the fact that the current mobile platforms are mostly closed and do not allow third-party innovation, making it extremely difficult to introduce disruptive technologies. This can be observed easily by examining the most open mobile platform, Android. Android is regarded as an open platform since its source code is open. However, it is indeed a closed platform from the perspective of open innovation; this is because a small, independent third party has no easy way to modify the platform and distribute the modification at a large scale to end users. Only a select few, such as Google and Samsung, have the power to modify the platform and deliver it.
Recognizing such a problem, this project proposes a new technique called API virtualization that enables open innovation in mobile platforms. API virtualization allows third-party developers to modify, reimplement, or customize platform APIs and deploy the modifications seamlessly. The uniqueness of the proposed technique is that it enables modifications completely at the app layer without requiring any platform-level changes. This allows practical openness---third parties can easily distribute their modifications for a platform without the need to update the entire platform.
If successful, this project will produce (1) a working prototype that implements API virtualization on Android, (2) several case-study systems that leverage API virtualization and provide better functionality such as app anonymity, automatic mobile-cloud integration, and energy policy customization, and (3) a Web service where third-party developers upload their platform API modifications that end users can download and use.
PUBLICATIONS PRODUCED AS A RESULT OF THIS RESEARCH
Note:
When clicking on a Digital Object Identifier (DOI) number, you will be taken to an external
site maintained by the publisher. Some full text articles may not yet be available without a
charge during the embargo (administrative interval).
Some links on this page may take you to non-federal websites. Their policies may differ from
this site.
PROJECT OUTCOMES REPORT
Disclaimer
This Project Outcomes Report for the General Public is displayed verbatim as submitted by the Principal Investigator (PI) for this award. Any opinions, findings, and conclusions or recommendations expressed in this Report are those of the PI and do not necessarily reflect the views of the National Science Foundation; NSF has not approved or endorsed its content.
The primary goal of the project is studying API virtualization on Android. API virtualization allows developers to intercept an Android API call and execute an arbitrary piece of code, which is useful in extending the capability of Android. For example, using API virtualization, a developer can intercept a storage write API call, and perform a write not only to the local storage but also to a cloud service for backup.
To comprehensively study API virtualization on Android, we have sought to answer the following three questions.
- Is it possible to enable API virtualization on Android (feasibility)?
- Is API virtualization useful on Android (applicability)?
- Can API virtualization be done correctly so we can deploy it for regular apps (deployability)?
For each question, we have developed prototypes that demonstrate the capability. Through these prototypes, we have shown that API virtualization is indeed feasible, applicable, and deployable on Android. We summarize these prototypes and our findings below.
Feasibility of API Virtualization
To demonstrate the feasibility of API virtualization, we have developed a prototype called Reptor and published a paper on it (MobiSys'17). Reptor demonstrates that it is possible to enable API virtualization with low overhead using bytecode instrumentation. Reptor analyzes an Android app's bytecode and statically detects all possible API calls that the app makes within its code. Reptor can then statically rewrite API calls in a way that the calls are redirected to an injected piece of code, enabling API virtualization. In implementing Reptor, we have overcome several challenges including correctly handling Java-language features such as sub-typing, polymorphism, and callbacks.
We have instrumented 1,200 apps downloaded from Google Play using Reptor and performed automated testing to verify correctness of our implementation. Our paper also discusses various use cases and performance results. Our findings are that Reptor enables API virtualization with low performance overhead in terms of call latency, memory usage, and energy consumption.
Applicability of API Virtualization
To demonstrate the applicability of API virtualization, we have developed two systems, BlueMountain (MobiCom'17) and Gesto (EICS'19) that uses API virtualization to enable functionality that was not previously possible on Android.
Our first system, BlueMountain, imagines a world where there are two types of developers. One type is regular developers who write mobile apps. The other type is what we call data management app developers who develop and write innovative data management solutions for mobile apps. For example, they could develop a solution that automatically backs up app data to a cloud, or a solution that automatically shares app data among a group of users. The innovation of BlueMountain is that it allows these data management solutions to be developed as regular Android apps, which means that data management solutions can be distributed using standard channels such as Google Play. BlueMountain can then take a data management app and "combine" it with a regular app so that a regular app can execute the data management solution. We use API virtualization as the basis to accomplish this; using API viritualization, we intercept all storage API calls and execute the code provided by a data management app. Our website (http://bluemountain.cse.buffalo.edu/) has a video clip that describes how BlueMountain works.
Our second system, Gesto, is a system that enables task automation for Android apps using gestures and voice commands. Gesto allows a user to record a sequence of UI actions for an app, choose a gesture or a voice command to activate the UI action sequence, and later trigger the UI action sequence by the corresponding gesture/voice command. Gesto uses API virtualization to implement UI action record-and-replay.
These two systems demonstrate that by using API virtualization, we can add new and innovative functionality to Android that was previously not possible.
Deployability of API Virtualization
We have developed a system called Mimic (ICSE'19) that demonstrates the deployability of API virtualization. Mimic tests the correctness of API virtualization for an app to ensure that the app is ready for deployment.
Initially, Mimic was developed to evaluate our prototypes for Reptor, BlueMountain, and Gesto. However, it evolved into a more general system that enables what we call UI compatibility testing. UI compatibility testing compares and contrasts two different versions of the same app by automatically and programmatically interacting with the UI of the app. For API virtualization, Mimic tests an app before and after instrumentation, and shows the differences between the two versions.
Conclusion
We have developed Reptor, BlueMountain, Gesto, and Mimic to comprehensively study API virutalization on Android. Our publications on these systems describe how to implement API virtualization using bytecode instrumentation (Reptor), how we enable new functionality that was previously not possible using API virtualization (BlueMountain and Gesto), and how we can test the correctness of our API virtualization (Mimic). Collectively, these systems show that API virtualization is feasible, applicable, and deployable on Android.
Last Modified: 09/09/2020
Modified by: Steven Y Ko
Please report errors in award information by writing to: awardsearch@nsf.gov.