Remote Intent Service: Supporting Transparent Task-Oriented Collaboration for Mobile Devices

Abstract

Platform support for mobile collaboration among multiple smart devices has been an active research issues in the computing community. Using platform-level collaboration functionalities, a mobile device can share its resources, I/O events, and even apps easily with other devices, which enables developing a new kind of application that runs across multiple devices. In this work, we further extend the collaboration functionalities in mobile platforms by developing a novel platform service, remote intent service (RIS),which enables a running application in a device to outsource the execution of a specific task to another application in a remote device. Using the remote intent service, for example, we can view an attached document to an email, using a document viewer application in a remote device that has a larger screen, or conveniently browse an audio file that exists on another mobile device and play it locally. We implemented the remote intent service to the Android platform and measured the latency for executing such tasks in a remote device. The experimental results confirm that the remote intent service, for sending the intent plus retrieving the result, incurs an additional delay of less than 250 ms in total, and thus, it is practical.

1. Introduction

Mobile platforms are being used in more and more smart devices not only because of the growing number of devices but also due to the increasing diversity of device types. While they have initially been developed to be used in smartphones, they are now being used in smart televisions, tablets, watches, and even in cars for their in-vehicle infotainment systems [1]. Recent studies show that public (or shared) devices are being rapidly deployed ubiquitously so that anonymous (or a group of) users can temporarily use them at their convenience [2,3].

As a single person comes to use more than one device with possibly different types, research efforts have been aimed to synchronize data between different devices. For example, a user who paused watching a YouTube video on a smart TV has become able to resume watching it on his(her) smartphone outside of the home. As mobile platforms keep evolving, higher-level collaboration technologies have emerged to overcome the weaknesses of mobile devices including small screen size, limited battery capacity, and less powerful computing resources. Modern mobile platforms support screen sharing/mirroring to overcome the small screen size of mobile devices by enabling users to enjoy content stored in a mobile device on a smart TV [4,5]. In academia, collaboration technologies between mobile devices and cloud/edge infrastructures have been developed, under the umbrella of mobile cloud/edge computing, to overcome the limited battery and computing resources in mobile devices [6,7,8,9,10] or to guarantee the safe and secure execution of apps [11,12]. To support more explicit collaboration between mobile devices, the sharingof resources, events, or even applications among mobile devices have been developed. Through resource and event sharing, users or mobile applications in a local device can exploit computation resources or I/O events in remote devices to expand the capacity and capability of the local device [13,14,15] or to facilitate more efficient machine learning with distributed platforms across multiple devices [16,17,18]. Application sharing enables us to develop a new kind of multi-device application by offloading a portion of an application to remote devices [19]. These platform technologies have opened a new era of mobile collaboration, and the computing community is still striving to develop more effective collaboration technologies incorporating emerging smart devices.

In this work, we develop a novel system service for Android, remote intent service (RIS), that further extends the current mobile collaboration technologies. RIS supports task-oriented collaboration, which we define as delegating a particular task in a device to a remote device that best fits to execute it. An intent in Android is a messaging object that can be used to request an action to another application component [20]. It allows an application to start an activity or service even in another application in the same device, to delegate a specific functionality to another capable application, instead of implementing the functionality in itself. The concept and capability of the intent facilitate realizing the task-oriented collaboration. Furthermore, existing applications leverage RIS without requiring any modifications or awareness of the remote device, operating as if the target application were installed locally on the same device. RIS transparently extends the current intent processing procedure in Android so that an application in a device can also start an activity or service in a remote device.

RIS can be useful in a wide range of applications that can make use of task-oriented collaboration for various purposes. For instance, when we need to view an attached PDF document to an e-mail, a tablet device that has a larger screen fits better to show the document than a smartphone, even if the tablet has fewer computation resources than the smartphone. Then, the task-oriented collaboration technology enables the e-mail application in a smartphone to delegate the document displaying task to a document viewer application not in the smartphone but in a remote tablet. Another practical use of RIS can also be found in educational purposes, where a teacher can open a lecture material on the student’s tablet with a single touch on their own tablet. In addition, within a corporate environment, employee A can request a specific type of file (for example, a PowerPoint file) to employee B through RIS on A’s phone. Then, employee B can simply choose the requested file on their file-exploring app on B’s phone, and the selected file can be delivered back to employee A. Furthermore, RIS can also be used for calling a specific phone number found on the internet while using a tablet by handing the number over to their smartphone using RIS, where it also automatically launches the phone call app with the specified number.

The task-oriented collaboration becomes more effective when we use public (or shared) devices, due to security reasons. When we need to use a personalized service that requires user authentication on a public device, the input of account credentials (i.e., ID and password) into the device may cause a private data leakage problem. For example, a rental car user is required to sign in to applications in the in-vehicle infotainment (IVI) system to use their personalized services (e.g., internet music streaming service supporting personal playlists or an in-car payment service), which may unintentionally leave the account credentials in the rental car. We can prevent such a problem by using the task-oriented collaboration. Specifically, provided that a local application in the public device has been implemented to support an external login (e.g., Google or facebook login), we can delegate the login process to a remote application (i.e., Google or facebook app) in the user’s private device to acquire the authorized session information from the remote application, which entirely removes the possibility of the private data leakage.

We implement RIS in LineageOS 19.1, which is based on Android (AOSP) 12, as a proof-of-concept prototype, and evaluate its performance using various real-world applications. The experimental results show that the additional latency incurred by RIS is within hundreds of milliseconds, confirming the feasibility and practicality of RIS.

The contribution of this paper is threefold.

• We define and show the necessity of a new type of mobile collaboration task-oriented collaboration.
• We develop a novel platform service, RIS, that supports task-oriented collaboration without necessitating any modification of applications.
• We implement RIS on Android and demonstrate its capacity and feasibility using three real-world scenarios.

The rest of this paper is organized as follows. In Section 2, we present the preliminary concepts and prior work related to this work. In Section 3, we design the core components of RIS. We evaluate the feasibility of RIS in Section 4, and finally, we conclude our work in Section 6.

2. Background and Related Work

In this section, we first briefly overview the background concepts of this work and then present prior research related to this work.

2.1. Background: Intent Processing in Android

Android applications are composed of four core components: activity, service, broadcast receiver, and content provider. Intents facilitate communication among such components, for example, starting an activity or service and delivering a broadcast. Such intent-based communication can occur between components even in different applications; an activity in an application can start an activity or service in another application. Owing to the intent-based communication, we can view an attached document to an e-mail using a document viewer application without explicitly launching the application.

There are two types (explicit and implicit) of intents. An explicit intent specifies an entity (i.e., application component) that will take an action for the intent by describing the target application package name or a fully-qualified component class name. Explicit intents are typically used for in-app communications because the class names of all activities and services are already known and thus can be specified in intents. On the other hand, an implicit intent just declares a general action to perform without specifying who will take the action. Finding the appropriate component for the action is the Android system role who investigates the intent filters declared in the manifest file of other applications to determine the capability of each application. Hence, multiple components from different applications can be identified as capable, in which case users select one among them.

An intent consists of many fields, including the component name, action, data, category, extras, and flags. If the component name is specified, the intent is identified as an explicit intent and is delivered to the specified component. The action field has a string, either predefined or user-defined, that specifies the generic action to take. The data field specifies the URI and/or the MIME type of the data on which the action will be taken. The category field contains additional information about the component type that will handle the intent. The extras field has one or more key-value pairs that contain additional information to take the requested action. Among the above fields, action, data, and category are used to find an appropriate component for an implicit intent by comparing them with the contents of each intent filter that specifies the types of intent a component can accept.

Figure 1a shows the explicit intent processing flow in Android. When an activity (Activity X) of an application (App A) issues an intent specifying a target activity (Activity Y in App B), the ActivityManager receives it and consults the PackageManager about the validity of Activity Y. If valid, the ActivityManager delivers the intent to the activity and starts it. The result of the activity execution, if any, is returned to the ActivityManager and then finally delivered to App A. Each communication between distinct entities is conducted through the binder IPC. Any object sent through the binder IPC must be parcelable, which should provide a serialization method of the object. Intent objects are parcelable by default, unless there exists any object in the extras, in which case the object should also provide its own parcel method to be sent through the binder IPC. This study focuses on ‘activity’ among the four application components, as it is the most commonly used component for handling intents.

Figure 1b illustrates the change in the activity stack accompanying intent processing. Activity is a basic execution unit in Android, and there can be multiple activities in a single application. Among multiple activities in an application, only one activity runs in the foreground, occupying the display, and all other activities become inactive background ones. Android maintains an activity stack for each launched application to manage all activities in an application. In general, activities are pushed into the activity stack in their recent execution order, and the stack top always indicates the activity running in the foreground. When a foreground activity (referred to as a caller activity) invokes another activity (referred to as a callee activity) using the startActivity() method, the callee activity is placed at the top of the stack and runs in the foreground. The caller activity then transitions to an inactive background activity. If it needs results (i.e. return values) from the callee activity, it waits for the return of results via the onActivityResult() method. Upon arrival of the results, the caller activity is moved to the stack top and resumes execution in the foreground.

The above activity stack management policy also applies when an activity in an application calls an activity in another application through intent communication. In the case of Figure 1, when Activity X that runs in the foreground generates an intent, Activity Y is placed at the stack top and runs in the foreground, pushing Activity X to the background. Upon receiving the results from Activity Y, Activity X moves to the top of the stack again and resumes execution in the foreground.

2.2. Related Work

During the past decade, the mobile computing community has actively worked on mobile collaboration, aiming to provide users with more convenient and effective functionalities by networking smart devices. Table 1 compares prior efforts with RIS in terms of source code modification, level of collaboration, direction, additional resource sharing, and task interpretation.

Some prior work enables smart devices to leverage hardware functionalities such as the display and audio resources on other devices [4,5]. However, these approaches are not well-suited to handle task-oriented collaborative tasks because such tasks exploit both hardware and software resources in other devices. AirPlay [4] and Smart View [5] also allow resources to be shared, but only in one way.

Apple Home [21] and SmartThings [22] allow different devices to collaborate by providing a stable platform for inter-application communications. Each device can join a network created by such platforms and control applications in other devices in the network using the protocols they provide. However, this approach requires applications to be developed specifically for the platform to join the collaboration, imposing an additional burden on application developers.

FLUID [23], FLUID-XP [24], and PRUID [25] are proposed to present a portion of user interfaces (UI) on other devices by offloading some of the entire UI tasks to the devices. In SAMD [19], specific sub-tasks (controllers) in an application can be offloaded to remote devices for execution, with the results returned to the originating local device. To achieve this, the tasks to be offloaded must be specified in the source code of the application using APIs provided by the system. Collaboroid [13] supports access to resources on remote devices for collaborative tasks. However, it cannot exploit the functionalities of the applications installed on the remote device. MTPS [26] establishes a master–slave hierarchy among devices on the same network and schedules resource sharing tasks that can execute in parallel, but its primary objective is to optimize parallelism rather than to enable collaborative functionality. Tap [15] enables easy interactive collaboration between mobile devices, but its functionality is limited to exchanging certain resources rather than performing collaborative tasks. Crosschat [27] allows enables interoperability between existing chat applications, but its functionality is limited to message exchange and requires an additional gateway device.

Providing safe execution of tasks has also been researched, such as HTPD [11] that ensures safe delivery of message objects or GR-T [12] that runs sensitive GPU computation on cloud services. These studies are essential for guaranteeing security, but they do not enable new functionalities or efficient operations for collaboration.

Platforms for collaborative machine learning such as a proposed scheme for edge networks in 6G [17] and MIRSA [18] have been introduced. With multiple mobile devices integrating their computational power together, these platforms enable faster and more efficient learning. However, their applicability is limited to machine learning tasks and cannot be generalized to support other types of functionality.

There are research efforts that use remote procedure calls (RPC) to delegate tasks to remote devices [28,29,30]. Intent to Share [28] provides platform-level support for inter-component communication using Android intents. However, it enforces using the APIs they provide to benefit from the functionality. Android RMI [29] provides a remote method invocation (RMI) mechanism at the user level to call application or system services on remote devices. Mobile Plus [30] supports cross-device RPC, enabling the sharing of various functionalities of applications and system components. These approaches mainly focus on executing procedures on remote devices. In contrast, RIS transparently intercepts an intent issued by a local application that does not know the existence of such a service, identifies its execution context specified in the intent, and executes the task by running an appropriate application on the remote device. As such, RIS enables seamless collaboration among applications on different devices without requiring application modifications.

Table 1. Comparison of RIS with prior work.

Work	Source Code Modification 1	Level of Collaboration 2	Direction 3	Additional Resource Sharing 4	Task Interpretation 5
AirPlay [4]	×	platform	one-way	×	×
Smart View [5]	×	platform	one-way	×	×
Apple Home [21]	○	application	bidirectional	○	×
SmartThings [22]	○	application	bidirectional	○	×
FLUID [23]	×	platform	bidirectional	○	×
FLUID-XP [24]	×	platform	bidirectional	○	×
PRUID [25]	×	platform	bidirectional	○	×
SAMD [19]	○	platform	bidirectional	×	×
Collaboroid [13]	○	platform	bidirectional	○	×
Tap [15]	×	platform	bidirectional	○	×
CrossChat [27]	×	platform	bidirectional	×	○
HTPD [11]	○	platform	bidirectional	×	×
MTPS [26]	○	platform	bidirectional	○	×
Collaborative ML [17]	○	application	bidirectional	×	×
MIRSA [18]	○	application	bidirectional	×	×
GR-T [12]	×	platform	one-way	×	×
Intent to Share [28]	○	platform	bidirectional	×	×
Android RMI [29]	×	platform	bidirectional	×	×
Mobile Plus [30]	×	platform	bidirectional	○	×
Remote Intent Service	×	platform	bidirectional	○	○

¹ Source code modification indicates whether the source code of the existing apps needs to be modified to use its functionality. ² Level of collaboration indicates the layer in which the collaboration functionalities are implemented. ³ Direction indicates whether devices can act as both providers and consumers of the collaborative functionalities (bidirectional) or their roles are separated (one-way). ⁴ Additional resource sharing indicates whether the work supports sharing of resources other than a fixed type of objects. ⁵ Task interpretation indicates whether the work interprets the task details and behaves adaptively.

Table 1. Comparison of RIS with prior work.

Work	Source Code Modification 1	Level of Collaboration 2	Direction 3	Additional Resource Sharing 4	Task Interpretation 5
AirPlay [4]	×	platform	one-way	×	×
Smart View [5]	×	platform	one-way	×	×
Apple Home [21]	○	application	bidirectional	○	×
SmartThings [22]	○	application	bidirectional	○	×
FLUID [23]	×	platform	bidirectional	○	×
FLUID-XP [24]	×	platform	bidirectional	○	×
PRUID [25]	×	platform	bidirectional	○	×
SAMD [19]	○	platform	bidirectional	×	×
Collaboroid [13]	○	platform	bidirectional	○	×
Tap [15]	×	platform	bidirectional	○	×
CrossChat [27]	×	platform	bidirectional	×	○
HTPD [11]	○	platform	bidirectional	×	×
MTPS [26]	○	platform	bidirectional	○	×
Collaborative ML [17]	○	application	bidirectional	×	×
MIRSA [18]	○	application	bidirectional	×	×
GR-T [12]	×	platform	one-way	×	×
Intent to Share [28]	○	platform	bidirectional	×	×
Android RMI [29]	×	platform	bidirectional	×	×
Mobile Plus [30]	×	platform	bidirectional	○	×
Remote Intent Service	×	platform	bidirectional	○	○

¹ Source code modification indicates whether the source code of the existing apps needs to be modified to use its functionality. ² Level of collaboration indicates the layer in which the collaboration functionalities are implemented. ³ Direction indicates whether devices can act as both providers and consumers of the collaborative functionalities (bidirectional) or their roles are separated (one-way). ⁴ Additional resource sharing indicates whether the work supports sharing of resources other than a fixed type of objects. ⁵ Task interpretation indicates whether the work interprets the task details and behaves adaptively.

To summarize, RIS is a platform-level service for applications that are not developed for remote execution in mind. It also interprets the task details and adapts its behavior accordingly, for example, inspecting required additional resources that the other device might not have and sending them along with the message (intent) itself. Moreover, RIS supports bidirectional collaboration, both from the local device to the remote device and vice versa. On the other hand, to the best of our knowledge, no existing studies have been specifically designed to support such a service. Prior research either requires the applications to to adopt custom APIs or merely offloads resources or fixed type of tasks to other devices without considering the execution context. Furthermore, their purpose is mostly limited to tasks specified by the applications, whereas RIS is designed to handle a wide range of tasks and user preferences.

3. Design of the Remote Intent Service

In this section, we first present the design goal of our remote intent service and then detail its core components.

3.1. Design Goals and Technical Problems

The objective of RIS is to establish a system that enables an application in a local device (local app) to transparently execute another application on a remote device (remote app) via an intent transfer, as if the remote app is executed on the local device, without any modification to applications. To that end, an intent generated by a local app must be processable on the remote device, and the results (also an intent) of the remote app must be safely returned to the local app. RIS supports inter-application intent communications at the framework level, since intent processing in Android is closely integrated with the framework responsible for managing activities. Thus, a local app cannot discern whether the remote app is hosted on the same device or not, providing not only seamless and transparent intent processing across different devices but also the intactness of applications.

RIS is designed to ensure that the intended operation of a user application, represented in the generated intent, is executed accurately on a remote device. Providing a simple inter-device intent communication service is not enough to achieve the design goal due to the heterogeneity of operating environments between local and remote devices. A representative scenario where simple intent communications cannot achieve the goal involves intents associated with files stored on the local device. In this case, the file referenced by the intent may not exist on the remote device, rendering remote intent processing infeasible. To achieve the goal, RIS needs to interpret the contextual information of the intent and take the necessary actions to ensure its proper processing on the remote device. In the above scenario, RIS manages the remote intent processing by also transferring the associated local files, thereby ensuring seamless execution of the intended activity and correct results.

Hence, besides the intent communication functionality, RIS needs to incorporate solutions to the following technical problems to realize task-oriented collaboration.

• Intent discernment: Unconditional transfer of an intent to a remote device incurs a serious problem when the remote device does not have an installed application to handle the intent. Hence, the RIS needs to recognize the remote devices’ capability to process each intent and maintain such information to identify intents for remote processing. Additionally, the information should be manageable by users to provide the local device user with the authority to choose an intent processing device between local and remote devices.
• Resource sharing: Intents often require supplementary resources to be passed to the target application. While some of the resources are embedded within the intent itself, there are cases where external resources (e.g., files) are specified in the intent by URIs. When an intent includes such external resources, the resources must also be available in the remote device for remote processing. To guarantee the availability of such resources, RIS needs to incorporate external resources when transferring an intent to a remote device.
• Inter-activity relationship management: Remote intent processing hurts the ordinary caller–callee relationship between activities, managed in the local device to correctly maintain the activity stack and safely return the results. A careful management scheme for the relationship is desired in RIS, specifically when the callee activity generates return values.

3.2. Overall Architecture

RIS is designed to provide solutions to the above technical challenges. Figure 2 illustrates the overall architecture of RIS and its remote intent processing flow. RIS consists mainly of four components: intent gateway, intent communication service, dummy app, and result intent gateway. The intent gateway intercepts every intent invoked by local applications to identify an intent to be directed to a remote application. In this paper, we call an intent to be delivered to an application in the local and remote devices a local intent and remote intent, respectively. The intent gateway maintains an intent table that defines rules for identifying remote intents. For a local intent, the intent gateway takes no other action so that it can be processed in an ordinary intent processing flow. For a remote intent, it delivers the intent to the intent communication service (ICS) for remote processing. The execution flow then diverges based on the result requirement of the intent invocation. For an intent that does not require results (case 1 in Figure 2), the intent gateway directly delivers the intent to ICS. In this case, the execution flow is unidirectional, from the local to the remote device. In contrast, for an intent that requires the return of execution results (case 2 in Figure 2), the intent gateway delegates the execution process to the dummy app, a special system app that interacts with ICS on behalf of the intent gateway. After delivering the intent to ICS, the dummy app waits for a result intent from the remote application to return it to the local application through the intent gateway, thus forming the bidirectional execution flow. The necessity and detailed functions of the dummy app are presented in Section 3.5.

The intent communication service plays the role of communicating intents between collaborating devices. Specifically, the ICS in the local device transfers intents and associated data to the remote device. On receiving the intent, the ICS in the remote device invokes the target activity and delivers the received intent to the activity. Upon completion of the target activity, its execution results (if any) are contained in a result intent to be returned to the local application. The result intent gateway in the remote device identifies whether the result intent is a result of the remote intent or not by checking the invoker of the activity. If the ICS has invoked the activity, the intent is regarded as a result of the remote intent, and the result intent gateway delivers it to the ICS. The result intent is then transferred to the ICS in the local device and eventually delivered to the local application through the dummy app.

The above design of the RIS solves the three technical problems in Section 3.1 as follows:

• Intent discernment: RIS selectively identifies remote intents referring to the intent table. Since the intent table lists only those intents that can be safely processed in the remote device, the intent table-based remote intent identification guarantees the processability of the intent in the remote device. In addition, RIS converts every explicit remote intent into an implicit one to provide users an option to choose the designated device between local and remote devices for the intent.
• Resource sharing: When a remote intent includes URIs referencing external resources, the RIS transfers a copy of each resource to the remote device alongside the intent to guarantee the resource availability in the remote device. Solutions to resolve rigorous file/directory access control policy in Android accompany such a resource sharing scheme in the RIS.
• Inter-activity relationship management: The RIS introduces a dummy app that stays active in the foreground until the remote application returns the results. The intermediary dummy application indirectly maintains the relationship between the caller (local) and callee (remote) activities, ensuring correct management of the activity stack and safe return of results.

In the following sections, we present each solution in detail.

3.3. Intent Discernment

Remote intent processing begins with inspecting every intent upon generation to identify remote intents and forward them to the ICS. To that end, the intent gateway maintains a list of remote intents in a table called the intent table, which is a system-wide structure. Each entry in the intent table consists of three attributes: (1) package name of the local app that generates intents, (2) package and activity names of the target app that will be executed in the remote device, and (3) a generic action intended to take for the intent.

Figure 3 illustrates an example of remote intent identification performed by the intent gateway in the local device. In this scenario, we assume that the com.example.risbench application in the local device generates an intent to execute the MainActivity of the com.TODO application with the ACTION_PICK action. The intent gateway refers to the intent table to determine whether there is a matching entry in the table. Specifically, the package name of the caller app and the component and action fields of the generated intent are matched with the package name (local app), package and activity names (remote app), and intent action fields in the table, respectively. To expedite the matching process, the intent gateway first uses hashing against the concatenated three fields to find one or more entries with the same hash value and then compares each field again with the entries (if any) using string matching to resolve hash collision. Only when there is a matching entry in the table is the generated intent identified as a remote intent designated for remote processing and thus delivered to the ICS. Otherwise, the intent is conceived as a local intent and forwarded to the ActivityManager for ordinary local processing.

The RIS provides user interfaces to manage the intent table in the Settings app. Users can register applications that deserve remote execution or delete entries to/from the table. The RIS also provides a user interface to find and connect nearby devices for collaboration. Wi-Fi Direct [31] is used for that purpose. When a connection is established between collaborating devices, they first share their intent tables. For each entry in the received intent table, a device finds matching applications (i.e., those that can execute the intent) installed in it and sends the list of matched applications to the peer device. The peer device registers applications in the list to PackageManager as virtual (remote) applications. When the same application is available in both local and remote devices, the RIS enables users to choose a target device (local or remote) for intent execution. To that end, the intent gateway converts an explicit intent into an implicit one so that the user can select one between local and remote applications.

3.4. Resource Sharing

An intent typically includes information about the callee activity itself to be executed. However, in some cases, the callee activity requires additional resources (or objects) that are difficult to embed in the intent structure for accurate execution. Then, the caller activity embeds URIs of the resources, instead of the resources themselves, in the data, extras, or clipboard field of the intent. For example, when an e-mail app invokes a document viewer app through intent communication to show the contents of an attached document to a user, the attached document should also be delivered to the document viewer app. In that case, the e-mail app specifies the URI of the document in the data field of the intent.

Such a URI delivery is enough for processing local intents, since both the caller and callee activities reside in the same device, sharing an identical execution environment. However, for remote intents, the URI delivery is insufficient to execute the callee activity, since the URI is not valid on the remote device. To solve this problem, the RIS examines the remote intent and transfers the resources specified by the URIs to the remote device. Specifically, the intent gateway inspects the data and extras fields of the intent to find any URIs referencing local resources needed for intent execution. If found, the intent gateway transfers it to the remote device through ICS. For a URI that references a third-party resource (e.g., resources on the internet), it takes no further action, since the remote device can access the resource through the network.

However, implementing the above resource sharing scheme is not straightforward due to Android’s rigorous access control policy. In Android, resources referenced by URIs within an intent can be accessed only by the application that generated the intent, which prohibits the ICS from accessing the resources for remote transfer. The RIS solves the problem by (1) implementing the intent gateway so that it runs in the context of the application that issued the intent and (2) creating a system-wide shared directory. Specifically, we implemented the intent gateway in the execStartActivity() method, which runs in the context of the caller activity having the same access privilege to the resources with the caller activity. In this way, the intent gateway can access the resources specified in the intent. The system-wide shared directory allows both the intent gateway and ICS to access the directory. The pathname of the directory is fixed so that collaborating devices share an identical pathname. Although the shared directory itself is accessible by all applications, the privilege of each file is limited to the RIS and the target application, preventing leakage to other unrelated authorities.

Figure 4 shows an example of the resource sharing process in RIS. To share resources specified in a remote intent with a remote device, the intent gateway copies the resources into the shared directory. It also updates the URIs in the intent to reference the copied resources in the shared directory. Then, the ICS transfers the resources in the shared directory, instead of the original resources, to the remote device along with the intent. After transferring them, the ICS removes the copied resources from the shared directory. Upon receiving the intent and resources, the ICS in the remote device starts the callee activity, passing the received intent, and stores the resources in the shared directory. The updated URIs in the intent enable the callee activity to access the resources in the shared directory. If the callee activity, as a result of the execution, creates new files or modifies received files from the caller activity, the files should be returned to the caller activity. In that case, the result intent contains the URIs of the files. The above resource sharing process is also applied to transfer the result files. To that end, the result intent gateway is implemented in the finish() method, which runs in the context of the callee activity, and the same shared directory is used for that purpose.

3.5. Inter-Activity Relationship Management

An activity stack for an application manages not only the activities in the application but also those in another application invoked through intent communication. Hence, the activity stack management policy, presented in Section 2.1, can be safely enforced when processing local intents.

Figure 5 shows the changes in the activity stack when processing a local intent. Of importance here is that the caller activity is pushed down in the stack by the callee activity, since both activities run on the same device. When the callee activity finishes running, it is removed from the stack, and the stack top points to the caller activity again to resume it in the foreground. In this way, the activity stack implicitly manages the caller–callee relationships between activities in different applications. However, a problem occurs when processing remote intents, specifically when processing remote intents that generate output to be returned to the local device. The activity stack management policy assumes that the foreground activity is always active. If the foreground activity stays inactive for a long time then Android perceives it as malfunctioning and triggers an ANR (“Application Not Responding”) error, which is problematic, since the application cannot respond to user input events [32]. When an activity in an application generates a remote intent, the callee activity is executed in the remote device, which does not affect the activity stack of the application in the local device. The caller activity remains at the top of the stack as a foreground activity. At that time, if the caller activity does not wait for a return intent from the callee activity, it continues working. However, if the caller activity requires a return intent, it pauses working (i.e., not responsive) until the result is returned. When such an unresponsive state persists for a predefined time, Android recognizes the activity as inactive and may trigger an ANR error.

In addition to the above problem, the remote intent processing makes it hard to deliver a result intent to the caller activity. In ordinary activity calls (i.e., local intent processing), the caller activity waits for the return of a result intent through the onActivityResult() callback method. When the callee activity finishes, the result intent is delivered to the caller activity through the callback method. In remote intent processing, however, the caller and callee activities run on different devices without the direct caller–callee relationship. The ICSs in both devices reside between the activities; thus, the ordinary callback-based result delivery mechanism does not work.

To mitigate these issues, the RIS introduces a special system application, called dummy app. For a remote intent that requires a result return, the intent gateway in the local device delegates its processing to the dummy app. Specifically, when the intent gateway identifies such a remote intent, it creates a new (local) intent that calls the dummy app and embeds the remote intent, as a whole, in the extras field of the new intent. Then, the intent gateway processes the new intent, not the remote intent, as an ordinary local intent that executes the dummy app. As a result, the caller activity waits for a result intent from the dummy app, not from the callee activity specified in the remote intent, which establishes a caller–callee relationship between the caller activity and the dummy app.

Figure 6 illustrates the remote intent processing flow, incorporating the result intent return, using the dummy app. The main activity of the dummy app, upon execution, creates a background thread that directly calls the ICS to deliver the embedded remote intent and waits for the result intent from the ICS. At that time, the ICS delivers the result intent as an ordinary function call return value, not through the callback method. The foreground thread of the dummy app displays a dialog that shows a status message, “An intent is being executed in the remote device”, and allows the user to stop the remote intent execution. Due to the foreground thread, the main activity remains responsive, preventing the ANR error, until the background thread receives the result intent from the ICS. The local device’s ICS delivers the intent to the remote device’s ICS, which executes the callee activity. When the callee activity finishes, the result intent is delivered to the dummy app via the result intent gateway, the remote device’s ICS, and the local device’s ICS. Upon receiving the result intent, the dummy app designates it as its result intent and finishes so that the result intent can be delivered to the caller activity through the callback method. The above remote intent processing flow applies only to remote intents that require the return of a result intent. For other remote intents, the intent gateway directly delivers the intent to the ICS without using the dummy app. The intent gateway differentiates the two kinds of remote intents by examining the requestCode parameter (negative: no result required, nonnegative: result required) in the intent generation API.

4. Performance Evaluation

In this section, we describe the evaluation of the latency and applicability of the RIS under various scenarios to investigate the feasibility of the RIS. We implemented the RIS in a real Android system, LineageOS 19.1, which is based on Android 12.

Although the RIS, as a system that involves interaction between different devices, has a nontrivial chance to fail during operations, we assumed the 100% success rate of all experiments. This is because failure occurs mostly due to the by-nature unstable wireless network, which is uncontrollable, and the design of the RIS is not related to it. Other than such cases, we have found no internal failure of the RIS yet.

Table 2. Implementation details of components of RIS.

Device	Component	Code Location	Work Details
Local	Intent gateway	Instrumentation.java execStartActivity	Read intent table Copy resources to shared directory update URI Execute dummy app Call ICS (execRemoteIntent)
	Dummy app	System app code	Call ICS (execRemoteIntent) Return result intent
	ICS	System service code RemoteIntentService.java	Send intent and resources Wait for result intent Write result files to shared directory Return result intent
Remote	ICS	System service code RemoteIntentService.java	Read intent and resources Write resources to shared directory Execute callee activity Send result intent and file
	Result intent gateway	Activity.java finish	Check activity invoker Copy result files to shared directory update URI Call ICS (sendResult)

outlines the system components involved in the RIS execution flow. The intent gateway and result intent gateway are integrated into the Android framework by extending the execStartActivity() method of the Instrumentation class and the finish() method of the Activity class, respectively, which run with user app privileges. The dummy app is developed as a standalone application and registered as a system app within the Android system. ICS is implemented as a system service, registered during the Android boot process. It reveals two core APIs: execRemoteIntent(), which facilitates intent transmission to remote devices, and sendResult(), which handles the return of execution results from remote devices.

We conducted experiments using two Google Pixel 5 smartphones with our customized Lineage 19.1 installed. Both devices were connected to the same Wi-Fi access point in all experiments, except for the “direct communication” experiments where the local device was connected to the hotspot provided by the remote device.

Table 3. List of applications used in experiments.

Name (Version)	Description	Issued Intents by the Caller App (RISBench)
RISBench	In-house benchmarking app	User defined intents
Librera (8.9.183)	PDF reader app	Intent.ACTION_GET_CONTENT “application/pdf” type Intent.CATEGORY_OPENABLE category
Gallery (1.1.40030)	LineageOS-default image viewer app	Intent.ACTION_VIEW “image/*” type
Files (12)	LineageOS-default file browser	Intent.ACTION_GET_CONTENT
Browser (12)	LineageOS-default internet browser app	Intent.ACTION_VIEW URL to a web page
Clock (12)	LineageOS-default clock, alarm, and timer app	AlarmClock.ACTION_SET_ALARM Time information in hours, minutes, and seconds
Music (4.1.0)	LineageOS-default music app	Intent.ACTION_VIEW “audio/*” type URI to a music file
Camera (2.0.002)	LineageOS-default camera app	MediaStore.INTENT_ACTION_VIDEO_CAMERA
Phone (23.0)	LineageOS-default phone call app	Intent.ACTION_DIAL URI to the phone number
MS Outlook (4.2447.2)	Email app	Intent.ACTION_SENDTO “mailto:” URI
Facebook (509.0.0.67.28)	Social networking service app	Intent.ACTION_MAIN “com.facebook.katana.LoginActivity” component

lists the applications used in the experiments. We developed a simple benchmarking application RISBench that can issue various intents, as well as result intents, according to the objective of each experiment. To precisely set the contents of the intents issued by various applications, we used RISBench as a single caller app that mimics the intent generation of real-world applications. The real-world applications in Table 3 are used as callee apps installed on the remote device.

We classified all the experiments into three categories. First, we performed basic experiments where the local RISBench issues a remote intent that calls an activity in the remote RISBench to measure RIS’s intrinsic time overhead (latency). Then, we tested various functionalities of RIS using representative intents commonly seen in user applications. The RISBench was used as both the caller and callee apps in this experiment. Lastly, we investigated RIS’s applicability in realistic scenarios by performing several experiments using real-world apps as the callee app.

A remote intent processing consists of two phases, ‘local to remote (L-to-R)’ and ‘remote to local (R-to-L)’ phases, where the latter phase is necessary only when the issued intent requires a result. For a detailed analysis of the remote intent processing latency, we further break down each phase into three latency measurement intervals, as shown in

Table 4. Latency measurement intervals in a remote intent processing.

Phase	Interval Name	Timestamp (from)	Timestamp (to)
L-to-R	Call local ICS	Intent gateway intercepts an intent	Local ICS called
	Transfer to remote	Local ICS called	Remote ICS received intent and resources
	Launch remote activity	Remote ICS received intent and resources	Callee activity launched
R-to-L	Call remote ICS	Callee activity called finish()	Remote ICS called
	Transfer to local	Remote ICS called	Local ICS received result intent and resources
	Return to local app	Local ICS received result intent and resources	onActivityResult() in the local app is executed

. The dummy app is executed and terminated in the ‘Call local ICS’ and ‘Return to local app’ intervals, respectively. Hence, its launch and termination times are included in the respective intervals. Note that the execution times of the caller app and callee activity are not included in the latency.

We repeated each experiment ten times and show the average latency of the experiments. To ensure complete independence between each experiment, we removed all intermediate files created in the shared directory before starting each experiment.

4.1. Overhead of RIS

We first measured the latency when the RISBench app in the local device issues an explicit remote intent that invokes the main activity of the RISBench app in the remote device. The main activity takes different actions depending on the contents of the intent received from the local device. The contents of remote intents have been determined to represent various scenarios of activity calls in terms of the result and file transfer requirements. In each experiment, the local RISBench app issues a remote intent that leads the main activity in the remote RISBench app to take one of the actions shown in

Table 5. Actions of the main activity in the RISBench app.

Action	Description	Result	File Transfer	File Transfer
			Size (L-to-R)	Size (R-to-L)
Launch	Launches RISBench	No	-	-
Launch and return	Launches RISBench and immediately returns an empty result intent	Yes	-	-
Launch with a file	Launches RISBench with a received file from the local device	No	1 KB	-
Launch and generate a file	Launches RISBench and generates a file to be transferred to the local device as a result	Yes	-	1 KB

.

Figure 7 shows the average latency for processing a single remote intent that triggers a specific action of the main activity in the remote RISBench app. In case of communication through the public access point (‘Pub. AP’), the intent (and file) transfer time from local to remote devices (i.e., ‘Transfer to remote’ interval) takes the largest portion of the total latency in all cases. Although the time varies greatly depending on the network condition and the amount of transferred data, it is noticeably larger than the result intent (and file) transfer time from remote to local devices (i.e., ‘Transfer to local’ interval). This is because the former includes the time to establish a network session between two devices, which is not included in the latter. However, the networking overhead can be significantly reduced when devices are directly connected to each other (‘Direct’). The time for ‘Call local ICS’ significantly differs depending on whether the intent requires results or not. When it requires results, the dummy app is launched during the time, resulting in larger ‘Call local ICS’ times for ‘Launch and return’ and ‘Launch and generate a file’ cases.

Despite the overhead associated with remote processing, the total latency (under 250 ms for public access points and under 200 ms for direct communication) remains sufficiently low for RIS to be practical, except in cases where the service is used repeatedly in an interactive manner, which is uncommon for intents. In most cases, both devices are controlled by a single user, and in such cases the user has to move their head (or eye) from the local to the remote device, which makes the latency of 250 ms hardly recognizable. Moreover, since the Pixel 5’s overall performance is lower than that of most modern smartphones, we expect even lower latency if RIS is implemented in commercial products in the future.

Table 6. Resource consumption in “Launch and return” scenario.

Device	Average CPU Load	Battery Usage (15 min)
Local	12.13%	1%
Remote	25.38%	4%
Idle	2.75%	0%

shows the average CPU load and total battery consumption of the “Launch and Return” experiment, which was repeated every second for 15 min (a total of 900 runs), compared to the “Idle” scenario where both devices are on without addressing any intents. In both scenarios, both devices maintained 50% display brightness without being charged. The results for the local device show that even when RIS was extremely actively used, its CPU load increased by around 9.38 percentage points compared to when the device was idle, and the RIS consumed negligible energy. Conversely, CPU load of the remote device increased by approximately 22.63 percentage points, and it consumed 4% of total battery capacity. This increase in resource consumption is unavoidable for the RIS, primarily because most of the overhead arises from launching the app, in which the operation involves not only the app execution process but also storage access to open the APK file. Even though the app used in this experiment is relatively lightweight compared to real-world apps, it still consumes significantly more energy than other components of the RIS process.

4.2. RIS Functionality Tests

In this section, we show the capability of RIS in handling various types of intents frequently seen in real-world apps. The intents include an explicit intent that launches a specified application by calling the main activity of the app and implicit intents that launch an app or activity that can perform the general action specified in the intent.

Table 7. Scenarios for the RIS functionality tests.

Scenario	Intent Description	Result	File Transfer	File Transfer	Intent
			Size (L-to-R)	Size (R-to-L)	Type
Remote app launch (explicit)	Launch Facebook app	No	-	-	Explicit
Remote app launch (implicit)	Launch any camera app	No	-	-	Implicit
View a local image file using a remote app	Launch any image viewer app to show a given image file	No	51.9 KB	-	Implicit
Retrieve a remote file	Launch a file selector activity to retrieve a file	Yes	-	88.2 KB	Implicit
Retrieve multiple remote files	Launch a file selector activity to retrieve multiple files	Yes	-	882 KB (10 files)	Implicit

lists the real-world scenarios that use the intents. We used Camera, Gallery (for the image viewer), and Files (for remote file retrieval) apps, shown in Table 3, to handle four implicit intents. In each experiment for the above scenarios, we measured the latency for remote intent processing.

Figure 8 shows the experimental results. The RIS can process both implicit and explicit intents for launching a remote app with almost identical latency when they do not accompany any file transfer. When an intent processing accompanies file input or output, the remote intent processing latency inevitably increases due to the file transfers, as shown in the latter three scenarios. The remote image view scenario involves an L-to-R file transfer, which increases the ‘Transfer to remote’ time, while the remote file retrieval scenarios involve R-to-L file transfers, which introduce the ‘Transfer to local’ and ‘Call remote ICS’ times. Undoubtedly, the ‘Transfer to local’ time is commensurate with the amount of data transferred. The ‘Call remote ICS’ time also increases with the amount of transferred data since the time includes the file copy time to the shared directory.

The above results confirm the functionality of RIS, which can handle various types of intent with reasonable latency.

4.3. Latency with Application-Specific Scenarios

Finally, we investigated the performance of the RIS under various application-specific scenarios, shown in

Table 8. Real-world application-specific scenarios.

Scenario	Description	Result	File Transfer	Intent	Remote
			Size (L-to-R)	Type	App
Open a web page	Open a given web page using a remote web browser	No	-	Implicit	Browser
Open a PDF document	Open a PDF file in the local device using a remote PDF viewer	No	88.2 KB	Implicit	Librera
Play music	Play an MP3 file in the local device using a remote music player	No	4.8 MB	Implicit	Music
Send an email	Launch a remote email app in composing mode	No	-	Implicit	MS Outlook
Set an alarm	Create an alarm using an alarm app	No	-	Implicit	Clock
Initiate a phone call	Open the phone app and dial a phone number	No	red-	implicit	Phone

. In all scenarios, the local app (RISBench) issues an implicit intent that does not involve any R-to-L file transfer. We used Browser, Librera, Music, Clock, Phone, and MS Outlook applications to handle intents in the remote device.

Figure 9 shows the latency of remote intent processing for each scenario. Most notable is the large ‘Transfer to remote’ time in the ‘Play music’ scenario, due to the time needed to transfer a 4.8 MB-sized MP3 file. The RIS does not differentiate multimedia files from ordinary resource files that need to be sent entirely before launching a remote activity. This design of RIS results in significant latency when users want to play music or a movie using a remote device. The problem can be solved by incorporating streaming functionality in the RIS. We leave this for future work (Section 6). In all scenarios except for ‘Play music’, RIS shows an acceptable latency for the remote processing of application-specific intents.

5. Limitations and Future Work

While the RIS can perform a variety of mobile collaboration in many practical scenarios with reasonable latency, it has a few aspects that can possibly be improved. We are planning to conduct further research to address the following (and perhaps other) issues:

• Energy efficiency: In general, the energy and computational resource consumption in RIS is trivial, because an intent object itself is lightweight, and the time taken to execute the specified app is nearly instant. However, energy consumption can be problematic if the operations involve huge file transmissions. As mobile devices are usually highly limited in battery capacity, it will be important to develop a method to minimize energy consumption in such cases.
• Latency for large file transmission: The current design of the RIS can execute the remote app only after retrieving all required files from the local device, because it has no control over the remote app’s attempt to access the files. However, waiting for all files to be transmitted can cause a huge delay when the files are large, and it will be a waste of time if the remote app will not actually have used the file. Two solutions are being considered to reduce the latency in such cases. First, streaming functionality for multimedia files can be introduced, where only the necessary part of a file is transferred when the app requests it. Streaming rules, including which type of files should be streamed and which apps can use the functionality, can be specified in the intent table. Second, files can be transferred asynchronously. This method requires a technique supported by the file system to block the app when the app tries to access to a file in the shared directory that is yet to be transferred. With this solution, the remote app can be executed first while other additional files are still being transferred.
• Security and privacy risks: Currently, the only authentication phase between two devices is through the RIS section we created in the Settings app, where the user can confirm to add other devices to the trusted list. However, the RIS does not have a fundamental prevention method against network attacks such as sniffing, revealing risks for a privacy leak. Moreover, the other device may be infected by malware or may have a maliciously manipulated RIS. To protect RIS from these risks, an encryption method will be applied during transmission, and a secure authentication phase will be introduced for the initial connection between two devices.
• Platform dependency: The design of RIS uses Android-specific features, mainly regarding intents and the shared directory. These components are not available on other platforms, for example, iOS, and thus cannot be universally implemented. Along with the research on RIS, a way to provide similar mobile collaboration support, which is less dependent on the platform, is being developed.
• Android version: RIS is built on top of LineageOS 19.1, which is based on Android 12. Migrating RIS to newer versions may require a few fixes in its implementation to cope with the following changes:

  –

  Restrictions on specific intents: Android 14 introduced several new rules for implicit and pending intents, as well as restrictions on starting activities from the background.

  –

  Added rules for safer intents: Android 15 and 16 introduced stronger regulations to improve the security of intents.

  –

  Protection against intent redirection attacks: Android 16 improved its security policies regarding intents to safeguard sensitive data from redirection attacks.

These changes mainly regarding security need to be taken into account by RIS, by checking if the intent to be transferred follows the updated policies and if the remote app is compatible with them. Other than the minor modifications needed to fulfill security requirements, to the best of our knowledge, the overall execution flow of an app using the intent has not changed drastically, and we have not identified any critical alterations that would invalidate the core design of the RIS. We believe that implementing RIS on new Android versions remains feasible with our proposed design. In the future, an advanced version of RIS will also be implemented on the latest Android releases.

• Generalization of the service: The design of RIS relies on Android-specific features, mainly regarding intents and the shared directory. These components are not available on other platforms, for example, iOS, thus limiting its universal applicability. Further research on RIS is being conducted to develop a more generic platform-independent framework for mobile collaboration. This will enable integration of the RIS with existing solutions, and the performance of RIS will be able to be evaluated relative to the prior implementations.

6. Conclusions

In this paper, we developed a platform-level service, the remote intent service (RIS), that enables remote processing of intents issued by local applications for task-oriented collaboration between mobile devices. RIS effectively addresses three technical challenges, intent discernment, resource sharing, and inter-activity relationship management, which are prerequisites for realizing task-oriented collaboration without modifying applications. We implemented the RIS on the Android platform and measured the latency for remote intent processing under various scenarios using real-world applications. The experimental results showed that RIS incurs acceptable latency in most scenarios, making it a practical solution for task-oriented mobile collaboration.