HK1176779B - Background transfer service for applications on mobile devices - Google Patents

Description

Background transfer service for applications on mobile devices

Technical Field

The invention relates to background data transfer.

Background

Allowing applications (e.g., third party applications) to run in the background of the mobile device and perform tasks puts malicious or poorly designed applications out of batteries, consumes bandwidth, and slows mobile phone/device performance. This is a problem on mobile devices where system resources are limited and a foreground experience is desired to run with full fidelity and responsiveness. In general, CPU, memory and network bandwidth are limited system resources; furthermore, bandwidth is highly variable under certain network conditions.

As a result, in one solution, application background processing is effectively disabled in that an application is "deactivated" when it is removed from the background. This means that applications currently rely on the user to hold them in the foreground to continue with these tasks, including data transfer. This solution is generally undesirable.

Disclosure of Invention

This summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.

Briefly, aspects of the subject matter described herein relate to techniques for configuring a background transfer service to run on a mobile device to control transfer of network data communications for an application. The background transfer service manages requests for data transfers by applications based on one or more policies that control resource usage of background application data transfers in a manner that limits interference with foreground application operations. In one implementation, a background transfer service is coupled to a download manager configured to make a remote connection to transfer data to or from a remote source to satisfy a transfer request.

In an aspect, the data sharing service moves or copies data transmitted (downloaded) from a remote source to a local store accessible by the application. The data sharing service moves or copies data from storage accessible by the application for transmission (upload) of the data to a remote source. In an aspect, the application instance manager provides notifications related to an offload state, license revocation, or recovery state of the application to a background transfer service that can cancel, suspend, and/or resume each pending transfer request of the application, respectively.

Policies may relate to allowing only a maximum number of pending transmissions at a time, limitations based on data size, connection rules (e.g., Wi-Fi versus cellular), and/or bandwidth limitations. The policy may be based on conditions such as other application data transmission requests, available cellular services, Wi-Fi availability, desktop browsing availability, power status, battery level, and/or charging status.

In an aspect, data is transmitted on behalf of one or more applications. This includes receiving data transfer requests from each application and managing the data transfer requests of each application to retain control over resource usage when transferring data for that application. Management of data transfer requests may include determining whether one or more transfer conditions are satisfied, and if not, moving the request to a wait state until the one or more transfer conditions are satisfied. The management of data transfer requests may also include determining whether to allow the request based on the size of the data to be transferred, throttling data transfers based on available bandwidth and/or the presence of the foreground streaming media, prioritizing foreground application data transfers over background application data transfers, and/or detecting a slow transfer state by checking whether the transfer rate is below a threshold, and if detected, waiting for a changed condition before continuing data transfers for the application. If the associated application is currently executing (in the foreground or in the background), the application is aware of the current transport state via a notification, commonly referred to as an "event," and can also query the transport service to determine the current state of any of its requests (including those that have been successfully completed or are in error).

In an aspect, when information (e.g., a notification) is received indicating that an application is being uninstalled, managing data transfer requests includes canceling each data transfer request corresponding to the application. When information indicating that the license of the application has been revoked is received, managing the data transmission requests includes suspending each data transmission request corresponding to the application; when information indicating that the license of the application has been restored is received, managing the data transfer request includes resuming the data transfer request corresponding to each of the pauses of the application.

When information is received indicating that an application has changed from a background application to a new foreground application, managing data transfer requests includes re-prioritizing at least one pending data transfer request of the new foreground application. When information is received indicating that the application has changed from the foreground application to the background application, managing the data transfer requests includes re-prioritizing at least one pending data transfer request for the background application.

In one implementation, when a data transfer request is received that includes a request to transfer data on behalf of an application, information corresponding to the request is queued in a request queue. Processing information from the request queue includes downloading data into the file cache on behalf of the application, including when the application is a background application. At download time, data is moved or copied from the file cache to a separate store using a service that has access to the store associated with the application. Data may be incrementally moved or copied while the transfer is in progress, or moved or copied in a single operation once the transfer is complete; in one implementation, the move from request storage to separate storage is completed only when the transmission ends without error. Uploading operates similarly, e.g., queuing and processing upload requests, including communicating with a service having access to an application store that includes data to be uploaded to upload the data on behalf of the application. If the associated application is currently executing (in the foreground or in the background), the application periodically knows the progress of the transfer via a notification, commonly referred to as an "event", and can also query the transfer service for the current progress of any of its requests.

Other advantages of the present invention will become apparent from the following detailed description when read in conjunction with the accompanying drawings.

Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar or like elements and in which:

FIG. 1 is a block diagram representing example components for performing background data transfers for an application via a background transfer service.

Fig. 2 is an example of an application for downloading content using a background transfer service.

FIG. 3 is a data flow diagram representing example components and data communicated when performing a background data transfer.

Fig. 4 is an example timing/data flow diagram showing how an application establishes a connection to a background transfer service.

FIG. 5 is an example timing/data flow diagram illustrating how an application enqueues a background transfer request.

Fig. 6A and 6B include a flow chart illustrating example steps for checking conditions and delaying or requesting data transmission based on the conditions.

FIG. 7 is an example timing/data flow diagram illustrating invoking a background transfer service to register for progress/completion notifications.

FIG. 8 is a timing/data flow diagram illustrating example operations involved in obtaining a transmission progress notification.

FIG. 9 is a timing/data flow diagram illustrating example operations involving obtaining a completion notification.

FIG. 10 is a timing/data flow diagram illustrating example operations involving canceling a background transfer request.

FIG. 11 is a timing/data flow diagram illustrating example operations related to querying background transfer request status.

FIG. 12 is a timing/data flow diagram illustrating example operations involving suspending a background transfer.

FIG. 13 is a timing/data flow diagram illustrating example operations involving continuing a background transfer.

FIG. 14 is a timing/data flow diagram illustrating example operations related to querying background transfer service status.

FIG. 15 is a state diagram illustrating an example state of a transfer request in a background transfer service.

FIG. 16 is a block diagram representing an exemplary non-limiting computing system or operating environment in which one or more aspects of various embodiments described herein can be implemented, e.g., in the example of a mobile telephone device.

Detailed Description

Aspects of the technology described herein generally relate to background transfer services that provide platform-level support for applications to queue transfers for running in the background. This ensures that applications can perform the appropriate data transfer tasks in the background without providing the applications with full flexibility to run whatever code they want to run. Background transfer services allow applications to queue requests, cancel requests, check request status, and continue transferring (uploading/downloading) content while not running in the foreground.

The application can download the content substantially in parallel, for example via a round-robin fairness mechanism that provides resources to the application in a fair manner. The application may specify transmission preferences, however, the policy associated with the background transfer service controls what the application is able to do, e.g., the application may only have a certain maximum number of pending transfers at a time, data transfers may be limited to a certain size when cellular and WiFi are not available or in the absence of external power, the background application may not be allowed to use a 2G/EDGE cellular connection, different actions may be taken while relying on battery power, low battery, or when connecting to an AC/USB charge, etc.

Providing platform-level transport services thus enables the platform to maintain control over what transport-related task applications can execute in the background, without providing the applications with full flexibility to run arbitrary code. In addition, the background transfer service allows first and third party applications to control the amount of bandwidth and/or other device resources being used to protect the foreground experience (where "first party," as used herein, refers to trusted code such as provided by the operating system vendor, and third party refers to applications from the vendor, regardless of the source or trustworthiness of the applications). Foreground applications may request additional bandwidth for heavy bandwidth utilization activities when necessary, and background transmissions (depending on the circumstances) may throttle bandwidth to protect the foreground experience in order to limit (e.g., reduce or avoid) interference with foreground application operations.

It should be understood that any of the examples herein are non-limiting. Thus, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and data transfer in general.

In one implementation, as generally represented in fig. 1, a background transfer service 102(BTS) controls application data transfer requests according to one or more policies 103 associated with (e.g., integrated with or externally coupled to) the background transfer service 102. The background transfer service 102, via the BTS client API104, allows applications, such as the application 106, to download content from or upload content to a network endpoint even if the application 106 is not in the foreground (e.g., is being deactivated or dehydrated). This is also the case when an application has gone dormant (moved to background instead of shutdown, and the operating system maintains state information for the application to return to foreground later).

Generally, a foreground application may add a request to a request queue of a background transfer service; the foreground/background application may find and remove requests from the request queue of the background transfer service. These requests are controlled by the background transfer service 102 according to one or more policies 103. Other functionality may be provided, such as allowing status updates, as described herein. As also shown in FIG. 1, tasks and/or services 107 (e.g., first-party applications) may use background services via similar (or the same) APIs as shown in FIG. 1 set as API 105.

As described below, for security and similar reasons, each application has its own local store 108 and 109, which in one implementation is accessed via a data sharing service 110. Note that in fig. 1, different components have different access rights represented by chambers (chambers), e.g., background transfer services run in standard-rights chambers, applications run in low-privilege chambers, data sharing services 110 run in standard chambers, etc. The data sharing service 110 has access to the application's local storage 108 or 109 (which is limited to only one particular folder in storage), and the background transfer service 102 uses the data sharing service 110 to either transfer in downloaded data or transfer out data for upload. The use of the data sharing service 110 (with elevated permissions) to transfer data to and from separate stores provides additional security.

As generally represented in FIG. 2, a scenario for background transfer from the web 220 or other network source includes an application downloading an extra level of game or game content, such as a media content download/upload of an application, such as a video streaming (e.g., application 206), e-reader (e.g., application 207), full-range navigation program, and the like. Each application (e.g., 206 and 207) may have its own separate storage, shown in fig. 2 as 208 and 209, respectively.

It should be noted that foreground applications may use the background transfer service 102. In this case, the background transfer service 102 may apply different policies or have other rules, such as prioritizing foreground application transfer requests over background application transfer requests, using different restrictions (or even no restrictions), etc. Apply policies or other rules when the background application is using the service and has changed to the foreground application; raising the priority of requests it queues (other application requests may be suspended), changing or not enforcing restrictions, and so forth.

As will be appreciated, transmissions through the background transmission service 102 can proceed in parallel with reasonable fairness and, as controlled by the service 102, do not starve each other. As a result, large transfers do not infinitely block other requests, and background transfer service 102 may enforce a hard limit on the size of the content of the transfer while minimizing disruption to, for example: background audio streaming, foreground video streaming, gaming, and foreground activity using the network. Note that audio streaming is sensitive to starvation, and background transfer services attempt to not interrupt the scenario, while neither starving resource-intensive applications nor degrading the foreground experience that requires network bandwidth, e.g., music streaming, multiplayer gaming scenarios, video streaming, browsers, social networks, etc. At the same time, the service may adapt and/or otherwise operate to maximize battery life through efficient resource usage (including battery and bandwidth). Cost awareness can be another consideration, such as not allowing rogue or writing bad applications to use most of the user's limited data plans on cellular connections.

Returning to the example implementation/architecture generally represented in fig. 1, the background transfer service 102(BTS) may comprise a service that runs internally in a standard rights chamberPhone services. In this example, RPC (remote procedure call) is used as an IPC (inter-process communication) mechanism between the background transfer service clients 106, 107 and the background transfer service 102. The service 102 thus provides an RPC interface that is accessible by low privilege cavity BTS-aware (e.g., Yamanote) applications and other high privilege processes. Note that the local RPC, PSL (Process Server library) and IPC mechanisms are inAvailable in the Phone platform.

The RPC interface exposes APIs 104, 105 for queuing, cancelling and querying the status of a single transmission. The RPC interface also exposes APIs 104, 105 for RPC clients to get notifications about the progress and completion of the transfer. The background transfer service 102 persists transfer requests in its request store 112 until conditions are appropriate for the delete request (e.g., the response has been successfully sent to the requestor). The request store 112 includes persistent storage of transfer requests of background transfer service saving applications in the file system.

In one implementation, the background transfer service 102 may use the services of the entertainment download manager 114(EDM) to manage http/https transfer requests such as start, cancel, and pause requests. Although the entertainment download manager 114 is illustrated herein as a separate component, in an alternative implementation, the entertainment download manager 114 (e.g., its functionality) or a portion thereof may be incorporated into the background transfer service 102, and vice versa. Thus, as used herein, the entertainment download manager 114 may be a separate component (in whole or in part) or may be a sub-part of the background transfer service 102 (or vice versa).

The entertainment download manager 114 is essentially a direct queuing service with looping logic (e.g., partitioning the available parallel slots among one or more requesting applications) that processes requests, provides progress callbacks/notifications, etc. The entertainment download manager 114 has its own file cache 115 and request queue, and typically maintains state data to handle the following: communicate with endpoints to transfer content to or from the endpoints, use retry mechanisms if needed, and the like. The entertainment download manager 114 can also monitor notifications from the resource manager component to change transfers (e.g., in one implementation, suspend a particular transfer) when an application goes from background to foreground. As indicated by the background transfer service 102, the data sharing service 110 moves/copies data from the file cache 115 to the corresponding separate storage for each application or to the file cache 115 via a transfer folder as appropriate.

In addition, the background transfer service 102 uses the application instance manager 116(AIM) to receive notifications regarding application uninstallation and license revocation and recovery. To this end, the application instance manager 116 includes sending notifications to the background transfer service 102 regarding application uninstallation and license revocation/recovery.

As generally represented in fig. 1, a BTS-aware (e.g., third party) application 106 uses a platform-provided managed API 104. Task/service 107 may be a headless (thread) task or another background service that is part of the platform. In one implementation, the background transfer service includes a platform background service (e.g., a platform component process hosting multiple services, hosted in services. exe) that includes an RPC server-side component that implements a transfer API. The background transfer service client API may be a platform native DLL that exposes native background transfer service APIs that use local RPC to communicate with background transfer services.

As also shown in fig. 1, in one implementation, the data sharing service 110 includes a platform background service that serves as a secure intermediary for platform components that access the detached store 108 of low-privilege applications. The entertainment download manager 114 includes a background service that the platform components use to transfer content. One design of the background transfer service 102 uses the entertainment download manager 114 to interface with the winnet and perform the actual http file transfer.

Persistent storage options for the background transfer service may include any suitable data structure/mechanism, including any suitable database, register, or file per request. In the platform, EDB (embedded database engine) is used for this mechanism, in part because EDB provides reasonable support for very likely request patterns (e.g., hundreds of requests, create/delete over time), and because it supports transactions.

Figure 3 provides a system overview and numbered operational flow. The background transfer service client API304 includes a library that the application 306 references to gain access to the background transfer service 102. The client API304 creates a temporary file (within the application's separate store 308, shown for convenience in the application) for the download request, and renames or moves the temporary file to the desired file name when the download is complete. Note that in one implementation, the move is not a double write to the file system, as long as it does not span volumes, and thus improves performance. The P2 cache may be enabled to avoid flushing to flash/SD unless needed.

As represented in fig. 3 by labeled arrows one (1) and two (2), application 306 requests the token for a given file handle (via RPC) from data sharing service 110 (via client API 304) and enqueues (labeled arrow three (3)) or dequeues the request by providing the request information (token for file handle, request ID) to the background transfer service (via RPC).

The data sharing service 110 provides mechanisms for: a handle to the file is created in the application's separate store 308 and access to the handle is granted to the background transfer service 102 through the exchange of a shared secret (token). This is represented in fig. 3 by the labeled arrows four (4) and five (5).

The background transfer service 102 is responsible for managing application request queues, saving the state of requests across the lifetime of the application (on the device), managing queue priority and management, and interfacing with the data sharing service 110 to copy files from or move files to the application store (by providing tokens), as described above. Likewise, the background transfer service 102 relays progress events/queries, such as completion and fatal errors, via the client API304, as represented via labeled arrow six (6).

The application instance manager 116 provides an API or the like for obtaining information about task instances, and the background service 102 may need to confirm the identity of the task instance and make policy decisions as to whether to accept the request. The background transfer service 120 subscribes to and satisfies requests from the application instance manager 116 for uninstallation and revocation as well as other application lifetime events. The application instance manager 116 notifies the background transfer service 102 when an application registered by the background transfer service is uninstalled and its license is revoked or restored. The background transfer service 102 cancels the pending request for the application when the application is being uninstalled and suspends requests made by the application when the license for the application is revoked. The background transfer service 102 continues with these requests while the application license is restored.

In one implementation, a resource manager may be used to control the suspension and resumption of the background transfer service 102. The application instance manager 116 may disable the entertainment download manager 114. Because the request is looked up using a combination of request ID and application ID, the background transfer service has some means of determining this information in order to ensure sandboxing of the request look-up and to ensure that the application ID is not provided by the application. The product ID of an application may be obtained by invoking the security system given the process ID of the application.

Turning to additional details of one example implementation, the first step taken by the background transfer service client is to establish an RPC connection to the background transfer service server. This can be done using the sequence in fig. 4. Assume that the request ID is unique to the system and is enforced by the background transfer service 102. Note that the caller can specify whether the request ID is an existing request, in which case the background transfer service will verify the caller's product ID (using the caller process ID obtained from the RPC runtime and using that ID to retrieve the product ID from the account database) and cross-check the caller's product ID with the product ID of the existing request ID. The background transfer service 102 may also use an API call (e.g., a GetTaskInstanceInformation API) to obtain the product ID of the RPC caller from the application instance manager, which, however, requires the task ID of the client process to be passed to the API. The task ID may be passed from the background transfer service client library via RPC to btsccreatebackgroundtransferrequest (Bts creates a background transfer request). The background transfer service may independently verify the validity of the task ID by comparing the process ID of the task process obtained from the gettaskstandeinformation with the caller process ID obtained from the RPC.

Enqueuing background transfer requests is generally illustrated in fig. 5. In one implementation, the background transfer service 102 supports applications using a combination of a unique request ID string, a URI, a transfer file name, and an HTTP verb to queue file transfer requests. Verbs supported include GET (for download) and POST (for upload). In addition, the application may specify a set of allowed custom HTTP headers to be added to the request. The application may also specify whether the transmission requires the device to turn on AC power (including USB charging) and/or Wi-Fi.

An example sequence diagram for enqueuing requests is shown in fig. 5. In addition, a server-side flow of the API is also shown. The different components shown in the figures have been described above.

Note that the background transfer service client API104 communicates with the background transfer service 102 using the RPC context handle obtained in FIG. 4. The background transfer service client API104 uses the API of the data sharing service to convert the transfer filename to a file token ID string because the background transfer service (running in the standard rights chamber) does not have direct access to the separate storage of the application. The background transfer service API calls the background transfer service 102 through a local (synchronous) RPC transfer in the previously created RPC context handle and the transfer parameters described above, including the file token ID.

When the background transfer service 102 gets an RPC call, the service checks to see if the conditions are appropriate for sending the request to the entertainment download manager 114, or alternatively, whether the background transfer service enqueues the request and sends it to the entertainment download manager 114 later when the conditions are appropriate.

Fig. 6A and 6B illustrate different conditions that may be checked. For example, step 602 validates the parameters and only if validated performs step 604 for notifying the application instance manager 116.

To help optimize battery usage, the background transfer service allows applications to specify delaying transfer requests until AC power is available. In this case, the background transfer service initiates the transfer process with the entertainment download manager 114 only when the phone is powered on AC power (e.g., USB powered). In addition, the background transfer service initiates monitoring for changes in power state and if the phone is turned to battery, ongoing transfers may be suspended in the entertainment download manager 114 until the phone is returned to AC power. In addition, the background transfer service monitors for low battery status and checks the battery status at startup. If the background transfer service gets a low battery status notification, the service will suspend its queued transfers with the entertainment download manager 114. The transmission continues when the battery state transitions from a low state.

As represented via steps 606, 608, 610, and 612, if the request is not delayed and a low battery condition exists (also when the "power save mode" is on), or the request is delayed and AC power is not available, the process branches to step 628 of fig. 6B (entry point EP2) as described below. Otherwise, step 614 represents preparing the download manager and proceeds to step 620 of FIG. 6B (entry point EP 1).

Step 628 represents a successful bifurcation of step 624 or a bifurcation of one of the above-described condition sets (steps 606, 608, 610, and 612). Step 628 enqueues the request to an in-memory queue and persistently stores the request.

Step 628 represents a successful bifurcation of step 624 or a bifurcation of one of the above-described condition sets (steps 606, 608, 610, and 612). Step 628 enqueues the request to an in-memory queue, saves the request, and persists the request.

Returning to fig. 5, the background transfer service calls the application instance manager 116 to notify that the request has been accepted using NotifyRequestCreated () corresponding to step 604 of fig. 6A. The API may also return the license status of the application by calling the entertainment download manager 114, which may be used to determine whether the transfer can be initiated. If there is next a failure in the background transfer service API, the application instance manager 116 is notified with NotifyRequestCompleted () corresponding to step 626 of FIG. 6B.

The background transfer service calls the entertainment download manager 114API, DownloadManagerCreate, to create the download ID. The transmission parameters may be passed directly to the entertainment download manager 114, for example setting a flag DM _ TYPE _ CONTENT | DM _ PRIORITY _ authority | DM _ period _ LIBRARY | DM _ FETCH _ CACHED | DM _ dot _ wait _ RESPONSE _ STREAM. The transmission parameters specify a policy that 3G cellular transmissions and Wi-Fi transmissions are allowed or only Wi-Fi transmissions are allowed. The transmission parameter may also specify the transmission method, POST or GET. In addition, an application product ID (GUID) may be specified as well as a media key (identical to the application request ID). The application product ID is used by the entertainment download manager 114 to transmit across application cycles to mitigate resource starvation. The media key is used to cause the entertainment download manager 114 to store the downloaded file as a unique file to the entertainment download manager 114 persistent cache. The background transfer service 102 moves the file from the cache to the application's storage when the transfer is successful, for example using MoveFile (Mobile File) supported in the data sharing service 110. Note that the MoveFileAPI does not copy data when the move does not span different logical volumes.

In response to the DownloadManagerCreate, the entertainment download manager 114 returns a download ID, which the background transfer service saves in memory along with the remaining transfer request parameters (the download ID fails after reboot). The background transfer service then calls the entertainment download manager 114, i.e., DownloadManagerStart, and initiates the transfer process.

Upon successful invocation of the entertainment download manager 114 to initiate the transfer, the background transfer service saves the request, including the target file token ID associated with the request, to the EDB (corresponding to step 628). Note that the data sharing service 110 supports storing the file token ID across reboot persisters.

There may also be a limit to the outstanding requests for each application (e.g., five by default) and if the limit exists, it is enforced by the background transfer service. Registration settings, etc. may override the default limits. This prevents an application from consuming too many system resources such as network bandwidth, battery, background transfer service memory, transfer file space, and persistent storage space.

The background transfer service client may optionally subscribe to receive transfer progress notifications and will make application callbacks at specific completion time points of the transfer. The point in time at which the callback will be made depends on the entertainment download manager 114's callbacks to background transfer services that occur at intervals depending on the size of the file being transferred. As represented in FIG. 7, the background transfer service client may make an RPC call to the background transfer service to register progress/completion notifications using the RPC context handle obtained in the creating step. The RPC may be an asynchronous RPC, as it is undesirable to have any dedicated thread blocked in the client or server. Note that the notification may arrive at a later point in time after the asynchronous RPC call is made.

Fig. 8 and 9 show transmission progress and completion notification, respectively. Note that the background transfer service 102 listens for progress and completion notifications from the entertainment download manager 114. Upon completion, the background transfer service uses the services of the data sharing service 110 to move the transfer file to a separate store of the application in the download case. Once the request is passed to the client, the background transfer service 102 also deletes the request from its persistent storage. The application instance manager 116 may also be notified that the request has been deleted, e.g., using notifyrequestdeled ().

An application may cancel its queued transmission requests at any point in time; a sequence diagram of the cancel operation is shown in fig. 10. The request is identified using an opaque RPC context handle received as part of the creation step. Once the cancellation request is successful, the transfer request is deleted from memory and persistent storage. NotifyRequestCompleted () may also be used to notify the application instance manager 116 that the request has been completed.

The application may query the state of the transfer request it queued (fig. 11) using the request handle received after calling the btsccreatebackgroundtransferrequest (Bts creates a background transfer request) API. The following information may be returned from the most recently cached results of the entertainment download manager 114 state in the background transfer service:

request status

Hr status of transmission

Http status of transfer

Number of bytes received

Total number of bytes expected to be received

Number of bytes sent

Total number of bytes expected to be sent

The application may close the request handler at any point in time. Closing the request handle does not cancel the request, but tears down the RPC connection between the client process and the server process. If the client process dies without closing the handle, the RPC runtime uses a context handle exhaustion (rundown) callback to notify the background transfer service 102.

An application may use an API ("BtsEnumBackGroudTransferRequests" (Bts enumerates background transfer requests ") to enumerate pending requests that have been queued by itself so far.

Fig. 12 relates to suspending the background transfer service 102. A platform component, such as a resource manager, may request to suspend the background transfer service 102 (e.g., if it detects that one or more foreground networked applications are running). In response, the background transfer service uses the DownloadManageEnumDownloads API to enumerate transfers that have been queued in the entertainment download manager 114, and the task ID is specified as part of each DownloadManagerCreate call. Once the transfers are enumerated, they may be paused, for example, one by calling a DownloadManagerPause API. A download manager pausetaskdown API may be provided in the entertainment download manager 114 to enable the above sequence to be done with one API call. Once the background transfer service has been suspended, the new enqueue request is also suspended. These new enqueue requests are only resumed after a specific resume API call from the platform component.

In one implementation, there need not be a timer in the background transport service 102 for automatic resumption from suspension. The resource manager ensures that the application is in the foreground, still running, and not under lock screen. A crash of the resource manager restarts the mobile device because the resource manager is hosted in the shell program. The background transfer service 102 ensures that only the appropriate chamber caller can call the suspend API. Note that with a timer, the application can repeatedly call the API, whereby the timer provides little benefit, but has some impact on battery life, as well as other drawbacks.

Fig. 13 relates to the continue background transfer service 102. This continues any transfers that the background transfer service 102 paused earlier (e.g., due to pausing the API call). The background transfer service 102 ensures that only the appropriate chamber caller can call the resume API. The order of continuation is the same as the order of the request queue in the background transfer service. This can be done using the DownloadManagerResume API; the entertainment download manager 114 may provide an API that allows the continuation sequence to be done with one API call. For downloads, the entertainment download manager 114 will continue from the last paused point in time with the server supporting the HTTP range header.

The query background transfer service state is represented in fig. 14. The background transfer service state may be active (meaning that it is running and does not need to be transferred) or suspended and may be queried using an API. In addition, the background transfer service may also return a count of the number of transfer requests in the transferring and waiting/suspended states.

In one implementation, the transport request goes through the following states in the background transport service, as represented in fig. 15:

state 1501. Has created: the background transfer service request has been created by the background transfer service client using the btsccreatebackgroundtransferrequest API.

State 1502. Is transmitting: the background transfer service client has queued transfer requests through the background transfer service using the btsnequeuebackgroundtransferrequest (Bts enqueue background transfer request) API, and the background transfer service has passed the request to the entertainment download manager 114.

State 1503. Waiting: the transfer request is waiting in the background transfer service queue because the transfer condition has not been met (e.g., the phone is not AC powered on for a delayed transfer).

State 1504. And (3) already suspended: the background transfer service has been suspended by the first party application using the btsplasetbackgroundtransferservice (Bts suspend background transfer service) API. The request is suspended because the application instance manager 116 notifies the background transfer service 102 that the application's license has been revoked. This will suspend the transfers that were queued up so far in the background transfer service, including the waiting, transferring and created transfer states. This state, in contrast to using only the wait state, can be used by the application to distinguish whether the delay in transmission is intentional because the first-party application (e.g., resource manager application instance manager 116) has suspended transmission, or unintentional because of an unsatisfied condition.

State 1505. The following is completed: the transfer request is completed because the application cancels the transfer request using the btscan backgroundtransferrequest (Bts cancels the background transfer request) API, or completes successfully or erroneously. To optimize network bandwidth usage, the entertainment download manager 114 may detect slow and pending transmissions by checking whether the transmission rate is below a threshold value, to consider these transmissions as failed, and to apply a retry strategy to them. For example, if the transmission rate falls below x kbps over Wi-Fi, the transmission will be suspended and continue at a later time. In the event Wi-Fi is not available due to a particular error, the entertainment download manager 114 will fail transmissions in excess of 20 MB. In this case, the background transfer service will monitor the Wi-Fi connection and re-queue the transfer with the entertainment download manager 114 when Wi-Fi is supported.

If the background transfer service detects that the expected file size is too large and the transfer request is not designated to be transferred only in the AC case, the background transfer service may cancel the request with the entertainment download manager 114 and return an error to the application. The callback will carry the expected total file size and the size of the current transmission. The entertainment download manager 114 may only allow a maximum number of concurrent background transfers (e.g., by default limited to two or four or similar limits).

In addition, the entertainment download manager 114 may throttle the maximum number of concurrent transmissions (default to one) when it detects that the media stack is streaming. Note that when there is no throttling support exposed to clients (including background transfer services) for use, the background transfer service 102 must automatically pause and resume transfers based on conditions in the system.

Upon loss of the connection, the entertainment download manager 114 moves the transfer request to a wait state and begins the transfer upon restoration of the connection. If the connection is not restored within a disconnection time (timeout), the entertainment download manager 114 cancels the transfer and reports the connection timeout error to the background transfer service 102. In this case, the background transfer service will monitor the connection and re-queue the transfer with the entertainment download manager 114 when the connection is supported. The connection manager selects from the available connections based on bandwidth. Thus, absent any particular preference or requirement (or mapping policy), the connection manager would select in the following order: DTPT (desktop pass through), Wi-Fi, and cellular. Note that in one implementation, the type of connection will not change once the transfer is initiated.

The background transfer service 102 performs monitoring to queue requests in the entertainment download manager 114, including whether the device has a connection. This is done because the entertainment download manager 114 fails a transfer if a connection is not available within a certain time (e.g., default 1 minute). Thus, the background transfer service monitors connection availability. The background transfer service also monitors the power status (AC/battery, battery status) of the device.

The background transfer service may queue the application requests with the entertainment download manager 114 at the same PRIORITY, e.g., the lowest background PRIORITY of the three entertainment download manager 114 priorities (DM _ TYPE _ CONTENT, DM _ PRIORITY _ option). This is to ensure that third party transmissions do not interfere too much with first party transmissions such as market downloads.

The entertainment download manager 114 supports the passing of application IDs with each download manager create call as part of the transmission parameters. The background transfer service passes the application product ID as the application ID when it creates a transfer request with the entertainment download manager 114. The entertainment download manager 114 will use the application IDs to cycle through each queue so that requests from one application ID cannot starve other applications for resources. Thus, if the entertainment download manager 114 queue contains Appld0(0), AppId0(1), Appld1(0), Appld2(0), the scheduling algorithm picks the requests in the following order: AppId (0), AppId1(0), AppId2(0), AppId0(1), where AppIdX (y) indicates the y-th request of application X. The entertainment download manager 114 may limit the maximum number of concurrent transmissions to achieve acceptable device performance. To prevent one application from taking all of the transmission slots and transmitting large files in the entertainment download manager 114, the entertainment download manager 114 may time slice between applications on a recurring basis (e.g., two minutes) and force transmission pauses when needed. Note that the entertainment download manager 114 market download may take some time to enter the opportunistic queue and will be multiplexed with the background transfer service application and will be included in the loop.

For security, the background transfer service 102 may run in a standard rights chamber and may be co-hosted with other services in the services. RPC security policies may be specified for background transfer services to allow low privilege chamber applications to call background transfer services using RPC. The background transfer service uses the account database API to cross-check the product ID of the calling process, as appropriate, and ensure that one application cannot call the background transfer service API on behalf of another application. Note that because most background transfer service third party application APIs use RPC context handles (which are not direct but are wrapper of RPC context handles as a side effect of using request handles), these application APIs should be protected against spoofing, as the RPC runtime is hardened against the spoofing. However, btsccreatebackgroundtransferrequest does not use RPC context handles but instead uses request IDs (preferably GUIDs) because it is the API that creates the context handles. The API may be hardened for spoofing.

The background transfer service 102 is started when an application makes a first call to an API. The background transfer service then checks whether it needs to continue any previous outstanding transfers that it can initiate at boot time. For performance reasons, processing immediately after service start may be delayed, for example using the register delay bootwork API. The background transfer service 102 checks the persistent store for requested items that have been marked with an in-flight, paused, or waiting state and then sends these requested items to the entertainment download manager 114 to initiate the transfer process or queues these requested items in memory to wait for conditions appropriate to initiate the transfer process (e.g., a delayed transfer request if the phone is currently on battery). After this is done, the background transfer service may enable its RPC interface and begin receiving calls from the client. The background transfer service also calls the application instance manager 116 to indicate startup using notifybackgroudservicestart () and calls NotifyRequestCreated () to inform the application instance manager 116 that the background transfer service 102 has created a new request. When creating a new request using the btsccreatebattergroundtransferrequest API, the background transfer service 102 calls the application instance manager 116 using notifyrequesttreated only once per request.

The background transfer service 102 may also check whether its request queue has been empty for more than a certain time (e.g., two minutes) and stops itself when idle. The background transfer service 102 may be reactivated by the background transfer service client using ActivateService (). NotifyBackGroudServiceStop () will also be used to call the application instance manager 116 to indicate a stop.

For reliability and error handling, the background transfer service 102 may rely on the entertainment download manager 114 to present it with transfer errors. Once the entertainment download manager 114 reports a transfer error, or there are other background transfer service errors that prevent the request from completing, the entertainment download manager 114 will move the request to the completed state but save the so far transferred bytes, total expected bytes, and http state in persistent storage along with the request to enable the application to query it later. The application deletes the request from storage when it has taken the appropriate action on the transmission.

For application uninstall, the background transfer service 102 authors an in-process COM server that implements the IBackgroundServiceProxy interface so that the application instance manager 116 can notify the background transfer service when an application is uninstalled or its license is revoked/restored. The background transfer service notifies the application instance manager 116 of the creation and deletion of each request whenever the background transfer service 102 has started and is ready to accept notifications from the application instance manager 116.

When an application is uninstalled, the background transfer service deletes the request corresponding to the application. When the application license is revoked, the background transfer service changes the request state to a suspended state and a state indicating that the license has been revoked. In this state, APIs (btsnequeuebackgroundtransferrequest, etc.) that change the transmission request state are not made, and these APIs will fail and have a permission error. When the license is restored, the request follows the "transfer condition is satisfied" path (state 1503 to state 1502 in fig. 15).

Only a few bytes per request need be stored in memory. The candidate list (based on access rate) includes:

1. fixed length request ID

2. Fixed length application product ID

3. Request status

4. Number of bytes transmitted

5. Total number of bytes

6. Status of transmission

If data related to the request is not available, the persistent store is referenced. In one implementation, the background transfer service 102 does not arrange threads for rare events and instead uses thread pooling (pooling).

The background transfer service client may optionally subscribe to transfer progress notifications and will make application callbacks at specific completion points of the transfer. The point in time at which the callback is made depends on the entertainment download manager 114's callback to the background transfer service, which occurs at arbitrary intervals. The background transfer service client may make an RPC call to the background transfer service to register progress/completion notifications using the RPC context handle obtained in the creating step.

As can be seen, the background transfer service provides services to third party applications to transfer files to or from separate storage of the applications in the background, for example using the http/https protocol. The background transfer service provides a set of APIs to the third party application for: submitting a file transfer request, checking the request status, registration completion and progress notification or cancellation request. The background transfer service manages and processes requests even when an application has been dehydrated, terminated, or following a device reboot. The background transfer service reports the status back to the application.

Exemplary operating Environment

FIG. 16 illustrates an example of a suitable mobile device 1600 on which aspects of the subject matter described herein may be implemented. Mobile device 1600 is only one example of a device and is not intended to suggest any limitation as to the scope of use or functionality of aspects of the subject matter described herein. Neither should the mobile device 1600 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary mobile device 1600.

With reference to FIG. 16, an exemplary device for implementing aspects of the subject matter described herein includes a mobile device 1600. In some embodiments, mobile device 1600 comprises a cellular telephone, a handheld device that allows voice communication with other handheld devices, some other voice communication device, and so forth. In these embodiments, mobile device 1600 may be equipped with a camera for taking pictures, although this may not be necessary in other embodiments. In other embodiments, the mobile device 1600 includes a Personal Digital Assistant (PDA), handheld gaming device, notebook computer, printer, appliance including a set-top box, media center, or the like, or other appliance, other mobile device, or the like. In still other embodiments, mobile device 1600 may include devices that are generally considered non-mobile, such as personal computers, servers, and the like.

Components of mobile device 1600 may include, but are not limited to, a processing unit 1605, a system memory 1610, and a bus 1615 that couples various system components including the system memory 1610 to the processing unit 1605. The bus 1615 may include any of several types of bus structures including a memory bus, a memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures, and the like. The bus 1615 allows data to be transferred between the various components of the mobile device 1600.

Mobile device 1600 may include a variety of computer-readable media. Computer readable media can be any available media that can be accessed by mobile device 1600 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by mobile device 1600.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, BluetoothWireless USB, infrared, Wi-Fi, WiMAX, and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The system memory 1610 includes computer storage media in the form of volatile and/or nonvolatile memory and may include Read Only Memory (ROM) and Random Access Memory (RAM). On mobile devices, such as cellular telephones, operating system code 1620 is sometimes included in ROM, although in other embodiments this is not required. Similarly, the application programs 1625 are typically located in RAM, although in other embodiments the application programs may be located in ROM or other computer readable memory. Heap 1630 provides memory for state associated with operating system 1620 and application programs 1625. For example, operating system 1620 and application programs 1625 may store variables and data structures in heap 1630 during their operation.

The mobile device 1600 may also include other removable/non-removable, volatile/nonvolatile memory. By way of example, FIG. 16 shows a flash memory card 1635, a hard drive 1636, and a memory stick 1637. For example, the hard drive 1636 may be miniaturized to fit in a memory slot. Mobile device 1600 may interface with these types of nonvolatile removable memories via removable memory interface 1631 or may be connected via a Universal Serial Bus (USB), IEEE 16394, one or more wired ports 1640, or an antenna 1665. In these embodiments, removable memory devices 1635-1637 may interface with the mobile device via communication module 1632. In some embodiments, not all of these types of memories may be included on a single mobile device. In other embodiments, one or more of these and other types of removable memory may be included on a single mobile device.

In some embodiments, hard disk drive 1636 may be connected in a manner that is more permanently attached to mobile device 1600. For example, the hard disk drive 1636 may be connected to an interface such as a Parallel Advanced Technology Attachment (PATA), a Serial Advanced Technology Attachment (SATA), or other attachment to the bus 1615. In such embodiments, removing the hard drive may involve removing a housing of the mobile device 1600 and removing screws or other fasteners that connect the hard drive 1636 to support structures within the mobile device 1600.

Removable storage devices 1635-1637 and their associated computer storage media, described above and illustrated in fig. 16, provide storage of computer readable instructions, program modules, data structures, and other data for mobile device 1600. For example, the removable memory devices 1635-1637 may store images captured by the mobile device 1600, voice recordings, contact information, programs, data for programs, and so forth.

A user may enter commands and information into the mobile device 1600 through input devices such as a keyboard 1641 and a microphone 1642. In some embodiments, the display 1643 may be a touch-sensitive screen and may allow a user to enter commands and information thereon. A keyboard 1641 and a display 1643 may be connected to the processing unit 1605 through a user input interface 1650 coupled to the bus 1615, but may be connected by other interface and bus structures, such as a communications module 1632 and a wired port 1640. Motion detection 1652 can be used to determine gestures made with device 1600.

For example, a user may communicate with other users via speaking into the microphone 1642 and via text messages entered on the keyboard 1641 or touch-sensitive display 1643. Audio unit 1655 can provide electrical signals to drive speaker 1644 and receive and digitize audio signals received from microphone 1642.

The mobile device 1600 may include a video unit 1660 that provides signals to drive a camera 1661. The video unit 1660 may also receive images obtained by the camera 1661 and provide the images to the processing unit 1605 and/or memory included on the mobile device 1600. The images obtained by camera 1661 may include video, one or more images that do not form a video, or some combination thereof.

Communication module 1632 may provide signals to and receive signals from one or more antennas 1665. One of the antennas 1665 can transmitAnd receives messages for the cellular telephone network. Another antenna can transmit and receive BluetoothA message. Yet another antenna (or shared antenna) may transmit and receive network messages via a wireless ethernet network standard.

Still further, the antenna provides location-based information, such as GPS signals, to the GPS interface and mechanism 1672. The GPS mechanism 1672, in turn, makes the corresponding GPS data (e.g., time and coordinates) available for processing.

In some embodiments, a single antenna may be used to transmit and/or receive messages for more than one type of network. For example, a single antenna may transmit and receive voice and packet messages.

When operating in a networked environment, mobile device 1600 may be connected to one or more remote devices. The remote devices may include a personal computer, a server, a router, a network PC, a cellular telephone, a media playback device, a peer device or other common network node, and typically include many or all of the elements described above relative to the mobile device 1600.

Aspects of the subject matter described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the subject matter described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Aspects of the subject matter described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a mobile device. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Aspects of the subject matter described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

Further, while the term server is frequently used herein, it can be appreciated that the term can also encompass a client, a collection of one or more processes distributed across one or more computers, one or more stand-alone storage devices, a collection of one or more other devices, a combination of one or more of the above, and the like.

Conclusion

While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.

Claims (11)

1. A system comprising a background transfer service module (102) configured to run on a mobile device at a platform level to control transfer of network communications for a plurality of applications (106) while the plurality of applications are in the background, the background transfer service module configured to manage application requests for data transfers based on one or more policies (103) associated with the background transfer service module that control resource usage for background application data transfers to limit interference with foreground application operations,

wherein the data transfer comprises a data transfer from a first background application and a second background application, and the managing comprises prioritizing a first data transfer for the first background application over a second data transfer for the second background application based on the one or more policies;

wherein the one or more policies include one or more of: only a maximum number of pending transmissions at a time, a data size-based limit, a connection rule, a bandwidth limit, and the one or more policies may be based on one or more conditions, the one or more conditions including: other application data transfer requests, available cellular services, Wi-Fi availability, desktop browsing availability, power status, battery level, and/or charge status.

2. The system of claim 1, further comprising a download manager configured to remotely connect for data transfer with a remote source to satisfy a transfer request.

3. The system of claim 2, further comprising a data sharing service module configured to move or copy data transmitted from the remote source to a separate store associated with an application, or to move or copy data from a separate store associated with the application for transmission of the data to the remote source, or both.

4. The system of claim 1, further comprising an application instance manager configured to provide one or more notifications to the background transfer service module regarding: an application uninstall state, a license revocation or recovery state, or any combination of uninstall state, license revocation or recovery state.

5. In a computing environment, a method to be executed at least in part on at least one processor using a background transfer service configured to run on a mobile device at a platform level, the method comprising:

transmitting (1502) data on behalf of a plurality of applications, the applications being at least one application (106) that is a background application during at least a portion of the transmission of the data, including receiving a data transmission request from each application, and

managing (622, 628) data transfer requests for each application based on one or more policies associated with the background transfer service to maintain control over resource usage while transferring the data for that application;

wherein the at least one application includes from a first background application and a second background application, and the managing includes prioritizing a first data transfer request from the first background application over a second data transfer request from the second background application based on the one or more policies;

wherein the one or more policies include one or more of: only a maximum number of pending transmissions at a time, a data size-based limit, a connection rule, a bandwidth limit, and the one or more policies may be based on one or more conditions, the one or more conditions including: other application data transfer requests, available cellular services, Wi-Fi availability, desktop browsing availability, power status, battery level, and/or charge status.

6. The method of claim 5, wherein managing the data transfer requests for each application comprises determining whether one or more transfer conditions are satisfied for at least one application, and if not, moving the requests to a wait state until the one or more transfer conditions are satisfied.

7. The method of claim 5, wherein managing the data transfer requests for each application comprises throttling the data transfer based on available bandwidth for at least one application.

8. The method of claim 5, wherein managing the data transfer requests for each application comprises determining whether one or more transfer conditions are satisfied for at least one application, and if not, moving the request to a wait state until the one or more transfer conditions are satisfied; or determining whether to allow the request based on a size of data to be transmitted; or throttle the data transmission based on available bandwidth; or any combination of the following: determining whether one or more transmission conditions are satisfied, and if not, moving the request to a wait state until the one or more transmission conditions are satisfied; determining whether to allow the request based on a size of data to be transmitted; or throttle the data transmission based on available bandwidth.

9. A method of using a background transfer service configured to run on a mobile device at a platform level, comprising:

receiving data transfer requests from a plurality of applications including a first background application and a second background application, the data transfer requests including a first data transfer request to download data on behalf of the first background application and a second data transfer request to download data on behalf of the second background application;

prioritizing the first data transfer request over the second data transfer request based on one or more policies that control use of background application data transfers, wherein the one or more policies include one or more of: only a maximum number of pending transmissions at a time, a data size-based limit, a connection rule, a bandwidth limit, and the one or more policies may be based on one or more conditions, the one or more conditions including: other application data transfer requests, available cellular services, Wi-Fi availability, desktop browsing availability, power status, battery level, and/or charge status;

queuing (628) information corresponding to the first data transfer request in a request queue;

processing information from the request queue, including downloading data into a request store (112) on behalf of the first background application (1502); and

communicating with a service (110) having access to move or copy the data from the requesting storage to a separate storage (108) associated with the first background application.

10. The method of claim 9, further comprising receiving a request from one or more of the first and the second background applications for state information related to download state, and returning state information in response to the request.

11. A system using a background transfer service configured to run on a mobile device at a platform level, comprising:

means for receiving data transfer requests from a plurality of applications including a first background application and a second background application, the data transfer requests including a first data transfer request to download data on behalf of the first background application and a second data transfer request to download data on behalf of the second background application;

means for prioritizing the first data transfer request over the second data transfer request based on one or more policies that control use of background application data transfers, wherein the one or more policies include one or more of: only a maximum number of pending transmissions at a time, a data size-based limit, a connection rule, a bandwidth limit, and the one or more policies may be based on one or more conditions, the one or more conditions including: other application data transfer requests, available cellular services, Wi-Fi availability, desktop browsing availability, power status, battery level, and/or charge status;

means (628) for queuing information corresponding to said first data transfer request in a request queue;

means for processing information from the request queue, including means for downloading (1502) data into a request store (112) on behalf of the first background application; and

means for communicating with a service (110) having access to move or copy the data from the requesting storage to a separate storage (108) associated with the first background application.