Preloading of applications and in-application content on user devices

Abstract

A method includes, in a user device (24) running an operating system (OS‑48), determining to preload at least a user interface (UI) display of a user application (26). At least the UI display is preloaded in a simulated foreground mode, in which the UI display is (i) processed by the user application in foreground mode, but (ii) maintained in a background mode by the OS and hidden from a user of the user device.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 975,789 filed on February 13, 2020, U.S. Provisional Patent Application No. 62 / 986,807 filed on March 9, 2020, U.S. Provisional Patent Application No. 63 / 066,271 filed on August 16, 2020, U.S. Provisional Patent Application No. 63 / 118,068 filed on November 25, 2020, and U.S. Provisional Patent Application No. 63 / 128,220 filed on December 21, 2020, the disclosures of which are incorporated herein by reference. Field of the Invention

[0003] The present invention relates generally to communication systems, and more particularly to methods and systems for preloading applications and content in user equipment. Background of the Invention

[0005] In an application ("app") running on a user device (such as a smartphone), one of the main factors affecting the user experience is the latency of the user interface (UI). Various techniques have been proposed for reducing latency and providing a more responsive UI. Some techniques involve prefetching of content. Other techniques involve background preloading of the app. Still other techniques involve prerendering of the UI of the app. For example, such techniques are described in PCT International Publication WO 2018 / 055506, entitled "An Optimized CDN for the Wireless LastMile," which is incorporated herein by reference.

[0006] PCT International Publication WO 2019 / 171237, entitled “Application Preloading in the Presence of User Actions,” describes a method in a processor of a user device, the disclosure of which is incorporated herein by reference. The method includes preloading one or more user applications in background mode. An activity that is called in the processor and associated with a given preloaded user application is detected. The processor evaluates whether the activity is a preload-initiated activity that is called due to the preloading of a given user application, or whether the activity is a user-initiated activity that is called due to an action of a user. If the activity is evaluated as a preload-initiated activity, the activity is processed using a first processing scheme. If the activity is evaluated as a user-initiated activity, the activity is processed using a second processing scheme that is different from the first processing scheme. SUMMARY OF THE INVENTION

[0008] Embodiments of the invention described herein provide a method comprising determining, in a user device running an operating system (OS), to preload at least a user interface (UI) display of a user application, and preloading at least the UI display in a simulated foreground mode, wherein (i) the UI display is processed by the user application in the foreground mode, but (ii) is maintained by the OS in the background mode and hidden from a user of the user device.

[0009] In some embodiments, the method also includes maintaining, by the OS, (i) one or more first data structures for storing non-preloaded UI displays and (ii) one or more second data structures for storing preloaded UI displays, and preloading the UI display includes initially assigning the UI display to one of the second data structures and then reassigning the UI display to one of the first data structures in response to meeting a criterion.

[0010] In an embodiment, upon determining that preloading of a UI display is successfully completed, or upon user interaction with a user application, reallocation of the UI display to one of the first data structures is performed. In an example embodiment, one or more first data structures include one or more first stacks of non-preloaded UI displays, and one or more second data structures include one or more second stacks of preloaded UI displays. In another embodiment, one or more first data structures include target displays associated with non-preloaded UI displays, and one or more second data structures include one or more virtual displays associated with preloaded UI displays.

[0011] In the disclosed embodiment, the preloading UI display includes a lifecycle event of the OS specified by the application as an active foreground process.

[0012] In some embodiments, the method includes determining that preloading of the UI display is successfully completed according to the completion criteria, and in response, transitioning the UI display to a preloaded background state in which both the OS and the user application consider the UI display to be in the background. Determining that the preloading is successfully completed may include detecting expiration of a maximum duration set for the simulated foreground mode. Additionally or alternatively, determining that the preloading is successfully completed may include receiving a notification of the successful completion of the preloading from the user application.

[0013] In another embodiment, the method includes discarding the preloaded UI display in response to detecting an error occurring in the simulated foreground mode. In yet another embodiment, preloading at least the UI display includes preventing the preloading from affecting one or more of: (i) a recent list of the user device, (ii) a usage metric of the user device, and (iii) a decision related to entering a power saving state.

[0014] In an embodiment, preloading at least the UI display includes notifying the user application via an application programming interface (API) that the UI display is being preloaded. Additionally or alternatively, preloading at least the UI display may include notifying the user application via an application programming interface (API) that the user application detects user interaction with the preloaded user application.

[0015] In some embodiments, preloading at least the UI display includes preloading at least a portion of the user application launched from the entry point UI display of the user application. In an example embodiment, preloading the user application includes preloading the entry point UI display and one or more additional UI displays according to the launch sequence of the user application. In another embodiment, preloading the user application includes preloading the given UI display only when verifying that the call to the given UI display is preload-initiated rather than user-initiated.

[0016] In another embodiment, preloading the user application includes determining that preloading of the user application is successfully completed by detecting expiration of a maximum defined duration. In yet another embodiment, preloading the user application includes determining that preloading of the user application is successfully completed by receiving a notification of successful completion of preloading from the user application. In yet another embodiment, preloading the user application excludes preloading of one or more of: (i) content that changes at a rate exceeding a predefined rate, and (ii) content whose preloading requires acquisition over a network.

[0017] In some embodiments, preloading at least a UI display includes preloading one or more in-app UI displays that are associated with a user application but are not immediately displayed when the user application is launched. In an embodiment, preloading of the in-app UI displays is performed when the user application is running in a foreground mode. In another embodiment, preloading of the in-app UI displays is performed when the user application is running in a background mode.

[0018] In some embodiments, preloading the UI display within the app includes caching the UI display within the preloaded app in a memory of the user device, and providing the UI display within the preloaded app from the memory in response to a request from the user application. In a disclosed embodiment, caching the UI display within the app includes assigning a corresponding expiration time to each UI display within the app, and providing the UI display within the app from the memory only in response to verifying that the expiration time has not expired.

[0019] In some embodiments, the method includes maintaining a preload policy for preloading displayed by the management UI. Maintaining the preload policy may include running a system app for maintaining the preload policy in the user device. In an embodiment, maintaining the preload policy includes setting the preload policy through communication between the system app and a network-side server.

[0020] In some embodiments, preloading at least the UI display includes preloading the UI display with a target orientation different than a current display orientation of the user device. In an example embodiment, the target orientation is an orientation in which the user is predicted to access the user application.

[0021] In an embodiment, preloading at least the UI display includes acquiring content for the UI display over a network, the quality of the content being higher than a quality for real-time acquisition of the content. In another embodiment, deciding to preload at least the UI display includes receiving an explicit request from a user to preload a user application. In another embodiment, the method includes presenting information to the user indicating a progress of preloading at least the UI display.

[0022] According to an embodiment of the present invention, a user device including a display screen and a processor is further provided. The display screen is configured to display a user interface (UI) display of a user application to a user. The processor is configured to run an operating system (OS) of the user device, determine to preload at least the UI display of the user application, and preload at least the UI display in a simulated foreground mode, wherein the UI display (i) is processed by the user application in the foreground mode, but (ii) is maintained in the background mode by the OS and hidden from the user of the user device.

[0023] The present invention will be more fully understood from the following detailed description of embodiments of the present invention in conjunction with the accompanying drawings, in which: BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 is a block diagram schematically illustrating a communication system using preloading according to an embodiment of the present invention;

[0026] Figure 2 and Figure 3 is a diagram schematically illustrating a data structure for processing preloaded and non-preloaded activities according to an embodiment of the present invention;

[0027] Figure 4 is a state diagram schematically illustrating preloading of activities according to an embodiment of the present invention; and

[0028] Figure 5A and Figure 5B 1 is a state diagram schematically illustrating life cycle states of a foreground loading activity and a background preloading activity according to an embodiment of the present invention. DETAILED DESCRIPTION

[0029] definition

[0030] This disclosure refers to operations and processes such as preloading and prerendering of applications ("apps") and app components such as user interface (UI) displays.

[0031] In this context, the term "preloading" refers to the process of loading, launching, and at least partially running an app in a background mode that is not noticeable to the user, not in response to (and usually before) a user call to the app. App components that can be preloaded include, for example, the app's main feed, other UI displays of the app, and / or content within the app (i.e., app content that is not immediately visible to the user when the app is launched). In this context, the term "UI display" refers to a logical UI element - a view or window used by an app to interact with the user. For example, in the Android operating system (OS), a UI display is called a view or activity.

[0032] The term "prerendering" refers to the process of building an app's UI display in background mode. Prerendering is considered to be an integral part of the preload operation herein. Prerendering can involve UI tasks that modify the UI display, and / or UI tasks that do not directly modify the UI display but are a prerequisite for such modification or synchronized with the modification of the UI display in the background. Thus, for example, initialization or preparation tasks performed when preloading an app and preparing to initialize or modify the app's UI display are also considered prerendering tasks herein.

[0033] Overview

[0034] Embodiments of the invention described herein provide improved methods and systems for preloading user applications ("apps") and their content in user devices. The disclosed preloading scheme reduces the delay perceived by the user when interacting with the app and thus provides an enhanced user experience.

[0035] In some embodiments, a user device runs an operating system (OS) that, among other things, preloads UI displays for user apps. The disclosed techniques can be used to preload individual UI displays, groups of interrelated UI displays, or entire apps. For clarity, by way of example, the following description primarily relates to the Android OS and Android activities. However, the disclosed techniques are applicable to any other suitable OS and any other suitable type of UI display.

[0036] In some disclosed embodiments, the OS preloads an activity using a novel operating mode referred to herein as "foreground simulation" or "simulated foreground." In this mode, the app processes the activity in foreground mode, but the OS maintains the activity hidden from the user in background mode. In other words, the activity that is undergoing foreground simulation is in the foreground from the app's perspective, but in the background from the OS's perspective. In some embodiments, the app is unaware of the fact that the activity was preloaded in the background and not conventionally loaded in the foreground. In other embodiments, the OS notifies the app that the activity was preloaded in the background, enabling the app to use different program code intended for foreground simulation.

[0037] The disclosed foreground simulation mode enables an activity to be preloaded, including prerendering and other suitable preload-related operations, optionally using existing app program code, while still keeping the activity in the background unnoticeable to the user.

[0038] This article describes various aspects of foreground simulation, including implementation examples of preloading activities, apps and content within apps, criteria for terminating foreground simulation, and implementation using existing foreground lifecycle states / events of the OS. In some embodiments, the disclosed technology is implemented using an application programming interface (API) provided by the OS to user apps.

[0039] In some embodiments, the OS keeps the preload operation transparent to the user by isolating the preloaded activities from the non-preloaded activities. In particular, the OS can store the preloaded activities and the non-preloaded activities in separate data structures (e.g., separate tasks, task stacks, and / or displays). When it is necessary to display the preloaded activities to the user, the OS typically moves the activities from the data structures dedicated to the preloaded activities to the data structures dedicated to the non-preloaded activities.

[0040] Other disclosed embodiments are directed to triggering preloading through explicit user requests, and to providing user information indicating the progress of preloading.

[0041] System Description

[0042] Figure 1 is a block diagram schematically illustrating a communication system 20 using preloading according to an embodiment of the present invention.

[0043] System 20 includes a user device 24 running one or more user applications ("apps") 26. Device 24 may include any suitable wireless or wired device, such as, for example, a cellular phone or smartphone, a wireless-enabled laptop or tablet computer, a desktop personal computer, a video game console, a smart TV, a wearable device, an automotive user device, or any other suitable type of user device capable of presenting content to a user. For clarity, the figure shows a single user device 24. Real-life systems typically include a large number of user devices of various types.

[0044] In this context, the terms "user application", "application" and "app" are used interchangeably and refer to any suitable computer program that runs on a user device and can be called (activated) by a user. Some apps 26 may be dedicated special-purpose applications, such as gaming apps. Other apps 26 may be general-purpose applications, such as web browsers.

[0045] In some embodiments (although not necessarily), app 26 is provided by one or more network-side servers (e.g., portal 28) and / or communicates with one or more network-side servers via network 32. Network 32 may include, for example, a wide area network (WAN) such as the Internet, a local area network (LAN), a wireless network such as a cellular network or a wireless LAN (WLAN), or any other suitable network or combination of networks.

[0046] In this example, the user device 24 includes a processor 44 that performs various processing tasks of the user device. Among other tasks, the processor 44 runs an operating system (OS) 48, which in turn runs apps 26. The embodiments described herein are primarily related to the Android OS. However, the disclosed technology is applicable to any other suitable OS that can be run on a user device, such as iOS, Windows, Linux, etc. OS 48 includes a software component called a preload agent 50 that handles the preloading of apps. Apps 26, OS 48, and preload agent 50 are schematically drawn inside the processor 44 to indicate that they include software running on the processor.

[0047] In addition, the user device 24 includes non-volatile memory (NVM) 54, such as flash memory. The NVM 54 can be used, among other things, to store a cache memory 52 for caching content associated with the app. In some embodiments, the user device uses a single cache 52. In other embodiments, also schematically depicted in the figure, a separate cache memory 52 can be defined for each app. Hybrid implementations are also possible, in which a portion of the cache 52 is centralized and some is app-specific. For clarity, the following description will simply refer to "cache 52," meaning any suitable cache configuration.

[0048] The user device 24 also includes a display screen 56 for presenting visual content to the user, and a suitable network interface (not shown in the figure) for connecting to the network 32. The network interface can be wired (e.g., an Ethernet network interface controller NIC) or wireless (e.g., a cellular modem or a Wi-Fi modem). Typically, the user device 24 also includes some internal memory, such as a random access memory (RAM) (not shown in the figure) for storing relevant code and / or data.

[0049] exist Figure 1In an example embodiment (but not required), the system 20 also includes a preload server 60 that performs preload-related tasks on the network side. The server 60 includes a network interface 64 for communicating over the network 32, and a processor 68 that performs various tasks of the preload server. In this example, the processor 68 runs a preload control unit 72 that performs network-side preload-related tasks.

[0050] Tasks related to network-side preloading may include, for example, deciding which apps to preload and when to preload, choosing whether to preload and which content within apps to preload, deciding how many app components to preload (e.g., executing only some initial executable code, or prerendering of the app's user interface and / or decisions about the duration of the foreground simulation). Another possible network-side preloading-related task may include, for example, deciding an applicable preloading mode (e.g., offline preloading in which access to the network is restricted or prohibited, or online preloading in which network access is allowed). For example, preloading modes are discussed in PCT application PCT / IB2020 / 057046, the disclosure of which is incorporated herein by reference. Yet another example is a "whitelist" of apps that are allowed to be preloaded as described below. In an embodiment, the preloading server 60 may be implemented as a cloud-based application.

[0051] In the embodiments described herein, for clarity, the preloading tasks are described as being performed by the processor 44 of the user device 24. However, in general, the preloading tasks may be performed by the processor 44 of the device 24, the processor 68 of the server 60, or both.

[0052] Preloading the app 26 may involve preloading any app elements, such as executable code associated with the app, e.g., launch code, an app feed, an app login page, various UI elements associated with the app, content associated with the app, app data associated with the app, and / or code or content available using the app through a user action such as a click (“content within the app”). Prerendering of content may involve background processing of any suitable type of UI display or portion thereof. For example, in Android terminology, prerendering may include background processing of one or more Android activities. In background mode, UI elements associated with the app are not presented to the user on the display screen 56, i.e., are hidden from the user. When the user invokes the previously preloaded app, the user device switches to running the app in a foreground mode visible to the user. (For the sake of brevity, the terms “background mode” and “foreground mode” are referred to herein as “background” and “foreground.”)

[0053] Figure 1The configurations of the system 20 and its various elements shown in are example configurations, which are selected only for the purpose of conceptual clarity. In alternative embodiments, any other suitable configuration can be used. For example, in some embodiments, the preload task can be implemented entirely in the processor 44 of the user device 24, in which case the subsystem 60 can be completely eliminated.

[0054] The preloading agent 50 may be implemented in a software module running on the processor 44, in an application running on the processor 44, in a software development kit (SDK) embedded in an application running on the processor 44, as part of an OS running on the processor 44 (possibly added to the OS by a user device vendor or other party), in a proxy server running on the processor 44, using a combination of two or more of the above, or in any other suitable manner. In most of the following description, it is assumed that the preloading agent 50 is part of the OS 48 of the user device 24.

[0055] Although the embodiments described herein primarily refer to human users, the term "user" also refers to machine users. For example, machine users may include various host systems that use wireless communications, such as host systems in various Internet of Things (IoT) applications.

[0056] The different elements of the system 20 may be implemented using suitable software, using suitable hardware (e.g., using one or more application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs)), or using a combination of hardware and software elements. The cache 52 may be implemented using one or more memory or storage devices of any suitable type. In some embodiments, the preload agent 50 and / or the preload server 60 may be implemented using one or more general purpose processors programmed in software to perform the functions described herein. For example, the software may be downloaded to the processor in electronic form over a network, or the software may alternatively or additionally be provided and / or stored on a non-transitory tangible medium, such as magnetic storage, optical storage, or electronic storage.

[0057] Preloading of activities, and isolation between preloaded and non-preloaded activities

[0058] In some embodiments of the present invention, a preload agent 50 in the OS 48 of the user device 24 preloads one or more UI displays of one or more apps to reduce the delay experienced by the user. The description herein mainly refers to Android activities as examples of UI displays, but the disclosed techniques can be used to preload any other suitable type of UI display. The disclosed techniques can be applied to the preloading of individual activities, apps, and content within apps with some changes.

[0059] The OS 48 typically maintains one or more "tasks" of activities. The term "task" refers to a container for storing activities that a user interacts with while performing some work. The activities stored in a task may belong to a single app or to multiple different apps (for example, when one app opens an activity of another app).

[0060] In some embodiments, OS 48 associates each task with a "task stack". The term "task stack" refers to a container that holds different tasks in some logical order, such as a stack order (last in, first out). The order relates to the order in which activities are displayed, for example, which activity is displayed on top of it. OS 48 can also apply a logical order between different task stacks. In Android OS, a "task stack" is sometimes referred to as an "activity stack".

[0061] When an application is preloaded, the OS 48 takes various measures to keep the preload operation unnoticeable to the user. Thus, for example, the OS ensures that the preloaded activity is invisible to the user and that the preload operation does not affect the OS's "recents" screen (also known as the "overview screen," "recent task list," "recent apps," "recent view," or "recently used apps").

[0062] In some embodiments, OS 48 keeps the preload operation subtle from the user by isolating the preloaded activities and non-preloaded activities in separate data structures (e.g., separate tasks and task stacks). When it is necessary to display the preloaded activities to the user, the OS moves the activities from the data structures dedicated to preloaded activities to the data structures dedicated to non-preloaded activities.

[0063] Figure 2 is a diagram schematically illustrating data structures used by OS 48 to handle preloaded and non-preloaded activities according to an embodiment of the present invention.

[0064] As can be seen, OS 48 is configured to handle multiple non-preloaded activities 80. Non-preloaded activities are associated with one or more "non-preloaded tasks" 84. Each non-preloaded task 84 is a stack that stores some non-preloaded activities in a specific logical order. Non-preloaded tasks 84 are associated with one or more non-preloaded task stacks 88 (for clarity, only one task stack is seen in the figure). Each non-preloaded task 84 is associated with one of the non-preloaded task stacks 88.

[0065] The OS 48 maintains a similar but separate hierarchy for preloaded activities 92. Preloaded activities 92 are associated with one or more "preloaded tasks" 96. Each preloaded task 96 is a stack that stores some preloaded activities in a specific logical order. The preloaded tasks 96 are in turn associated with one or more preloaded task stacks 100 (again, only one preloaded task stack is seen in the figure for clarity). Each preloaded task 96 is associated with one of the preloaded task stacks 100.

[0066] Therefore, in some embodiments, OS 48 stores non-preloaded activities in a hierarchy of data structures (non-preloaded activities, non-preloaded tasks, and non-preloaded task stacks). OS 48 stores preloaded activities in another separate hierarchy of data structures (preloaded activities, preloaded tasks, and preloaded task stacks).

[0067] Typical features of the isolation or separation between the processing of preloaded and non-preloaded activities are:

[0068] ■Non-preloaded tasks hold only non-preloaded activities, not preloaded activities. Non-preloaded task stacks hold only non-preloaded tasks, not preloaded tasks. Similarly, preloaded tasks hold only preloaded activities, not non-preloaded activities; and preloaded task stacks hold only preloaded tasks, not non-preloaded tasks.

[0069] ■ Non-preloaded activities, tasks, and task stacks are not affected by preloaded activities, tasks, and task stacks. For example, there is no stacking or other ordering between preloaded tasks and non-preloaded tasks; and there is no stacking or other ordering between preloaded task stacks and non-preloaded task stacks.

[0070] ■ Preloading of activities and / or creation of preloaded tasks and task stacks do not affect the "Recent" screen of OS 48. Therefore, if a task is on the Recent screen, it will remain on the Recent screen even if any actions are applied to the preloaded activities, preloaded tasks, or preloaded task stacks. For the same reason, if a task is not on the Recent screen, then due to some preloading related action, it will not be added to the Recent screen. In addition, the order in which tasks appear in the Recent view is not affected by the preloading action.

[0071] The data structures described above and their processing by OS 48 simplify the implementation of the preload operation and ensure that the preload operation is not noticeable to the user.

[0072] Figure 3FIG. 4 is a diagram schematically showing a data structure for processing preloaded and non-preloaded activities according to another embodiment of the present invention. In this embodiment, OS 48 supports Figure 2 An additional level of hierarchy above the hierarchy of , namely the "display" hierarchy.

[0073] In this context, the term "display" refers to a logical construct, such as a container, for storing activities. Each display has properties and states. Properties are fixed attributes that characterize a display, such as height, width, density, color mode, supported refresh rates, and special features such as high dynamic range (HDR). States include variable properties of a display, for example, display orientation (portrait or landscape). A display can be defined as a virtual display, i.e., a display that is not associated with physical hardware and whose content is therefore not displayed to the user. Instead, a virtual display allows content to be rendered to a virtual surface, where a surface is an object that holds pixels.

[0074] In some embodiments, the OS 48 defines a default display 104 (whose contents are actually displayed to the user on the display screen 56) and one or more virtual displays 108 dedicated to preloading (referred to as "preloaded virtual displays"). All non-preloaded task stacks 88 are associated with the default display 104. Each preloaded task stack 100 is associated with one of the preloaded virtual displays 108. In an example implementation, there is a one-to-one correspondence between the preloaded task stacks 100 and the preloaded virtual displays 108, i.e., each preloaded task stack 100 is associated with a single corresponding preloaded virtual display 108.

[0075] The additional hierarchy retains the separation between the preloaded and non-preloaded activities described above. For example, the default display 104 includes only non-preloaded task stacks and no preloaded task stacks; the preloaded virtual display includes only preloaded task stacks and no non-preloaded task stacks.

[0076] Figure 3 The configuration of the display depicted in is selected purely as an example. In alternative embodiments, any other suitable configuration may be used. For example, a strict one-to-one correspondence is not necessarily required between the preloaded task stacks 100 and the preloaded virtual displays 108, that is, a certain virtual display 108 may include two or more preloaded task stacks 100. As another example, the OS may maintain multiple conventional (non-virtual) displays simultaneously. Additional aspects of preloading using virtual displays are further discussed in the "Additional Embodiments and Variations" section below.

[0077] Use foreground to simulate preloading activities

[0078] In some embodiments, the preload agent 50 preloads one or more activities of one or more user apps 26 using a special operating mode called "foreground simulation" or "simulated foreground." In this mode, the app 26 processes the activity in foreground mode, but the OS 48 maintains the activity hidden from the user in background mode. In other words, the activity being foreground simulated is in the foreground from the app's perspective and in the background from the OS's perspective.

[0079] Foreground emulation mode enables an activity to be preloaded, including prerendering and other appropriate preload-related operations, optionally using existing app code, while still keeping the activity in the background unnoticeable to the user.

[0080] In various embodiments, OS 48 may use various techniques to keep the activity in the background even if the app processes the activity as if it were in the foreground. For example, preload agent 50 may override one or more final system calls that cause the activity window to be displayed on display screen 56 of user device 24. As another example, preload agent 50 may associate the activity with a virtual display that is not linked to an actual physical display. Using a virtual display for preloading is explained in detail below.

[0081] In some embodiments, preloading of activities includes the following steps, possibly in different orders, or subsets thereof:

[0082] ■The OS 48 determines that a certain activity of a certain app 26 will be preloaded.

[0083] ■The OS grants the app permission to act as if it is running in the foreground as opposed to a potentially more restricted background state, but in reality the OS keeps the app in the background. For example, the OS might grant the app permission to start an activity.

[0084] ■If the process of the app in question is not alive, the OS will create an app process for the app.

[0085] ■ If the activity is not already associated with a task, the OS creates a preloaded task 96 for the activity.

[0086] ■ The OS marks the activity as a preloaded activity 92. This marking may be performed, for example, by marking the activity itself, by marking a preloaded task that holds the activity, or implicitly, for example, by placing the preloaded task in a preloaded task stack 100 that is marked as such, and / or by placing the preloaded task in a preloaded task stack 100 that is itself explicitly or implicitly marked as preloaded by placing the preloaded task stack in a preloaded virtual display 108.

[0087] ■ If the preloaded task 96 is not already associated with a preloaded task stack 100, the OS creates a preloaded task stack and associates the preloaded task with the task stack, or alternatively associates the preloaded task with an existing preloaded task stack. In some embodiments, the OS may maintain a single preloaded task stack, created on demand or in advance, or multiple task stacks. For example, the OS may create a preloaded task stack for each app or each preloaded task.

[0088] ■In some embodiments, if the preloaded task stack 100 is not already associated with a preloaded virtual display 108, the OS creates a preloaded virtual display and associates the preloaded task stack with the preloaded virtual display, or alternatively associates the preloaded task stack with an existing preloaded virtual display. In some embodiments, the OS may maintain a fixed number of preloaded virtual displays that are created on demand or in advance, or maintain a dynamic number of preloaded virtual displays. For example, the OS may create a preloaded virtual display for each app, or for each preloaded task stack, or for each preloaded task.

[0089] ■ In some embodiments, the OS launches and initializes the app using the normal lifecycle events of an activity (e.g., in Android, using the app's OnCreate() method). In an alternative embodiment, the OS launches and initializes the app using an event dedicated to initializing the app due to preloading, such as OnCreateForPreload().

[0090] ■In some embodiments, the OS creates the preloaded activity in the background, i.e., the activity is not displayed to the user, and calls the app's initialization code using the activity's normal lifecycle callbacks, such as OnCreate(). Alternatively, the OS can create the preloaded activity in the background and call its initialization code using an event dedicated to initializing an activity due to preloading, such as OnCreateForPreload().

[0091] ■The OS simulates the activity transitioning to the foreground, but actually uses a "foreground simulation" mode, keeping the activity hidden from the user (the activity appears to be in the background). In some embodiments, but not necessarily, foreground simulation allows the activity to be fully rendered while in the background.

[0092] ■After a period of foreground simulation, the OS changes the state of the activity to a normal background activity.

[0093] In some cases, a user may enter a preloaded activity, for example by invoking an app (without being aware of the fact that the activity is preloaded). In this case, the activity should exit the preloaded state. User entry into a preloaded activity may include the following steps or a subset thereof:

[0094] ■ The OS marks the activity as a normal, non-preloaded activity (if currently marked otherwise).

[0095] ■ The OS verifies that the task holding the activity is not a non-preloaded task. This verification can be performed by reassigning the activity's previous task (the preloaded task) as a non-preloaded task, if applicable, or by moving the activity to a different, possibly new, non-preloaded task.

[0096] ■ The OS verifies that the now active non-preloaded task is associated with a non-preloaded task stack. In some embodiments, the OS removes the non-preloaded task from the preloaded task stack and re-parents the task to an existing or new non-preloaded task stack. In some embodiments, the OS simply marks the existing task stack holding the non-preloaded task as non-preloaded. This can be done explicitly or implicitly by re-parenting the existing task stack to the non-preloaded target display.

[0097] ■ In some embodiments, the OS verifies that the display holding the non-preloaded task stack is associated with the non-preloaded display. In some embodiments, this includes reparenting the task stack into the non-preloaded target display.

[0098] ■The OS makes the preloaded activity visible to the user and moves it to the regular foreground state.

[0099] ■The OS calls any relevant callback functions that may be associated with the activity or app exiting from the preloaded state.

[0100] Figure 4 is a state diagram schematically illustrating a preloading process according to an embodiment of the present invention. The state diagram may be used by OS 48, possibly with some variations, for preloading activities belonging to an app, or for preloading the app itself. The activities preloaded using this state diagram may be, for example, the launch activity of an app or an activity that is part of the content within an app. However, for simplicity and clarity, the following description primarily refers to the preloading of individual activities. Preloading of apps will be discussed in more detail below.

[0101] The preload operation begins with a preload trigger, i.e., an event that causes the OS 48 to decide to preload an activity. In response to the preload trigger, the preload agent 50 transitions the activity to the "foreground simulation" state 110. As described above, in this state, the app sees the activity as a foreground activity, while the OS sees the activity as a background activity. When the activity is in the foreground simulation state, the agent 50 starts the activity in the background and at least partially prerenders the activity.

[0102] At some stage, the agent 50 decides to end the foreground simulation. Several example completion criteria for ending the foreground simulation are discussed further below. Assuming no errors occurred during the foreground simulation, the preload agent 50 transitions the activity from the foreground simulation state 110 to the "preloaded background" state 114. If an error occurs during the foreground simulation, the preload agent 50 may terminate ("kill") the activity.

[0103] In the preloaded background state, both the OS and the app treat the activity as a background activity. In this state, the activity is static and waits in the background. In some embodiments, when the activity is in the preloaded background state 114, the preload agent 50 may decide to refresh the activity in the background. In this case, the agent 50 transitions the activity back to the foreground simulation state 110.

[0104] Upon user entry, for example, when the user launches the app by clicking on its icon, the agent 50 transitions the activity from the preloaded background state 114 to the "foreground" state 118. In this state, the activity is visible to the user. With the help of the preparation and pre-rendering operations performed in the foreground simulation state, the transition to the foreground state 118 is fast. As shown in the figure, in the case of user entry during foreground simulation, it is also possible to directly transition from the foreground simulation state 110 to the foreground state 118.

[0105] Figure 4 The state diagram in is an example state diagram, which is depicted only for the purpose of conceptual clarity. In alternative embodiments, OS 48 can use any other suitable configuration of states and transitions to perform the disclosed technology. Additional implementation details and possible variations are given below.

[0106] In some embodiments, in an Android implementation, upon entering the foreground simulation state 110, the agent 50 sets the activity to the "resume" state, marks the activity and its window as "visible", and marks the activity as "focus". However, from the user's perspective, the activity is rendered to the background and is therefore invisible to the user. Upon transitioning from the foreground simulation state 110 to the preloaded background state 114, the agent 50 changes the activity's "visible" and "focus" signals to indicate that the activity is not visible and not in focus, calls any related callbacks, and additionally changes the activity state to "paused" and / or "stopped".

[0107] In some embodiments, the agent 50 uses existing lifecycle events of the Android OS related to entering and exiting the foreground to transition the activity into and out of the foreground simulation state 110. These lifecycle events may include, for example, OnStart() and / or OnResume() for entering the foreground simulation, and OnPause() and / or OnStop() for exiting the foreground simulation. This implementation simplifies the integration of the app with the preload feature because the app can use its normal, non-preloaded, activity-related code flow.

[0108] In an alternative embodiment, the agent 50 uses new dedicated events to transition activities into and out of the foreground simulation state 110. These new lifecycle events are dedicated to preload operations and are different from the events used for normal activity processing. For example, such dedicated events may include OnSimulatedStart(), OnSimulatedResume(), OnSimuatedPause(), OnSimulatedStop(), etc.

[0109] In some embodiments, the OS 48 notifies the app of the fact that the activity is preloaded. For example, such notification may be performed using a suitable application programming interface (API) provided by the OS to the app. For example, an API of the form "boolean isPreloaded(Activity activity)" may be provided to the app, for example, via a software development kit (SDK). This method allows the app to check whether a certain activity is preloaded. When the activity parameter is omitted, the query / notification is interpreted as a general query / notification about whether the app itself is considered preloaded.

[0110] In some embodiments, when an app or activity is preloaded, the app does not perform certain actions that the app is willing to perform only when the user actually uses the app / activity. Such deferred actions can include, for example, running analysis code, obtaining and rendering certain content, obtaining and rendering content that is not immediately displayed to the user upon entry, and so on. In some embodiments, OS 48 (e.g., through an SDK) provides an API to the app that allows the app to register one or more callback functions to be used when the user enters after preloading. The OS calls these functions when the user enters the preloaded activity or preloaded app. This feature enables the app to complete any actions skipped during preloading, such as running relevant analysis code, refreshing a previously preloaded UI, starting video playback, etc.

[0111] As described above, the preload agent 50 can use various completion rules to decide to end the foreground simulation of a certain activity and transition to the preloaded background state 114. In one embodiment, the agent 50 continues the foreground simulation until the activity is fully rendered in the background, and only then transitions to the preloaded background state 114. In other embodiments, the foreground simulation phase is limited in time to not exceed a defined timeout duration. For example, the time limit can be implemented by using a programmatic timer and / or by using an API provided to the app (e.g., through an SDK).

[0112] In one embodiment, no API is used, and expiration of the timeout indicates successful completion of the preload. Upon successful completion, the agent 50 deems the preloaded activity suitable for future display and transitions from "foreground simulation" to "preload background." As described above, if the app indicates that an error occurred during preload, the agent 50 can terminate the preload process, for example by destroying the activity / app.

[0113] In another embodiment, in addition to the timeout mechanism, the OS 48 provides an API to the app that enables the app to indicate whether the preload was successful or failed. If the app indicates that the preload was successful, the OS stops the timer and transitions to a "preloaded background" as if the timer had expired. If the app indicates that the preload failed (e.g., due to network problems in obtaining the content to be rendered), the OS can terminate the preload process, for example, by destroying the activity / app being preloaded. In an embodiment, if the timeout expires before the app indicates a successful preload, the OS can treat the preload as a failure and can terminate the preload process, for example, by destroying the activity / app being preloaded.

[0114] To ensure that the OS 48 does not display an activity whose preload failed, and therefore ensure that the preloaded content displayed to the user is intact, it is important to consider the above failure scenarios. For example, if a network error occurs while preloading an app, the failure scenario avoids displaying the error to the user later, when the error condition may no longer be valid.

[0115] Background preloading of activities using foreground lifecycle events

[0116] Figure 5A and Figure 5B 1 is a state diagram schematically illustrating the life cycle states (also referred to as life cycle events) of a foreground loaded activity and a background preloaded activity according to an embodiment of the present invention. Figure 5A and Figure 5B Explains how background preloading of activities can be implemented using existing OS lifecycle events / states designed for traditional foreground handling of activities.

[0117] like Figure 5A As shown in the figure, the life cycle of the foreground activity begins when the activity is started. The activity then passes through the onCreate(), onStart(), and onResume() states, which end as the activity runs.

[0118] If another activity enters the foreground, the original activity transitions to the onPause() state. After a certain amount of time, when the activity becomes no longer visible, it proceeds to the onStop() state. If the activity is finished executing or is destroyed by the OS, the activity passes to the onDestroy() state and is then closed.

[0119] While in the onPause() state, if the user returns to the original activity, the activity returns to the onResume() state and continues running. Also in the onPause() state, the OS may kill the app process of the activity if an app with a higher priority competes for memory resources. Later, if the user navigates to the activity, the activity will start from the onCreate() state.

[0120] While in the onStop() state, if the user navigates to the activity, the activity passes to the onRestart() state and then to the onStart() state. Also in the onStop() state, the OS may kill the app process of the activity if an app with a higher priority competes for memory resources. Later, if the user navigates to the activity, the activity will start from the onCreate() state.

[0121] Figure 5B The following diagram shows the process of performing a preloading activity according to an embodiment of the present invention. Figure 5A In this example, the life cycle of the preloaded activity begins with a preload trigger. In response to the preload trigger, the preload agent 50 transitions the activity to the foreground simulation state 110 (as in the above example). Figure 4 In this example, the onCreate(), onStart(), and onResume() states are used to implement the flow of the foreground simulation process. Figure 5A The OS 48 keeps the activity in the background relative to the preloaded activity in the foreground, for example by overlaying a system call to display the activity on the display screen 56 of the user device 24.

[0122] The transition condition from the "activity running" to the onPause() state is in the foreground activity ( Figure 5A ) and preloaded activities ( Figure 5B ). For preloaded activities, the agent 50 transitions the activity to the onPause() state when the foreground simulation is successfully completed. If the foreground simulation fails, for example due to a network problem, the OS may destroy the app process of the activity as described above in addition to completing the preloaded activity.

[0123] From the onPause() state, the preloaded activity proceeds to the preloaded background state 114, which in this example is implemented using the onStop() lifecycle state.

[0124] While in the onStop() state, if the OS (usually the agent 50) decides to refresh the activity, the activity passes to the onRestart() state and then to the onStart() state. If the activity has been killed by the OS, the OS may later decide to preload the activity again. In this case, the activity passes back to the onCreate() state.

[0125] For the sake of clarity, Figure 5B Transitions triggered by user navigation to an activity are not shown. Such triggers cause the activity to pass to foreground mode, rather than foreground simulation. For example, user navigation to an activity while in the onStop() state causes the activity to pass to the onRestart() state, but in foreground mode; user navigation to an activity while in the onPause() state causes the activity to pass to the onResume() state, but in foreground mode; and user navigation to an activity after the activity is in the killed state causes the activity to pass to the onCreate() state, but in foreground mode.

[0126] The life cycle states / events and transition conditions described above are described by way of example only. In alternative embodiments, any other suitable arrangement of life cycle events / states may be used. Other aspects of using OS life cycle events to implement preloading are discussed in the U.S. Provisional Patent Application 63 / 128,220 cited above.

[0127] Preload user applications

[0128] The description so far has primarily involved preloading of individual activities. In some embodiments, the preload agent 50 of the OS 48 uses the disclosed techniques to preload the user app 26 as a whole before the user requests to activate the app. Preloading an app (referred to herein as "AppPreload") typically includes preloading a selected subset of the app's activities, thereby significantly reducing app launch delays.

[0129] In some embodiments, in preloading an app, the agent 50 follows and simulates the normal app launch sequence by preloading the app's entry point activity (sometimes called a launcher activity or splash screen). The agent 50 may then optionally preload one or more additional activities that the app would normally launch as part of its normal launch sequence. The agent 50 typically preloads each selected activity, entry point, or other content using the techniques described above, such as using foreground simulation.

[0130] In some embodiments, if the app calls an activity while the app is being preloaded, the agent 50 verifies that the call was preload-initiated, not user-initiated. If so, the agent 50 preloads the activity. In some embodiments, if such an activity typically requires a new task, the agent 50 creates a new preloaded task for the activity and associates the activity with the new preloaded task. Additional aspects related to distinguishing between preload-initiated or user-initiated activities are discussed in PCT International Publication WO 2019 / 171237 referenced above.

[0131] In some embodiments, the agent 50 places the various activities preloaded during the boot sequence in the same preloaded task. In some embodiments, the agent 50 creates preloaded tasks according to the normal boot sequence of the app, where for each task that would be created normally, the agent 50 creates a matching preloaded task. In some embodiments, each preloaded app is assigned a separate preloaded task stack that contains the various preloaded tasks and preloaded activities of the app. In some embodiments, each preloaded app is assigned a separate preloaded virtual display that contains the app's preloaded task stack.

[0132] In some embodiments, when a user enters a preloaded app, the agent 50 ensures that the app will be displayed in its initial state. In some embodiments, when preparing to preload an app, the agent 50 checks whether the app already has one or more living activities. If so, the agent 50 kills the app's living activities and tasks before starting preloading. For example, the agent 50 can destroy the app process that holds the living activities and tasks. In some embodiments, when preloading an app, if the app already has one or more living processes, the agent 50 destroys and / or completes them before starting preloading.

[0133] In some embodiments, the agent 50 preloads the app only in response to verifying that the app is not currently in the foreground.

[0134] In some embodiments, the agent 50 will only preload an app in response to verifying that the app does not have any live processes. In some embodiments, the agent 50 will only preload an app in response to verifying that all processes that would normally start during normal app startup are not active. In some embodiments, the agent 50 will only preload an app in response to verifying that certain specific processes are not active. The selection of such specific processes may depend on a defined configuration.

[0135] In some embodiments, the agent 50 will only preload an app in response to verifying that the app does not have a process with any live app components of one or more specified types. Such types may include, for example, activities, broadcast receivers, services, content providers, widgets, notifications, or any other suitable type of app components.

[0136] In some embodiments, the agent 50 will only preload an app in response to verifying that the app does not have any active activities. In some embodiments, the agent 50 will only preload an app in response to verifying that the app does not have a specific active activity (referred to herein as a target activity). The target activity can be configured for each app, for example, via an API. In some embodiments, an app configures exactly one target activity (referred to as its "primary activity"), which is typically preloaded during the app's preload period.

[0137] In other embodiments, the agent 50 may preload an app even if the app has an active component only if the app is considered "not recently used" (NRU). For example, if the time elapsed since the user last used the app exceeds a defined value, the app will be considered NRU.

[0138] Typically, as described above, the Recents screen of OS 48 is not affected by the preloading of apps. Thus, when the Recents screen requests a task that is replaced with a preloaded task, OS 48 provides the latest task to the Recents screen rather than attempting to bring the previous task to the foreground (which may fail because the previous task no longer exists) or creating a new task. In some embodiments, this feature is implemented by maintaining a mapping between the latest task saved by the Recents screen and the latest preloaded task per app per user (e.g., per app package). In other embodiments, this feature is implemented by maintaining a mapping between {app package, user} and the latest preloaded task for {app package, user}.

[0139] In some embodiments, the app usage metrics maintained by OS 48 are not affected by the preloading of apps. In this context, the app usage metrics may include, for example, a last use timestamp for each app or app package, a process priority order typically based on the time of most recent use (e.g., least recently used order), previously used processes, etc.

[0140] In some embodiments, the agent 50 preloads the app based on the least recently used usage metric. In some embodiments, the agent 50 preloads the app after the user exits from the app. In some embodiments, the agent 50 preloads the app after the user exits from the app in case such exit kills one or more activities of the app. For example, such a scenario may occur due to the app being swiped-off from the recents screen or exited by using the back button.

[0141] In some embodiments, preloading apps does not affect OS 48's decisions about initiating a power saving state, such as whether and when to initiate App Standby. Thus, for example, preloading of apps is not considered app usage for the purpose of power saving decisions.

[0142] In some embodiments, during preloading of an app, OS 48 temporarily turns off the power saving state, for example, to allow the app to download and / or render content.

[0143] In some embodiments, when preloading of the app is complete, the app and all of its activities are moved to a normal background state, such as a paused or stopped state.

[0144] In some embodiments, the preload agent 50 sets an upper limit on the total duration of preloading apps. This upper limit can be set instead of or in addition to the time limit for preloading each individual activity (in Figure 4For example, the time limit can be implemented using a programmatic timer and / or using an API provided to the app (e.g., via an SDK), similar to the timeout implementation associated with individual activities. In an example embodiment, the API can allow the app to declare that the preloading of the app was successfully completed, rather than the successful preloading of an individual activity.

[0145] In some embodiments, when a user enters a preloaded app, OS 48 presents some preliminary UI animation and / or startup window before displaying the preloaded activity or activities. In one embodiment, the animation and / or startup window is the same as the animation and / or startup window that would be displayed if the app was not preloaded. In another embodiment, when the app is preloaded, the OS presents a certain animation and / or startup window, and when the app is not preloaded, the OS presents a different animation and / or startup window. In the latter case, the OS can use an animation and / or startup window that is specifically designed for the situation where the user enters after preloading, for example, as an indication to the user that the app being entered is preloaded.

[0146] In some embodiments, preloading of apps supports a multi-user environment in user device 24. For example, in some embodiments, OS 48 ensures that preloaded tasks for one user cannot be accessed or otherwise used by another user. In some embodiments, OS maintains different preloading policies for each user.

[0147] In some embodiments, OS 48 gives preloading a lower processing priority than UI foreground-related jobs. In some embodiments, the processing resources allocated to preloading are limited to a small portion of the available processing resources after prioritizing UI foreground-related jobs. In some embodiments, preloading is performed under Android's background Cgroup.

[0148] In some embodiments, OS 48 provides a testing tool for app developers to simulate the preloading of apps. In some embodiments where the preloading of apps can be performed in multiple modes, for example, as described in the above-mentioned PCT application PCT / IB2020 / 057046, the simulation of preloading supports all possible modes.

[0149] In some embodiments, app preloading is used to speed up the launch time of apps (such as games) where a lot of processing work occurs when the app starts.

[0150] In some embodiments, app preloading is performed in such a way that the processing performed during preloading remains relevant to the user for a considerable duration. For example, preloading can exclude content items that change rapidly, for example, at a rate exceeding a predefined rate. An example is to preload at least a portion of a landing page for an app (e.g., a game) that rarely changes over time. This allows the OS to preload such an app (e.g., a game) only occasionally and possibly at a preferred time period (e.g., when the user device is connected to a power source), and still maintain a high probability that the preloaded app will be used by the user as is, without the need to refresh the preloaded content (e.g., when the user enters).

[0151] In some embodiments, app preloading is used to speed up the launch time of apps (such as games) that require specific device resources (e.g., GPU resources). In some embodiments, preloading of such apps is performed when device resources are available / abundant.

[0152] In some embodiments, app preloading excludes fetching content over the network. In some embodiments, during preloading, the OS prohibits access to the network. In some embodiments, app preloading is limited to rendering content that is already present on the user device (e.g., in flash memory), e.g., embedded in the app itself or residing in a temporary cache (e.g., a cache of items previously fetched over the network, such as Figure 1 The contents of cache 52).

[0153] In some embodiments, at least some of the app preloading functionality is integrated into an app development framework or a third-party SDK, such as a game framework (also known as a game engine) or an analytics SDK. Such an app development framework is referred to herein as an App Preloading Integration Framework. In some embodiments, such integration is achieved by providing suitable plug-ins for such a framework or SDK. In some embodiments, the App Preloading Integration Framework is used to replace some or all of the app preloading API integration steps (which are otherwise required by the app in order to utilize or better utilize app preloading). In some embodiments, the use of the App Preloading Integration Framework reduces or simplifies the integration efforts of the app with the app preloading API. In some embodiments, the app preloading API is given to the app as part of the integration framework.

[0154] In some embodiments, when deciding whether to preload an app, OS 48 considers the type of app to be preloaded, for example, whether the app is a game. In some embodiments, when deciding whether to preload an app, OS 48 may consider the type of one or more frameworks used by the app and whether it is an App preload integration framework.

[0155] Preload app content

[0156] In some embodiments, the preload agent 50 of the OS 48 uses the disclosed activity preloading techniques, such as those related to foreground simulation, to preload content within an app (e.g., in-app activities). Preloading of content within an app is referred to herein as "InAppPreload". In this context, the term "in-app activities" refers to activities that are not immediately displayed to the user when the app is launched, but may be displayed later based on events such as user interaction with the app.

[0157] Note that preloading of activities within an app can be performed for both apps that remain in the background (e.g., preloaded apps) and apps that are running in the foreground (e.g., apps that are launched and currently being used by the user). In some embodiments, preloading of activities within an app is performed while the app is in the background, after the app itself has been preloaded. In either case, preloading of activities within an app allows for significant reductions in latency experienced by the user. Latency is reduced because the activity is at least partially ready in memory when the app needs to display the activity, such as in response to a user clicking a link within the app.

[0158] In some embodiments, the agent 50 in the OS 48 maintains a cache of activities within the preloaded app. The cache is typically implemented in the user device RAM. Each activity preloaded by the OS is saved to the cache. Activities that can be preloaded or the intent to create such activities are assigned corresponding unique and stable identifiers (IDs) by the OS, which are used as their cache keys. Typically, although not required, the app initially assigns an ID by calculating the ID when the intent is to create an activity. When the app requests to start an activity within the app, the agent 50 calculates the unique ID of the activity and compares it with the unique ID of the activity cached in the app. If a match is found, the OS 48 displays the cached activity instead of creating a new activity. If no match is found, the OS 48 creates the activity in the manner in which the activity is usually created without preloading.

[0159] In some embodiments, the app uses an API provided by the OS (eg, through an SDK) to map an activity or an intent to create an activity to a unique and stable ID.

[0160] In some embodiments, the agent 50 assigns an expiration timestamp to each activity in the activity cache within the app. In such an embodiment, the OS 48 provides the preloaded activity from the cache (rather than creating a new activity) only when the expiration time of the cached activity has not yet expired. In some embodiments, when the activity expires, the activity is destroyed. The agent 50 typically assigns an expiration timestamp when preloading an activity, and sets the expiration time to the preload time plus a certain time to live (TTL) duration. In some embodiments, the TTL is fixed on all activities within the app and on all apps. In some embodiments, the TTL is fixed on all activities of the same app. In some embodiments, the TTL is set dynamically. In some embodiments, the TTL is set dynamically based on a configuration set by the app (e.g., via an API).

[0161] In some embodiments, the number of activities maintained in the activity cache within the app is limited. In some embodiments, the agent 50 limits the total number of activities that can reside in memory for a given app, including preloaded activities and non-preloaded activities, which are activities that are regularly launched by the app. In some embodiments, the limit on the number of cached activities is fixed. In other embodiments, the limit is set dynamically and can depend on the current state of the user device (e.g., depending on available resources), hardware type (e.g., total RAM and / or CPU power), app type, app usage frequency, app usage patterns, or any other suitable factor.

[0162] In some embodiments, the agent 50 assigns each preloaded within-app activity its own separate preload task 96. In other embodiments, the agent 50 groups (e.g., stacks) the preloaded within-app activities in multiple preload tasks 96. In still other embodiments, the agent 50 groups (e.g., stacks) all preloaded activities in a single preload task 96. In some embodiments, each preloaded task 96 resides in its own preloaded task stack 100. In some embodiments, all preloaded tasks 96 reside in the same preloaded task stack 100. In yet other embodiments, all preloaded tasks for the same app reside in the same preloaded task stack. In some embodiments, the preloaded task stack for activities within an app resides within a preloaded virtual display 108, as will be explained in detail below.

[0163] In some embodiments, the preload agent 50 selects activities within the app to be preloaded based on the suggestion and ranking (prioritization) of potential target activities to be preloaded. In some embodiments, the OS 48 provides the app with an API for suggesting and ranking potential target activities to be preloaded. In some embodiments, the app can call the API at various points in time when the app is running to adjust the suggested and ranked potential target activities, for example, based on content items currently reachable and / or visible to the user, such as based on the temporal state of the app.

[0164] In some embodiments, when an app with preloaded in-app activities is moved from the foreground to the background by the OS, the preloaded in-app activities are maintained for a defined duration while the app is in the foreground. This feature allows for rational use of RAM while still allowing the user to switch to a different app and back without losing the preloaded activities. In some embodiments, the defined duration is fixed across all activities and all apps. In other embodiments, the defined duration is fixed across all activities of the same app. In yet other embodiments, the defined duration is set dynamically. In some embodiments, the defined duration is set dynamically based on a configuration set by the app, for example, through an API.

[0165] In some embodiments, the agent 50 preloads activities within the app one by one, i.e., not concurrently. In some embodiments, the agent 50 preloads activities within the app concurrently and may maintain a concurrency limit. The limit defines the number of concurrent preloads that the OS will perform at any given point. The OS can set this limit to a fixed size or dynamically set the limit based on current conditions. Setting a higher concurrency limit may help activity cache hit rates and may also reduce battery consumption due to bundling of preloaded actions. On the other hand, a higher concurrency limit may consume more device resources, such as CPU and GPU processing. Therefore, the concurrency limit (dynamic or static) setting may depend on factors such as the current device state (e.g., available resources), hardware type (e.g., total RAM, CPU type), app input (e.g., expected processing required or allocated for preloading), and / or whether the app is running in foreground mode or background mode.

[0166] In some embodiments, when a user enters an activity within a preloaded app, OS 48 displays a preliminary UI animation before displaying the preloaded activity. Such a UI animation can be the same animation that would be displayed if the user enters a non-preloaded activity, or a different animation (e.g., an animation specifically dedicated to the situation where the user enters after preloading). The dedicated animation can include, for example, an indication to the user that he or she is entering a preloaded activity.

[0167] In some embodiments, the activity preloading functionality within the app is integrated into an app development framework or a third-party SDK, such as a game framework (also known as a game engine) or an analytics SDK. Such an app development framework is referred to herein as an InAppPreload integration framework. In some embodiments, such integration is achieved by providing an InAppPreload plugin for such a framework or SDK. In some embodiments, the InAppPreload integration framework is used to replace some or all of the InAppPreload API integration steps (which are otherwise required by the app in order to utilize or better utilize InAppPreload). Using the InAppPreload integration framework reduces or simplifies the integration work of the app with the InAppPreload API. In some embodiments, the InAppPreload API is given to the app as part of the integration framework.

[0168] In some embodiments, when deciding whether to preload an in-app activity, the agent 50 considers the resources required to preload the activity. Such resources may include, for example, power consumption, use of cellular data, memory, CPU resources, GPU resources, or any other relevant resources. In some embodiments, the agent 50 learns this information over time, for example, by measuring the resources consumed during preloading. In some embodiments, the app at least partially declares its requirements for at least a portion of such device resources (e.g., through an API).

[0169] In some embodiments, OS 48 provides tools for app developers to simulate preloading of activities within an app.

[0170] Additional Embodiments and Modifications

[0171] Using Virtual Display for Preloading

[0172] Above about Figure 3 The concept of preloading a virtual display 108 is described. In various embodiments, the preload agent 50 of the OS 48 may use the preloaded virtual display 108 to preload activities in various ways.

[0173] In some embodiments, when an app or activity is preloaded, the preload agent 50 creates the app or activity within the preloaded virtual display 108. Before displaying it to the user, for example, in response to the user entering the app, the agent 50 transfers the app or activity to the regular display and displays it there. The regular display to which the preloaded content is transferred is referred to herein as the "target display."

[0174] In some embodiments, OS 48 maintains only one regular display (e.g., Figure 3 4), which serves as the target display for all preloaded apps and activities. In other embodiments, OS 48 maintains multiple regular displays. In such embodiments, agent 50 typically determines the target display based on the semantics of the user request. For example, an app or activity can be transferred to a regular display in which the app or activity is typically already launched without being preloaded. In some embodiments, when a user requests to view the content of an app, for example, when a user clicks on an app's icon, the app or activity is transferred from the preloaded virtual display to the regular display.

[0175] When using foreground simulation as described above, when foreground simulation is complete, agent 50 can transfer the app or activity from preloaded virtual display 108 to a regular display (e.g., default display 104). In the regular display, agent 50 places the app or activity in a background state, ready for later use by the user.

[0176] In some embodiments, OS 48 maintains a single preloaded virtual display 108 for all preloaded operations. In such embodiments, agent 50 limits preload operations (e.g., the duration of foreground simulation, or the entire duration of an app in a preloaded state) to one preload operation at a time to avoid cross-effects between different preloaded apps. A single preloaded virtual display 108 can be created as part of system initialization, or on demand when a preload operation is first requested.

[0177] In an alternative embodiment, OS 48 creates and maintains multiple preloaded virtual displays 108 for, for example, each preloaded task stack 100, each preloaded app, each preloaded task 96, or each preloaded activity 92. In an exemplary embodiment, agent 5 can create a preloaded virtual display 108 even for one preload operation, and destroy the preloaded virtual display after the preloaded content is transferred to the regular display. Multiple preloaded virtual displays can exist in parallel, each for a different preload operation. This fine granularity helps to avoid the cross-effect of the preload operation on other tasks, task stacks, apps, or activities that are preloaded or otherwise. As an alternative to destroying the preloaded virtual display 108, the preloaded virtual display can be cached in memory by agent 50 for later use by different preloaded operations.

[0178] In some embodiments, the agent 50 may maintain a pool of preloaded virtual displays 108 that are created with different attributes and / or states. In such an embodiment, the agent 50 performs each preload operation in a preloaded virtual display that matches its desired target attributes and state. For example, the agent 50 may maintain two preloaded virtual displays 108 - one for landscape orientation and the other for portrait orientation. Apps that implement landscape orientation will be preloaded in the former, while apps that can use any orientation and are expected to be used in portrait orientation will be preloaded in the latter. When using a pool of preloaded virtual displays, it is possible to allow several preload operations to be performed simultaneously within the same preloaded virtual display because the operations share the same target attributes and states.

[0179] As another example, when the OS uses several possible regular displays in which the user can launch apps, each display having its own different attributes, the agent 50 can create corresponding preloaded virtual displays that match each regular display in each of its expected states. The latter embodiment is useful, for example, in situations where virtual displays are limited or resource expensive, such as due to construction or maintenance costs.

[0180] As described above, the preloaded virtual display 108 is designed to be a temporary placeholder for content that is later transferred to a regular display. Therefore, a given preloaded virtual display should resemble the corresponding regular display (target display) as closely as possible. To this end, the agent 50 typically sets the preloaded virtual display to emulate some or all of the properties of the target regular display, such as its height and width.

[0181] When the properties of the preloaded virtual display are set to emulate a regular display, the agent 50 should specify which regular display to emulate. As defined above, the emulated regular display is typically selected as the target display to which the desired app is transferred. However, in practice, in many cases, there is only one such target display associated with the display screen 56 of the user device (e.g., Figure 3 In these embodiments, any pre-loaded virtual display 108 typically emulates the properties of the default physical display 9, and therefore the properties of the display screen 56.

[0182] In some embodiments, the target display includes certain system decorations - UI elements, such as a status bar or navigation components. These decorations take up some of the display area available to the app. The preloaded virtual display should typically mirror these components to ensure that the preloaded app is rendered in the same area as the area available in the target display. Therefore, in some embodiments, the agent 50 creates decorations in the preloaded virtual display in a manner similar to the way decorations are created for the corresponding target display. In some embodiments, the agent 50 does not actually create decorations within the preloaded virtual display, but calculates and retains the size of the decorations, thereby reducing the area available in the preloaded virtual display accordingly.

[0183] In some OS and user devices, orientation is a state variable for the display. Therefore, encapsulating the preloading operation into a preloaded virtual display allows the OS to preload apps with different orientations without affecting the regular display, and in particular without changing the orientation of the display with which the user is interacting. In some embodiments, the agent 50 determines the orientation of a preloaded virtual display in a manner similar to a physical display by negotiating with the app requirements. For example, for an app that requires a landscape orientation, the negotiation causes the agent 50 to change the orientation of the preloaded virtual display to landscape, while the default display can remain portrait. In other embodiments, the orientation of each preloaded virtual display is fixed.

[0184] For apps that can be used in one of several different orientations, agent 50 may determine a target orientation based on, for example, the orientation in which the preloaded content is expected to be used. Agent 50 may then set that orientation as the orientation of the preloaded virtual display, possibly taking into account the app's usage history, the current state of the physical device, and / or other suitable factors.

[0185] Preloading by using intent

[0186] In some embodiments, OS 48 supports the use of "intents" and "intent resolution". The term "intent" refers to an advance indication of an operation to be performed. Among various operations, an operation may be the start of an activity. The term "intent resolution" refers to the function of OS 48 to process an intent, resolve the intent into a desired operation, and optionally perform the desired operation.

[0187] In some embodiments, preloading of activities is performed as part of intent resolution by the OS 48. In these embodiments, the intent to open an activity may be marked as a preload intent, in which case the operation to be performed is the preload of the activity, rather than the regular, non-preloaded launch of the activity. In such embodiments, the intent resolution function of the OS may receive both regular intents and preload intents. In some embodiments, non-preload intents may include intents to launch an activity in response to a user's entry into an existing activity, which may or may not be preloaded. In some embodiments, if a non-preload intent is received for an already preloaded activity, the intent resolution function detects this fact and, for example, as described above, triggers the desired action when the activity / app exits from a preloaded state.

[0188] In some embodiments, during intent resolution of a preload intent, OS 48 resolves the target activity to be preloaded, decides whether to preload it, and acts accordingly. In some embodiments, at least a portion of processing the preload intent is performed under system lock, so that the decision to preload and the actual preload are performed in an atomic manner, avoiding potential race conditions with system state.

[0189] In some embodiments, creation of the preload intent is performed in a previous stage based on several inputs such as system events (e.g., swiping away the app from the recents screen, exiting the app using the back button, receiving a push notification, etc.).

[0190] In some embodiments, the decision to create a preload intent and / or actually preload according to the intent depends on a preload policy maintained by the OS. In some embodiments, the OS 48 maintains the preload policy by using a system app. For example, the preload policy can be created by a system app and / or persisted in the data portion of the system app.

[0191] In some embodiments, the preloading policy is defined at least in part by considering configuration settings set by the user app, for example, through a provided API. Such configuration can be set by the app at any point, for example, when the app is initialized. In some embodiments, the preloading policy is defined at least in part by considering configuration settings set by an internal algorithm of the device (for example, through the agent 50) and / or by a server-side algorithm (for example, through Figure 1 The preloading strategy is defined by additional configuration settings set by the preloading control unit 72. Such algorithms may include, for example, usage pattern analysis algorithms, artificial intelligence, machine learning algorithms, etc.

[0192] Preload according to the preload policy received from the network side server

[0193] In some embodiments, the OS 48 receives a preload policy from the preload control unit 72, and the preload agent 50 performs various preload operations according to the policy. As described above, the OS can manage the preload policy using a system app. The OS 48 can obtain updates to the preload policy from time to time, such as over the air, from the preload control unit 72. In various embodiments, the preload policy can specify the following definitions and parameters, such as:

[0194] ■Specifications for which apps to preload and when.

[0195] ■Specifications on whether to preload and which apps’ content to preload.

[0196] ■ Specifications for how much of the app’s components to preload (e.g., only executing a certain initial executable code, or prerendering the app’s user interface, and / or a maximum duration for foreground emulation).

[0197] ■ Specifications for the use of preloading modes, e.g., offline preloading and / or online preloading, e.g., as described in the PCT application PCT / IB2020 / 057046 cited above.

[0198] ■ "Whitelist" of apps - a defined list of apps. In some embodiments, OS 48 only allows preloading of apps that appear on the whitelist. In other embodiments, OS 48 allows preloading of apps that appear on the whitelist except for apps that have integrated and call specific APIs provided to the app, such as preload initialization APIs, for example, via SDK.

[0199] ■Specification of maximum duration of foreground emulation for all apps and / or specific to certain apps.

[0200] Additional aspects of managing preloading operations using a network-side server are discussed, for example, in the above-referenced US Provisional Patent Application 63 / 118,068.

[0201] Preload in expected device orientation

[0202] In some embodiments, when preloading an activity, OS 48 defines a target device orientation (e.g., portrait or landscape) for activity preloading, which may be different from the current orientation of the user device 24. Thus, the preloaded activity is prerendered as if the user device is in the target orientation, while other device functionality continues to work normally in the actual orientation. This feature allows preloading to be fully utilized, even in the face of orientation changes. For example, a user may be watching a video in landscape orientation, and then be predicted to open a social app in portrait orientation after the video is completed. In this case, OS 48 can preload the predicted social app in portrait orientation. In some embodiments, the OS selects the target orientation based on the app's usage pattern, the target activity, and / or the orientations supported by the preloaded app.

[0203] In some embodiments, the OS may maintain preloaded activities in more than one orientation simultaneously and display the activities in an orientation that matches the orientation of the user device when entered by the user.

[0204] In some embodiments, if the orientation of the preloaded activity does not match the orientation of the user device when the user enters, the OS 48 destroys the preloaded activity. In other embodiments, the OS re-renders the preloaded activity upon entry to match the current orientation.

[0205] In some embodiments, the OS 48 may respond to changes in the orientation of the user device by potentially destroying preloaded activities that had a different orientation, or re-rendering such activities to match the current orientation.

[0206] Preload in multiple windows

[0207] In some embodiments, OS 48 allows preloading of activities during multi-window mode (also known as "split screen" mode) (even for activities of apps that do not support multi-window). Typically, when an activity of an app that does not support multi-window needs to be launched (for example, due to user entry), the OS checks whether the user device is currently in multi-window mode. If so, the OS may display an error message or exit multi-window mode. In some embodiments of the present invention, OS 48 can ignore this check when preloading an activity and allow the activity to be launched in the background, just as in full screen, while keeping the user device in multi-window mode.

[0208] In addition, in some embodiments, OS 48 takes full advantage of preloaded activities for immediate display, even in multi-window, regardless of whether these activities have been preloaded during multi-window. In some embodiments, this feature is implemented by saving all preloaded tasks in at least one preloaded task stack, and reparenting the preloaded tasks to the system's multi-window task stack when the OS needs to display the preloaded activities.

[0209] Rich content for preloaded activities

[0210] In some embodiments, the content fetched by the app to be rendered on the preloaded activity can be of higher quality (e.g., higher definition images / video; 3D images instead of 2D images, etc.) than the normal content fetched during real-time activity loading (i.e., when the activity is created due to user request rather than due to preloading by the OS). In some embodiments, this enrichment of content is achieved by having the app request the higher quality content when preloading the activity.

[0211] In an embodiment, to determine the content quality, the app may check whether its activity is preloaded by using an API, such as the isPreloaded() method mentioned above.

[0212] In some embodiments, normally applied content reduction algorithms are skipped during preloading. For example, when retrieving content for preloading, image quality reduction algorithms applied on the server side, for example by a content delivery network (CDN), are skipped. In some embodiments, when the app performs the retrieval of content, the skipping of content quality reduction on the server side is overridden due to the app's explicit request. In some embodiments, the preloaded app can indicate to the server that it has a good quality network connection, regardless of the actual network connection, in order to allow higher quality content during preloading. In some embodiments, the preloaded app can indicate to the server that it is retrieving content during preloading to allow the server to decide the desired content quality during preloading.

[0213] Masking Unexpected Interactions When Preloading Activities

[0214] In some embodiments, when an activity is preloaded, and possibly also when the activity is in the background state due to preloading, OS 48 masks (hides) undesirable interactions that could make the user aware of the preloaded activity. In some embodiments, masking of such interactions includes masking pop-up messages such as light-weight toasts (in Android) and error messages.

[0215] Preload activity when user enters

[0216] In some embodiments, if the user enters an app / activity that is currently being preloaded, the OS 48 stops preloading and recreates the app / activity as if it had not been preloaded (e.g., from scratch). In an alternative embodiment, the OS completes the preloading process and simultaneously displays the predefined screens to the user. After preloading is complete, the OS removes the predefined screens and displays the preloaded activity as if the user entered the preloaded activity. Further, alternatively, the OS may perform all actions required when a user enters a preloaded activity (as previously defined), making the preloaded activity visible to the user, and the loading of the activity continues while in the foreground.

[0217] Avoid preloading when the CPU is busy

[0218] In some embodiments, preloading is avoided when the user device CPU is too busy, for example, based on a predefined or dynamically set condition. This feature can help increase the likelihood that preloading will be completed in a timely manner, and thus can help not waste resources such as power and data (e.g., due to automatic failure timer limitations as described above).

[0219] Preloading for battery-sensitive situations

[0220] In some embodiments, in power consumption sensitive situations, preloading is assigned a low priority by the OS, or even preloading is avoided entirely. Such situations may include, for example, when the user device battery is too low (e.g., the remaining energy is below a preconfigured threshold), when the user device enters a power saving state controlled by the OS (e.g., Android hibernation state), when the user device enters a power saving state controlled by the user (e.g., Android battery saver state), or when a specific app enters an app-specific node state (e.g., Android App standby state).

[0221] In contrast, in some embodiments, OS 48 triggers preloading more freely (eg, more frequently) in situations where power issues are less severe than in the past, such as when the user device is connected to an external power source.

[0222] Preloading as a power saving / battery saving tool

[0223] In some embodiments, the disclosed preloading techniques are used as a measure to save power and / or battery resources. Such savings can be achieved by using any of the following example schemes:

[0224] ■Use preloading to save wasted screen time: In this scheme, preloading is used to reduce the power consumed by the user device screen while the user is waiting for content to load. In an example embodiment, the OS gives appropriate preference to preloading based on how much power is consumed by the screen or content presented during the waiting time at normal (non-preloaded) startup.

[0225] ■Use preloading to save power consumed by poor network conditions: In this scheme, preloading is used to reduce the power consumed by the device networking hardware (such as a cellular modem). In some embodiments, the OS gives preference to preloading when the expected power consumption due to networking during preloading is less than a certain threshold. For example, preloading may be preferred when 4G or 5G coverage is good and / or when connected to Wi-Fi. In some embodiments, preloading is preferred when the preloading strategy estimates that there is a high enough probability that the user will use the preloaded app in network conditions that are worse than the existing network conditions by a given threshold. For example, the OS may decide to preload the app when the preloading strategy estimates that there is a high enough probability that the app will be used in 3G coverage and the current situation has good Wi-Fi.

[0226] ■Use preloading to save power consumed by the continuity of app use: In this scheme, the OS performs preloading concurrently (e.g., preloading multiple apps / activities at the same time) to reduce the power wasted by running normal apps in a serial manner. This bundling of preloading operations increases the power efficiency of device hardware such as cellular modems, Wi-Fi communication hardware, CPUs, and GPUs.

[0227] ■Use preloading to save power consumption due to app usage when the device is not connected to an external power source: In this scheme, the OS 48 gives preference to preloading when the user device is connected to an external power source and / or when the preloading policy estimates that the probability that the app will be used when the device is not connected to an external power source is high enough.

[0228] As a preload of tools that allow for an improved offline experience

[0229] In some embodiments, the disclosed preloading techniques are used to provide an improved offline experience to the user. The term "offline experience" refers to a situation where a user enters or attempts to use an app while the user's device is offline (i.e., unable to connect to the appropriate portal 28 via a network, e.g., due to being disconnected from the Internet). For example, the improved offline experience may refer to the following advantages that may be provided during the offline experience:

[0230] ■ Allow the app to display content instead of showing no display at all.

[0231] ■ Allow the app to display newer content than it would display without preloading.

[0232] ■Allow apps to display content that is new to the user, i.e. content that the user has not consumed before.

[0233] In some embodiments, OS 48 gives preference to preloading if the preloading policy estimates that the likelihood that the user will use the preloaded app while the user device is offline is high enough.

[0234] Preload as a tool to save cellular data

[0235] In some embodiments, the disclosed preloading techniques are used as a measure to save cellular data consumption. For example, such savings can be achieved by preferring preloading when the user device is connected to Wi-Fi. In some embodiments, preloading is primarily or exclusively performed when connected to Wi-Fi, and preloading can be prohibited in other situations. In some embodiments, when the device is connected to Wi-Fi, preloading is preferred if the preloading policy estimates that the user will use the preloaded app when not connected to Wi-Fi is sufficiently likely.

[0236] Preload in cellular data sensitive situations

[0237] In some embodiments, in situations where cellular data consumption is particularly sensitive, OS 48 gives low preference to preloading, or even avoids preloading. Such situations may include, for example, scenarios where the user device is roaming; scenarios where the user device enters a cellular data saving state controlled by the OS (e.g., Android sleep state); scenarios where the user device enters a cellular data saving state controlled by the user (e.g., Android data saver state); or scenarios where a specific app enters an app-specific cellular data saving state (e.g., Android App standby state).

[0238] Define the cellular data budget for preloading

[0239] In some embodiments, OS 48 measures the cellular data consumed by the preloading operation. In some embodiments, the measured cellular data consumed by the preloading includes data consumed by the app during its activity in the simulated foreground state. In other embodiments, the measured data includes data consumed by the app during its activity with any preload (in the simulated foreground state or in the background). In still other embodiments, the measured data includes data consumed by the app during its specific activity with preload (in the simulated foreground state or in the background). In addition, alternatively, the measured data includes data consumed by the app during its "main activity" (entry point activity as defined above) with a specified preload (in the simulated foreground state or in the background). In some embodiments, the OS counts activities preloaded as part of AppPreload and as part of InAppPreload (preloading of in-app activities) separately.

[0240] In some embodiments, the OS maintains a data consumption budget for preloaded data. In some embodiments, the OS sets an overall data consumption budget for all apps together. In other embodiments, the OS sets a separate data consumption budget for each app. In some embodiments, the OS maintains a separate data consumption budget for each given duration, such as a daily budget, a weekly budget, a monthly budget, etc. In some embodiments, the duration is determined based on the user's usage pattern.

[0241] In some embodiments, the OS sets the data consumption budget to a predefined fixed parameter (e.g., 10MB). In some embodiments, the OS sets the data consumption budget to a dynamic parameter. In some embodiments, the dynamic parameter is set based on learning of app / device usage patterns. In some embodiments, the budget for a given app in a given time period is set to a function (e.g., a linear function) of the estimated user usage of the app in the given time period.

[0242] In some embodiments, when a certain data consumption budget is reached, the OS will avoid triggering additional preloads that affect the certain preload budget. For example, when the data consumption budget of a given app in a given period and a given set of functions (AppPreLoad / InAppPreLoad) is exhausted, the OS does not trigger further preloads for the given set of functions for the remainder of the given period. In some embodiments, the OS tracks the data consumption budget that has been consumed and adjusts the preload strategy to reduce the chance of consuming the preload budget in the next given period.

[0243] In some embodiments, the preload data budget is defined as part of a broader data budget (such as a data budget for background states), either per app or for the entire user device.

[0244] In some embodiments, when deciding whether to preload, the OS considers the resources required for app preloading. Such resources may include, for example, power consumption, cellular data, memory, CPU, GPU, etc. In some embodiments, the OS learns this information over time by measuring the resources consumed during preloading. In some embodiments, the app at least partially declares its requirements for at least a portion of such user device resources (e.g., through an API).

[0245] User Opt-Out / Opt-In

[0246] In some embodiments, the OS 48 provides the user with a UI option to opt-out of preload and / or opt-in to preload. In some embodiments, opt-in / out is only related to the AppPreload functionality (i.e., the OS will not trigger app preload for a user who has opted out of AppPreload and vice versa). In some embodiments, opt-in / out is only related to InAppPreload (i.e., preloading of activities within an app). In some embodiments, opt-in / out is related to both AppPreload and InAppPreload functionality.

[0247] In some embodiments, the opt-in / out is given as an option in a certain settings menu. The option can be explicit, for example, the user can explicitly select whether the OS should trigger the relevant preload function set. In other embodiments, the opt-in / out is implicit, for example, using a UI option that is not directly related to preloading. For example, forcibly stopping an app (e.g., through a settings menu in Android, or by sweeping the app from a recent menu in iOS) will result in an implicit opt-out of preloading, at least until the app is not in a forced-stop state. As another example, setting the user device to a node state (e.g., an Android battery saver state) by the user will result in an implicit opt-out of preloading, at least until the user device has exited from a power-saving state.

[0248] App Opt-Out / Opt-In

[0249] In some embodiments, OS 48 provides the app with the option to opt out and / or opt in to preload, for example, through an API. In some embodiments, the OS provides an API for both AppPreload and InAppPreload to opt out and opt in. In other embodiments, the OS provides an API that allows the app to choose which function to opt out / into: AppPreload, InAppPreload, or both. When the app opts out of the preload function, the OS does not trigger the function until the app opts in again.

[0250] User-initiated preload trigger

[0251] In the embodiments described so far, the preloading operation is generally triggered by the OS 48 in response to various possible conditions and criteria. In alternative embodiments, the OS 48 enables the user to explicitly request preloading. In some embodiments, the OS 48 provides a UI that includes an option for the user to explicitly request preloading of a particular app or a group of apps. The preloading agent 50 preloads an app or a group of apps in response to an explicit request from the user provided using the UI option.

[0252] In an embodiment, OS 48 presents UI options to the user only for apps that support app preloading. In some embodiments, the option is presented as part of the UI of the user device home screen (also referred to as a "launcher" in Android OS). In some embodiments, the UI option lets the user access additional launch options for a particular app through some UI method of the home screen, for example, by pressing and holding the selected app icon, and the additional launch options include an explicit option to preload the selected app.

[0253] When explicitly preloaded due to a user's request, agent 50 preloads the app in the background, for example, using any of the preloading techniques described herein or using any other suitable preloading technique.

[0254] In some embodiments, preloading is completely transparent to the user. In other embodiments, although the app is preloaded in the background (not displayed to the user), allowing the preloading operation has some impact on the user experience, for example, due to the use of user device resources such as CPU and audio. In some embodiments, the OS 48 does not play the audio of the preloaded app to prevent interference with the user. These categories of partial transparency or opacity may be acceptable to users because the app is preloaded due to their explicit request.

[0255] In some embodiments, the app supports both preloading explicitly requested by the user and preloading that occurs not due to a user's request (e.g., triggered by the OS). In some embodiments, the app uses the same logic for both types of preloading. In other embodiments, the app uses different logic for user-initiated preloading and non-user-initiated (e.g., OS-initiated) preloading.

[0256] In some embodiments, the app is unaware of preloading explicitly requested by the user. This means that the app runs the same logic during preloading and normal launch. Specifically, in these embodiments, the app does not need to integrate a specific API to support preloading. This functionality may be acceptable in the case of preloading explicitly requested by the user rather than preloading that occurs without user request (e.g., preloading that the user is unaware of). For example, it may be reasonable for certain app actions, such as reporting that the user has launched an app's analytics, to be performed in the case of preloading explicitly requested by the user rather than preloading that occurs without user request, in which case such actions may not be applicable.

[0257] Reporting preloading status to the user

[0258] In some embodiments, OS 48 presents information to the user indicating the current progress status of preloading. Any suitable output may be used for this purpose. For example, OS 48 may present to the user a progress bar that gradually fills as preloading progresses. For example, such a progress bar may be displayed as part of an app icon or elsewhere in the UI.

[0259] As another example, after completing preloading of an app, OS 48 indicates to the user that the app is ready to be used. This indication is referred to herein as "preload complete". The OS may provide a preload complete indication only for apps whose preloading is triggered by the user, only for apps whose preloading is triggered by the OS without an explicit request from the user, or for both. In some embodiments, the preload complete indication for apps whose preloading is triggered by the OS (without an explicit request from the user) is different from the preload complete indication provided for preloading apps whose preloading is explicitly triggered by the user.

[0260] In some embodiments, the OS provides a preload completion indication through a UI notification, for example, in a window of the OS UI that normally displays a notification to the user. In some embodiments, the preload completion indication is provided by appropriately marking the icon of the app on the launcher.

[0261] It will be understood that the above embodiments are cited by way of example, and the present invention is not limited to what has been specifically shown and described above. More specifically, the scope of the present invention includes combinations and sub-combinations of the various features described above and variations and modifications of the present invention, which will be thought of by those skilled in the art after reading the above description and are not disclosed in the prior art. The documents incorporated by reference into this patent application are considered to be an integral part of this application, except that any term is defined in these incorporated documents to some extent in a manner that conflicts with the definition explicitly or implicitly made in this specification, and only the definition in this specification should be considered.

Claims

1. A method for preloading an application, comprising: In a user device, determining to preload at least a user interface (UI) display of a user application; as well as preloading at least the UI display in a simulated foreground mode prior to a user request of the user device to interact with the user application, wherein the UI display (i) is processed in the foreground mode from the perspective of the user application but simultaneously (ii) remains in the background mode and is hidden from the user from the perspective of the user, Wherein preloading at least the UI display in the simulated foreground mode includes preventing the preloading from affecting one or both of (i) usage metrics of the user device, and (ii) decisions related to entering a power saving state.

2. The method according to claim 1, The method includes maintaining (i) one or more first data structures for storing non-preloaded UI displays and (ii) one or more second data structures for storing preloaded UI displays, in, Preloading the UI display includes initially assigning the UI display to one of the second data structures and subsequently reassigning the UI display to one of the first data structures in response to satisfying a criterion.

3. The method according to claim 2, wherein: Upon determining that preloading of the UI display is successfully completed, or upon user interaction with the user application, reallocation of the UI display to one of the first data structures is performed.

4. The method according to claim 2, wherein: The one or more first data structures include one or more first stacks of non-preloaded UI displays, and wherein the one or more second data structures include one or more second stacks of preloaded UI displays.

5. The method according to claim 2, wherein: The one or more first data structures include a target display associated with a non-preloaded UI display, and wherein the one or more second data structures include one or more virtual displays associated with a preloaded UI display.

6. The method according to any one of claims 1 to 5, wherein: Preloading the UI display includes specifying lifecycle events of the operating system of the user device as an active foreground process.

7. The method according to any one of claims 1-5, the method comprising determining that preloading of the UI display is successfully completed based on a completion criterion, and in response, transitioning the UI display to a preloaded background state, in which the user application and the user both believe that the UI display is in the background.

8. The method according to claim 7, wherein: Determining that the preloading completed successfully includes detecting expiration of a maximum duration set for the simulated foreground mode.

9. The method according to claim 7, wherein: Determining that the preloading is successfully completed includes receiving a notification from the user application that the preloading is successfully completed.

10. The method of any one of claims 1-5, comprising discarding a preloaded UI display in response to detecting an error occurring in the simulated foreground mode.

11. The method according to any one of claims 1 to 5, wherein: Preloading at least the UI display further comprises preventing the preloading from affecting a recent list of the user device.

12. The method according to any one of claims 1 to 5, wherein: Preloading at least the UI display includes notifying the user application via an application programming interface (API) that at least the UI display is being preloaded.

13. The method according to any one of claims 1 to 5, wherein: Preloading at least the UI display includes notifying the user application via an application programming interface (API) of detected user interactions with the preloaded user application.

14. The method according to any one of claims 1 to 5, wherein: Preloading at least the UI display includes preloading at least a portion of the user application starting from an entry point UI display of the user application.

15. The method according to claim 14, wherein: Preloading the user application includes preloading the entry point UI display and one or more additional UI displays according to a launch sequence of the user application.

16. The method according to claim 14, wherein: Preloading the user application includes preloading the given UI display only upon verifying that a call for a given UI display is preload initiated and not user initiated.

17. The method according to claim 14, wherein: Preloading the user application includes determining that preloading of the user application is successfully completed by detecting expiration of a maximum defined duration.

18. The method according to claim 14, wherein: Preloading the user application includes determining that preloading of the user application is successfully completed by receiving a notification from the user application that the preloading is successfully completed.

19. The method according to claim 14, wherein: Preloading the user application excludes preloading of one or more of the following: Content that changes at a rate exceeding a predefined rate; and It preloads content that needs to be obtained from the network.

20. The method according to any one of claims 1 to 5, wherein: Preloading at least the UI display includes preloading one or more UI displays within apps, the UI displays within apps being associated with the user application but not displayed immediately when the user application is launched.

21. The method according to claim 20, wherein: Preloading of a UI display within the app is performed when the user application is running in a foreground mode.

22. The method according to claim 20, wherein: When the user application is running in background mode, preloading of the UI display within the app is performed.

23. The method according to claim 20, wherein: Preloading the UI display within the app includes caching the preloaded UI display within the app in a memory of the user device, and providing the preloaded UI display within the app from the memory in response to a request from the user application.

24. The method according to claim 23, wherein: Caching the in-app UI displays includes assigning a corresponding expiration time to each in-app UI display, and providing the in-app UI display from the memory only in response to verifying that the expiration time has not expired.

25. The method of any one of claims 1-5, further comprising maintaining a preloading policy that manages preloading of UI displays.

26. The method according to claim 25, wherein: Maintaining the preloading policy includes running a system app that maintains the preloading policy in the user device.

27. The method according to claim 26, wherein: Maintaining the preloading strategy includes setting the preloading strategy through communication between the system app and a network-side server.

28. The method according to any one of claims 1 to 5, wherein: Preloading at least the UI display includes preloading the UI display with a target orientation different than a current display orientation of the user device.

29. The method according to claim 28, wherein: The target orientation is an orientation in which the user is predicted to access the user application.

30. The method according to any one of claims 1 to 5, wherein: Preloading at least the UI display includes acquiring content for the UI display over a network, the content having a higher quality than real-time acquisition of the content.

31. The method according to any one of claims 1 to 5, wherein: Deciding to preload at least the UI display includes receiving an explicit request from the user to preload the user application.

32. A method according to any one of claims 1-5, the method comprising presenting to the user information indicating the progress of preloading at least the UI display.

33. A user device for preloading an application, comprising: a display screen configured to display a user interface (UI) display of a user application to a user; as well as A processor configured to: Decide to preload at least the UI display of the user application; as well as preloading at least the UI display in a simulated foreground mode prior to a user request of the user device to interact with the user application, wherein the UI display (i) is processed in the foreground mode from the perspective of the user application but simultaneously (ii) remains in the background mode and is hidden from the user from the perspective of the user, Wherein preloading at least the UI display in the simulated foreground mode includes preventing the preloading from affecting one or both of (i) usage metrics of the user device, and (ii) decisions related to entering a power saving state.

34. The user equipment according to claim 33, wherein: The processor is configured to: maintaining (i) one or more first data structures for storing non-preloaded UI displays and (ii) one or more second data structures for storing preloaded UI displays, The UI display is initially assigned to one of the second data structures, and subsequently, in response to a criterion being met, the UI display is reassigned to one of the first data structures.

35. The user equipment according to claim 34, wherein: The processor is configured to reallocate the UI display to one of the first data structures upon determining that preloading of the UI display is successfully completed or upon user interaction with the user application.

36. The user equipment according to claim 34, wherein: The one or more first data structures include one or more first stacks of non-preloaded UI displays, and wherein the one or more second data structures include one or more second stacks of preloaded UI displays.

37. The user equipment according to claim 34, wherein: The one or more first data structures include a target display associated with a non-preloaded UI display, and wherein the one or more second data structures include one or more virtual displays associated with a preloaded UI display.

38. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to preload the UI display by applying a lifecycle event of an operating system of the user device specified for an active foreground process.

39. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to determine that preloading of the UI display is successfully completed based on completion criteria, and in response, transition the UI display to a preloaded background state in which both the user application and the user believe that the UI display is in the background.

40. The user equipment according to claim 39, wherein: The processor is configured to determine that preloading is successfully completed by detecting expiration of a maximum duration set for the simulated foreground mode.

41. The user equipment according to claim 39, wherein: The processor is configured to determine that the preloading is successfully completed by receiving a notification from the user application that the preloading is successfully completed.

42. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to discard a preloaded UI display in response to detecting an error occurring in the simulated foreground mode.

43. The user equipment according to any one of claims 33 to 37, wherein: The processor is also configured to prevent preloading of the UI display from affecting a recent list of the user device.

44. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to notify the user application via an application programming interface (API) that at least the UI display is being preloaded.

45. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to notify the user application via an application programming interface (API) of a detected user interaction with a preloaded user application.

46. ​​The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to preload at least a portion of the user application starting from an entry point UI display of the user application.

47. The user equipment according to claim 46, wherein: The processor is configured to preload the user application by preloading the entry point UI display and one or more additional UI displays according to a launch sequence of the user application.

48. The user equipment according to claim 46, wherein: The processor is configured to preload the given UI display only upon verifying that the call for the given UI display is preload initiated and not user initiated.

49. The user equipment according to claim 46, wherein: The processor is configured to determine that preloading of the user application is successfully completed by detecting expiration of a maximum defined duration.

50. The user equipment according to claim 46, wherein: The processor is configured to determine that preloading of the user application is successfully completed by receiving a notification of the successful completion of the preloading from the user application.

51. The user equipment according to claim 46, wherein: When preloading the user application, the processor is configured to exclude preloading of one or more of the following items: Content that changes at a rate exceeding a predefined rate; and It preloads content that needs to be obtained from the network.

52. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to preload one or more in-app UI displays that are associated with the user application but are not immediately displayed when the user application is launched.

53. The user equipment according to claim 52, wherein: The processor is configured to preload a UI display within the app when the user application is running in a foreground mode.

54. The user equipment according to claim 52, wherein: The processor is configured to preload a UI display within the app when the user application runs in background mode.

55. The user equipment according to claim 52, wherein: The processor is configured to cache a UI display within a preloaded app in a memory of the user device and provide the UI display within the preloaded app from the memory in response to a request from the user application.

56. The user equipment according to claim 55, wherein: The processor is configured to assign a corresponding expiration time to each cached in-app UI display, and to provide the in-app UI display from the memory only in response to verifying that the expiration time has not expired.

57. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to maintain a preloading policy that manages preloading of a UI display.

58. The user equipment according to claim 57, wherein: The processor is configured to run a system app that maintains the preload policy.

59. The user equipment according to claim 58, wherein: The processor is configured to set the preloading policy through communication between the system app and a network-side server.

60. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to preload the UI display in a target orientation different than a current display orientation of the user device.

61. The user equipment according to claim 60, wherein: The target orientation is an orientation in which the user is predicted to access the user application.

62. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to acquire content displayed by the UI through a network, the quality of the content being higher than quality for real-time acquisition of the content.

63. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to decide to preload at least the UI display in response to receiving an explicit request from the user to preload the user application.

64. The user equipment according to any one of claims 33 to 37, wherein: The processor is configured to present information to the user indicating a progress of preloading at least the UI display.

Images