Mobile Plus: Multi-device Mobile Platform for Cross-device Functionality Sharing Plus: Multi-device Mobile Platform for Cross-device Functionality Sharing Sangeun Oh, Hyuck Yoo, ... di erent devices. M+ detects reference-type arguments in

  • Published on

  • View

  • Download


<ul><li><p>Mobile Plus: Multi-device Mobile Platform for Cross-deviceFunctionality Sharing</p><p>Sangeun Oh, Hyuck Yoo, Dae R. Jeong, Duc Hoang Bui, and Insik ShinSchool of Computing, KAISTDaejeon, Republic of Korea</p><p>{ohsang1213, yoohuck12, dragon812, ducbuihoang, insik.shin}</p><p>ABSTRACTIn recent years, the explosion of diverse smart devices such asmobile phones, TVs, watches, and even cars, has completelychanged our lives. We communicate with friends throughsocial network services (SNSs) whenever we want, buy stuffwithout visiting shops, and enjoy multimedia wherever weare, thanks to these devices. However, these smart devicescannot simply interact with each other even though they areright next to each other. For example, when you want to reada PDF stored on a smartphone on a larger TV screen, youneed to do complicated work or plug in a bunch of cables.In this paper, we introduce M+, an extension of Androidthat supports cross-device functionality sharing in a trans-parent manner. As a platform-level solution, M+ enablesunmodified Android applications to utilize not only appli-cation functionalities but also system functionalities acrossdevices, as if they were to utilize them inside the same de-vice. In addition to secure connection setup, M+ also allowsperforming of permission checks for remote applications inthe same way as for local. Our experimental results showthat M+ enables transparent cross-device sharing for var-ious functionalities and achieves performance close to thatof within-device sharing unless a large amount of data istransferred.</p><p>CCS ConceptsGeneral and reference Design; Human-centeredcomputing Mobile computing; Mobile devices;Collaborative interaction; Software and its engineering Operating systems; Communications management;</p><p>KeywordsMulti-device Mobile Platform; Functionality Sharing; Re-mote Procedure Call; Inter-Process Communication;</p><p>Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from</p><p>MobiSys17, June 19-23, 2017, Niagara Falls, NY, USA 2017 ACM. ISBN 978-1-4503-4928-4/17/06. . . $15.00</p><p>DOI:</p><p>1. INTRODUCTIONThe mobile app ecosystem continues to grow and ma-</p><p>ture rapidly, and offers a wide variety of services, such asSNS, shopping, entertainment, and healthcare. Mobile ap-plications have become complex and diverse, and they havecome to use the functionalities1 of other applications or sys-tem services. At the same time, users own multiple mobiledevices. A recent survey reported an average of more thanthree devices per person [1], and users are easily temptedto use on each device the functionalities available on otherdevices.</p><p>Such trends present exciting opportunities for multiplesmart devices to be used together, including (1) video con-ferencing on a camera-less smart TV using a smartphonescamera, (2) secure internet shopping on an unsecured pub-lic device using payment service from ones own privatesmartphone, (3) replying to an email on a smartphone whilescrolling through its attached documents on a tablet, anddoing copy and paste between the two devices, and (4) play-ing sensor-based games on a tablet while using sensors froma smartphone, which can provide a more convenient methodto control them.</p><p>Many solutions have been proposed to enable this excitingopportunity. First, many interesting studies have been doneto use the resources of other devices through the cooperationof applications. Many apps [26, 32, 6, 7, 15, 31] are avail-able for sharing specific resources, including screen casting,cameras, and sensors. However, their applicability is quitelimited, because they work with their own custom applica-tions but do not support unmodified applications. This im-poses a great burden on those wanting to develop and deploysuch applications for each individual resource or functional-ity. Second, a great deal of work [39, 14, 27, 37, 22, 23, 13,21, 4, 42] has been done to develop a cross-device platformthat enables unmodified applications to use the resourcesof other devices. However, these mainly focus on utilizingsystem resources such as sensors and cameras but do notsupport application functionalities such as in-app paymentand SNS login.</p><p>Here, we present a novel platform M+ (Mobile Plus). Themain goal of M+ is to allow unmodified applications to sharea wide range of functionalities across devices. That is, oursystem is intended to be insensitive to the type of func-</p><p>1In this paper, we define functionality as a collection of ser-vices, features, content, and resources. We classify function-alities into two categories according to their providers: ap-plication functionalities offered by applications, and systemfunctionalities by Android system services.</p><p>332</p><p></p></li><li><p>tionality, and with no extra burden of application develop-ment. To achieve the design goal, M+ extends the exist-ing remote procedure call (RPC) scheme and its underly-ing binder inter-process communication (IPC) mechanismto multi-device environments. In other words, our key ideais to intercept RPC messages (binder parcels) from a clientdevice and forward them to a server device to execute RPCfunction logic. This approach suits our design goal for tworeasons. First, to the best of our knowledge, all existing ap-plications are using RPCs to utilize the functionalities ofother applications or system services. Therefore, extendingthe RPC scheme will naturally enable support of both ap-plication and system functionalities in the multi-device en-vironment. Second, RPC is transparent to the applicationlayer because it is supported at the platform layer. There-fore, the RPC extension does not require modification ofapplications.</p><p>M+ should address several fundamental challenges in ex-tending within-device RPC to cross devices because Androidis designed under the assumption that client and server pro-cesses run on the same device. (i) Android allows passageof various type of references or handles as RPC parame-ters, including shared memories, sockets, binders, and files,for better performance. However, passing RPC argumentsin a call-by-reference manner does not work properly acrossdifferent devices. M+ detects reference-type arguments ina functionality-agnostic way and makes their values avail-able transparently between devices. (ii) Android app man-agement logic will not work properly in the multi-deviceenvironment: it cannot manage execution context and se-mantics (e.g., app lifecycles, caller-callee information) of appbeyond the device boundary. Hence, M+ addresses this un-precedented issue based on the concept of virtual activityto enable unmodified applications to execute on differentdevices without having their interaction semantics violated,while incurring little change to Android system services. (iii)The Android assumption that there is only one instance ofan application will not hold. Because each device can have itsown resident app, there could exist multiple instances of thesame app when multiple devices are joined for functionalitysharing. For this reason, M+ leverages the notion of remoteapp registration to manage multiple instances properly forcorrect security checks and communication support.</p><p>We proved the M+ concept with a prototype using Nexus6 (smartphone) and Nexus 10 (tablet)2. It was demonstratedthat M+ allows existing applications on different devicesto successfully share functionalities such as Facebook Lo-gin, Google Market Payment, Android Contacts, and PDFViewer; as well as system features (camera, sensor, notifi-cation and clipboard). Interestingly, all these sharing pro-cesses do not incur significant performance overhead andbehave almost like sharing within the same device in mostcases, unless they require transfer of a large amount of data.The details about the experiment will be discussed in latersections. In addition, it is worth noting that even if hetero-geneous types of devices interact with each other, M+ caneasily support the interaction if the devices have just thesame RPC interfaces. This is possible because our systemis designed to provide functionality sharing via cross-deviceRPC regardless the type of device.</p><p>2See for our demo videoillustrating the interaction between Nexus 6 and Nexus 10.</p><p>2. USE CASESService sharing: login, payment, and notification.</p><p>M+ can change the way people utilize services across de-vices in many places. With M+, one could dispatch certainservices to designated devices or users for various reasons.For example, a user might want to log into an SNS app(e.g., Instagram) on a public device such as a free rentaltablet in a public library or a smart TV in her hotel room.This comes with a risk to privacy (e.g., social media ac-count hijacking) because public devices could have malwareor keystroke-logging software secretly installed. With M+,she can log into the SNS app securely using her Facebooklogin on her own smartphone. Moreover, a kid might feel animpulse to purchase in-game items after failing to move onto the next round in a mobile game. With M+, her mothercan be prompted to deal with the purchase order via Pay-Pal or Google Play on her smartphone. With M+, a usercould receive notifications or alarms (e.g., incoming calls,SMS messages, and low battery alarms) forwarded from asmartphone and displayed on a TV.</p><p>Contents sharing: file, contact, and calendar. M+can facilitate the way users access and interact with infor-mation between devices. When checking emails on a smart-phone, a user might want to view an attached PDF docu-ment on a larger-screen device, such as a tablet. With M+,this could be done right away with a single tap on the PDFicon on a smart watch, rather than go through a cloud stor-age service (e.g., Dropbox) or use an email client app onthe tablet. Interestingly, she could work on both devices atthe same time: write an email reply on a smartphone andscroll through the attached documents on a tablet simulta-neously. In this case, the user could also copy any part ofthe attached document on the tablet and paste it on thesmartphone. With M+, a user could run video conferencingor daily briefing apps on a TV, while accessing contact andcalendar data on her smartphone.</p><p>I/O sharing: camera. The digital world is now shiftingfrom 2D to 3D, and one great example is the success of 3Dselfie camera applications. However, in order to render 3Dimages from a single camera, the camera must take multi-ple images from different angles. Apparently, this conditionputs critical restrictions on development of many creativeuses. Instead, applications seek to construct 3D images usingmultiple cameras. In this context, M+ provides a platform-level I/O sharing so that those applications can use remotecameras easily.</p><p>3. ANDROID BACKGROUNDApplication components. Each functionality in An-</p><p>droid is implemented as one of four application components:activity, service, content provider, or broadcast receiver. anactivity represents the user interface of an application, allow-ing interaction between the application and the user. Every-thing a user sees in an application is provided by activities.For example, Facebook login activity provides a UI to al-low users to enter ID and password. a service is designedto perform long-running operations in the background. Forexample, I/O functionalities, such as camera and sensor,are provided with system services. a content provider givesan interface for storing and sharing data using a relationaldatabase (e.g. SQLite database). For instance, contact listsand calendar information are managed by content providers.</p><p>333</p><p></p></li><li><p>Client ServerStubWithin-device RPC</p><p>Android Platform</p><p>System-wide processes</p><p>Proxy</p><p>Activity manager</p><p>Service manager</p><p>Pass a proxy Register a proxy</p><p>Figure 1: Within-device RPC in Android</p><p>a broadcast receiver is for receiving system-wide messages.For example, low battery level warning is broadcast and ap-plications save their states to prevent any data loss.</p><p>Functionality sharing in Android. Android is de-signed to allow applications (processes) to share their func-tionalities through remote procedure calls (RPCs). Supposethat a client application tries to use a functionality of aserver application. Here, function sharing is achieved be-tween them if the client invokes RPC functions for the func-tionality to the server. The invocation procedure typicallyconsists of two steps. The client first forwards a message(called parcel) for calling a RPC function to the server. Uponreceiving the parcel, the server executes the RPC functionand passes the parcel containing its result to the client.</p><p>The Android RPC employs the inter-process communica-tion (IPC) mechanism managed by the binder driver, be-cause it is achieved across the process boundary. To deliverparcels from the client to the server, the binder driver cre-ates a binder connection: a route between the two processesfor the parcels. This procedure is called binding. Here, thesource and target endpoints of a binder connection are aproxy and a stub. RPC invocations are always made in onedirection: from proxy to stub.</p><p>Figure 1 shows how binding works between client andserver processes. A client first requests a proxy to Androidsystem services; then it asks the service manager to share asystem functionality or asks the activity manager to sharean application functionality. We note that each individualserver has registered its proxy to the service/activity man-ager when it is initiated. When the client obtains the proxyfrom the server/activity manager, binding is completed inone of two ways depending on the component type of serverfunctionality. The client binds to the servers component di-rectly if the component is a service or content provider, orindirectly via the activity manager if the component is anactivity. The latter allows the activity manager to mediateinteraction between the client and server activities accord-ing to their own interaction semantics. We will describe thisin more detail in Section 6.</p><p>4. SYSTEM DESIGN OVERVIEWThe main goal of M+ is to allow transparent sharing of</p><p>both application and system functionalities across multiplemobile devices. To this end, M+ should be oblivious to thetype of functionality without incurring any extra burdenof application development. M+ extends the within-deviceRPC scheme across different devices to achieve this goal.Figure 2 shows an overview of M+ consisting of these main</p><p>Client</p><p>Security Management</p><p>Server</p><p>Cros...</p></li></ul>


View more >