Multi-screen control method, storage medium and intelligent equipment

Abstract

The invention relates to the technical field of android system screen control, particularly provides a multi-screen control method, a storage medium and intelligent equipment, and aims to solve the problems that existing android system multi-screen control is large in resource occupation and large in implementation difficulty, for this purpose, the multi-screen control method provided by the invention comprises the steps of obtaining a mapping relation, and judging whether the user in the mapping relation belongs to a managed user established by the operating system, judging the connection state of the corresponding screen for the user belonging to the managed user in the mapping relation, and independently starting a system interface and a starter of the connected screen by the corresponding user for the connected screen. According to the method and the device, the purpose of respectively managing multiple users and application program data in one Android system is realized by utilizing a managed user mechanism provided by an Android native system, multiple sets of kernels and the Android system do not need to be operated, the occupied resources are few, the realization difficulty is low, and the effects of saving hardware resources and reducing cost are achieved.

Description

Technical Field

[0001] The present application relates to the technical field of screen control of Android systems, and in particular to a multi-screen control method, a storage medium and a smart device. Background Art

[0002] Currently, there are two main technical solutions for controlling multiple screens in the Android system: one is the virtualization solution, which uses low-level virtualization technologies such as Kernel-based Virtual Machine (KVM) to run multiple kernels and Android systems; the other is the container solution, which uses container isolation technology to enable one kernel to run multiple Android systems. However, both of the above solutions will run two relatively complete Android systems, occupying more resources and involving hardware virtualization technology, which is difficult to implement.

[0003] Accordingly, the art needs a new multi-screen control solution to solve the above problems. Summary of the invention

[0004] In order to overcome the above-mentioned defects, the present application is proposed to solve or at least partially solve the technical problem that the existing Android system multi-screen control occupies a lot of resources and is difficult to implement.

[0005] In a first aspect, a multi-screen control method is provided, the method comprising: obtaining a mapping relationship, wherein the mapping relationship comprises a correspondence between a preset screen and a user; determining whether the user in the mapping relationship belongs to a managed user created by an operating system; for a user in the mapping relationship who belongs to the managed user, determining a connection status of a corresponding screen; and for a screen whose connection status is connected, having the corresponding user independently start a system interface and a launcher of the connected screen.

[0006] In a technical solution of the above-mentioned multi-screen control method, the method further includes: representing the screen by a physical address of the screen and representing the user by a user name to form the mapping relationship.

[0007] In a technical solution of the above-mentioned multi-screen control method, the acquiring of the mapping relationship comprises: in response to the start of the system service, loading a configuration file from a non-volatile storage medium into a memory, wherein the configuration file comprises the mapping relationship.

[0008] In a technical solution of the above multi-screen control method, the method further includes: for a user who is not a managed user in the mapping relationship, creating a managed user for the user so that the user becomes a managed user.

[0009] In a technical solution of the above multi-screen control method, the method further includes: in response to creation of a managed user, updating the ID of the corresponding user and the ID of the screen in the mapping relationship.

[0010] In a technical solution of the above-mentioned multi-screen control method, the method further includes obtaining change information of the connection status of the screen.

[0011] In a technical solution of the above-mentioned multi-screen control method, the method further includes: in response to obtaining that the connection status of the screen that is connected changes to being disconnected, stopping the current process of the corresponding user.

[0012] In a technical solution of the above-mentioned multi-screen control method, for the screen whose connection status is connected, the corresponding user independently starts the system interface and launcher of the connected screen, including: for the screen whose connection status is connected, querying the managed user corresponding to the connected screen; starting the managed user; and the managed user independently starting the system interface and launcher of the connected screen.

[0013] In a technical solution of the above-mentioned multi-screen control method, in response to obtaining that the screen with a connection status of connected changes to disconnected, stopping the current process of the corresponding user includes: in response to obtaining that the screen with a connection status of connected changes to disconnected, querying the user corresponding to the screen with the status change; stopping the current process of the corresponding user.

[0014] In a technical solution of the above-mentioned multi-screen control method, the method also includes: for a screen whose connection status is connected, obtaining information on whether the home screen key is touched; in response to the information that the home screen key is touched, querying the corresponding user in the mapping relationship; and the corresponding user controls the screen where the home screen key is touched to return to the launcher interface.

[0015] Solution 1. A multi-screen control method, characterized in that it includes: obtaining a mapping relationship, wherein the mapping relationship includes a preset correspondence between a screen and a user; determining whether the user in the mapping relationship belongs to a managed user created by an operating system; for a user in the mapping relationship who belongs to the managed user, determining the connection status of the corresponding screen; and for a screen whose connection status is connected, having the corresponding user independently start the system interface and launcher of the connected screen.

[0016] Solution 2. The multi-screen control method according to Solution 1 is characterized in that the method also includes: representing the screen with a physical address of the screen and representing the user with a user name to form the mapping relationship.

[0017] Solution 3. The multi-screen control method according to Solution 1 is characterized in that obtaining the mapping relationship includes: in response to the startup of the system service, loading a configuration file from a non-volatile storage medium into the memory, wherein the configuration file includes the mapping relationship.

[0018] Solution 4. The multi-screen control method according to Solution 1 is characterized in that the method further includes: for a user who is not a managed user in the mapping relationship, creating a managed user for the user so that the user becomes a managed user.

[0019] Solution 5. The multi-screen control method according to Solution 4 is characterized in that the method also includes: in response to the creation of a managed user, updating the ID of the corresponding user and the ID of the screen in the mapping relationship.

[0020] Solution 6. The multi-screen control method according to Solution 1 is characterized in that the method also includes obtaining change information of the connection status of the screen.

[0021] Solution 7. The multi-screen control method according to Solution 6 is characterized in that the method also includes: in response to obtaining that the connection status of the screen from being connected changes to being disconnected, stopping the current process of the corresponding user.

[0022] Solution 8. The multi-screen control method according to Solution 1 is characterized in that, for the screen whose connection status is connected, the corresponding user independently starts the system interface and launcher of the connected screen, including: for the screen whose connection status is connected, querying the managed user corresponding to the connected screen; starting the managed user; and the managed user independently starting the system interface and launcher of the connected screen.

[0023] Solution 9. The multi-screen control method according to Solution 7 is characterized in that in response to obtaining that the screen with a connection status of connected changes to disconnected, stopping the current process of the corresponding user, including: in response to obtaining that the screen with a connection status of connected changes to disconnected, querying the user corresponding to the screen with the status change; stopping the current process of the corresponding user.

[0024] Scheme 10. The multi-screen control method according to Scheme 1 is characterized in that the method also includes: for a screen whose connection status is connected, obtaining information on whether the home screen key is touched; in response to the information that the home screen key is touched, querying the corresponding user in the mapping relationship; and the corresponding user controls the screen whose home screen key is touched to return to the launcher interface.

[0025] Scheme 11. The multi-screen control method according to Scheme 1 is characterized in that the method also includes: for a screen whose connection status is connected, obtaining information on whether it is awakened; in response to the information that the screen is awakened, querying the corresponding user in the mapping relationship; and the corresponding user controls the awakened screen to return to the launcher interface.

[0026] Solution 12. A computer-readable storage medium storing a plurality of program codes, wherein the program codes are suitable for being loaded and run by a processor to execute the multi-screen control method described in any one of Solutions 1 to 11.

[0027] Scheme 13. A smart device, characterized in that the smart device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein a computer program is stored in the memory, and when the computer program is executed by the at least one processor, the multi-screen control method described in any one of Schemes 1 to 11 is implemented.

[0028] The above one or more technical solutions of the present application have at least one or more of the following beneficial effects:

[0029] In the technical solution for implementing the present application, the managed user mechanism (also called work profile mechanism) provided by the Android native system is used to achieve the purpose of managing multiple users and application data in an Android system separately. Specifically, this embodiment first obtains the mapping relationship between the screen and the user, and then determines whether the user in the mapping relationship is a managed user that has been created by the Android system. If it is a managed user that has been created, the connection status of the screen corresponding to the user is determined, and for the screen in the connected state, the corresponding user independently starts its system interface and launcher. Since this embodiment does not need to run multiple sets of kernels and Android systems, it occupies fewer resources, and the managed user mechanism provided by the Android native system is used to isolate multiple users, which is less difficult to implement, thereby achieving the effect of saving hardware resources and reducing implementation costs, and solving the problem that the existing Android system multi-screen control occupies a lot of resources and is difficult to implement. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The disclosure of the present application will become easier to understand with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present application. Among them:

[0031] Figure 1 is a schematic flow chart of the main steps of a multi-screen control method according to an embodiment of the present application;

[0032] Figure 2a It is a schematic diagram of the framework of the multi-screen startup process of the Android system in the related art;

[0033] Figure 2b is a schematic diagram of a framework of a multi-screen startup process of an Android system according to an embodiment of the present application;

[0034] Figure 3 is a schematic diagram of the overall framework of a multi-screen control method according to an embodiment of the present application;

[0035] Figure 4 is a schematic diagram of a modified SystemUi startup process according to an embodiment of the present application;

[0036] Figure 5 is a schematic diagram of a modified Home startup process according to an embodiment of the present application;

[0037] Figure 6 It is a schematic diagram of the main structure of a smart device according to an embodiment of the present application.

[0038] Reference numerals:

[0039] 11: memory; 12: processor. DETAILED DESCRIPTION

[0040] Some embodiments of the present application are described below with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are only used to explain the technical principles of the present application and are not intended to limit the protection scope of the present application.

[0041] In the description of the present application, the terms "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices. The terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected, it can be indirectly connected through an intermediate medium, it can also be the internal communication of two elements, it can be a wireless connection, or it can be a wired connection.

[0042] In addition, "module" and "processor" may include hardware, software or a combination of the two. A module may include hardware circuits, various suitable sensors, communication ports, and memories, and may also include software parts, such as program codes, or a combination of software and hardware. The processor may be a central processing unit, a microprocessor, an image processor, a digital signal processor, or any other suitable processor. The processor has data and / or signal processing functions. The processor may be implemented in software, hardware, or a combination of the two. Computer-readable storage media include any suitable media that can store program codes, such as magnetic disks, hard disks, optical disks, flash memory, read-only memory, random access memory, etc.

[0043] In addition, if the meaning of "and / or" appears in this application, it includes three parallel solutions. Taking "A and / or B" as an example, it includes solution A, solution B, or a solution that satisfies both A and B. In addition, the technical solutions between the various embodiments can be combined with each other, but it must be based on the ability of ordinary technicians in this field to implement. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by this application. The term "at least one A or B" or "at least one of A and B" has a similar meaning to "A and / or B" and can include only A, only B, or A and B. The singular terms "one" and "this" can also include plural forms.

[0044] The relevant user personal information that may be involved in the various embodiments of this application is strictly in accordance with the requirements of laws and regulations, following the principles of legality, legitimacy and necessity, based on the reasonable purposes of business scenarios, to process the personal information that users actively provide during the use of products / services or generated due to the use of products / services, as well as the personal information obtained with the user's authorization.

[0045] The user personal information processed by this application will vary depending on the specific product / service scenario, and shall be based on the specific scenario in which the user uses the product / service, and may involve the user's account information, device information, driving information, vehicle information or other related information. This application will treat the user's personal information and its processing with a high degree of diligence.

[0046] This application attaches great importance to the security of user personal information and has taken reasonable and feasible security protection measures that meet industry standards to protect user information and prevent personal information from being accessed, disclosed, used, modified, damaged or lost without authorization.

[0047] Here we first explain some terms involved in this application.

[0048] The managed user mechanism, also known as the work profile, refers to adding multiple users to an Android system, each with its own application data and settings. In this way, different users can use different accounts and applications without interfering with each other. The main goal of this approach is to create an isolated environment that can be used to store managed data while maintaining the privacy and security of user profiles.

[0049] An automated driving system (ADS) refers to a system that will continuously perform all dynamic driving tasks (DDT) within its own operational domain design (ODD). That is, the machine system is allowed to fully assume the task of automatic vehicle control only under the specified appropriate driving scenario conditions, that is, the system is activated when the vehicle meets the ODD conditions, and the system replaces the human driver as the driving subject of the vehicle. Among them, the dynamic driving task DDT refers to the continuous lateral (left and right steering) and longitudinal motion control (acceleration, deceleration, constant speed) of the vehicle, as well as the detection and response to targets and events in the vehicle's driving environment. The design operating range ODD refers to the conditions under which the automated driving system can operate safely, and the conditions set may include geographic location, road type, speed range, weather, time, national and local traffic laws and regulations, etc.

[0050] For multiple screens connected by an Android system, if you want to control multiple screens separately, you can usually use kernel-based virtual machines or container isolation technology. However, the above two solutions occupy more resources and are difficult to implement. Therefore, a new multi-screen control solution is needed to solve the above problem.

[0051] See attached Figure 1 , Figure 1 FIG. 1 is a flow chart of the main steps of a multi-screen control method according to an embodiment of the present application. Figure 1 As shown, the multi-screen control method in the embodiment of the present application mainly includes the following steps S101 to S104:

[0052] Step S101, obtaining a mapping relationship, wherein the mapping relationship includes a preset corresponding relationship between a screen and a user.

[0053] In this embodiment, taking the in-vehicle Android system as an example, assuming that there are at least two screens in the car connected to the same Android system, to realize the control of multiple screens separately, it is first necessary to obtain the correspondence between multiple screens and users. It should be noted that the mapping relationship can be pre-written in the configuration table when the vehicle leaves the factory. For example, if there are two screens in the vehicle, two users are set in advance and matched. It should be noted that this embodiment does not impose specific restrictions on the number of screens, and it can include two or more according to the specific situation.

[0054] In one implementation, when configuring the correspondence between the screen and the user, the user can be represented by a user name (such as a string consisting of letters, numbers and special characters), a user identity identifier, etc.; the screen can be represented by an identifier such as a physical address when the screen is connected using a USB (Universal Serial Bus) interface or a MAC address (Media Access Control Address) when connected using a Wi-Fi (WIreless Fidelity) interface, thereby forming a mapping relationship (configuration table) between the screen and the user.

[0055] As an example, the configuration table includes four screens in the car and the corresponding users, using numbers and letters to represent the screens and users, as shown in Table 1 below: Table 1. Mapping relationship configuration table Screen user 1 A 2 B 3 C 4 D

[0056] According to the mapping relationship configuration table in Table 1, screen 1 corresponds to user A, screen 2 corresponds to user B, screen 3 corresponds to user C, and screen 4 corresponds to user D.

[0057] Step S102: determining whether the user in the mapping relationship is a managed user that has been created by the operating system.

[0058] In this embodiment, in order to use the managed user mechanism provided by the Android native system to control multiple screens separately, it is first necessary to configure that the users in the table have corresponding managed users in the Android operating system, that is, the users in Table 1 must belong to the managed users created by the operating system.

[0059] In one implementation, when the Android system is run for the first time, a corresponding managed user can be created according to the configuration table. After the first creation is completed, the created managed user will not disappear when the system is restarted, and will only be erased when the system is restored to factory settings.

[0060] Step S103: for the user who is a managed user in the mapping relationship, determine the connection status of the corresponding screen.

[0061] In this embodiment, if the user in the mapping relationship is a managed user, it is necessary to further obtain the screen corresponding to the user according to the mapping and determine the connection status of the screen. The connection status includes connected and unconnected. Only the connected screen can be controlled by the corresponding (managed) user.

[0062] Step S104 , for a screen whose connection status is connected, the corresponding user independently starts the system interface and the launcher of the connected screen.

[0063] In this embodiment, for the connected screens, the corresponding users respectively control the screens with which they are mapped. Specifically, controlling the screens includes: the corresponding users respectively independently start the system interface (SystemUI) and launcher (home) of the connected screens. The system interface is used to provide elements for users to interact with the screen interface, and the launcher is used to manage other installed applications.

[0064] In one implementation, referring to the mapping relationship configuration table in Table 1 in step S101, for created users, for example, users A, B, C, and D are all managed users in the operating system, then the screens 1, 2, 3, and 4 corresponding to users A, B, C, and D are respectively monitored to see which are connected. If it is detected that screens 1, 2, and 3 are connected to the Android system via a USB interface, the system interface and launcher for screens 1, 2, and 3 can be independently started by the corresponding users A, B, and C, respectively.

[0065] Based on the method described in steps S101 to S104 above, the purpose of managing multiple users and application data in an Android system is achieved by using the managed user mechanism (also called work profile mechanism) provided by the Android native system. Specifically, this embodiment first obtains the mapping relationship between the screen and the user, and then determines whether the user in the mapping relationship is a managed user that has been created by the Android system. If it is a managed user that has been created, the connection status of the screen corresponding to the user is determined, and for the screen in the connected state, the corresponding user independently starts its system interface and launcher. Since this embodiment does not need to run multiple sets of kernels and Android systems, it occupies fewer resources, and the isolation of multiple users is achieved based on the managed user mechanism provided by the Android native system, and the implementation difficulty is relatively low, achieving the effect of saving hardware resources and reducing implementation costs, and solving the problem that the existing Android system multi-screen control occupies a lot of resources and is difficult to implement.

[0066] In an optional implementation, step S101 further includes the following step S1011:

[0067] Step S1011, in response to the start of the system service, loading a configuration file from a non-volatile storage medium into a memory, wherein the configuration file includes a mapping relationship.

[0068] In this embodiment, since this method needs to bind each screen to a managed user in the system, it is necessary to obtain the preset correspondence between the screen and the user. Specifically, a custom service can be created to load the configuration file into the memory storage, and in subsequent use, the configuration file stored in the memory can be called through the custom service, so as to achieve the purpose of individually controlling the corresponding screen with different user identities according to the bound screen and user relationship.

[0069] In one implementation, the custom service is started during the system service startup process, wherein the system service (SystemServer) is a key component in the Android system that starts and manages multiple core system services, and is responsible for gradually starting and initializing multiple core system services, such as PackageManagerService, ActivityManagerService, and WindowManagerService. The system service is mainly created by the Zygote process through the fork mechanism. During the system service startup process, the configuration file containing the mapping relationship is loaded into the memory from the non-volatile storage medium (such as a solid state drive, a flash memory card) through the custom service, so as to facilitate the calling of the mapping relationship to realize the separate control of multiple screens.

[0070] In an optional implementation, when step S103 determines that the user in the mapping relationship is not a managed user, the method further includes step S105, which specifically includes the following steps S1051 and S1052:

[0071] Step S1051: For a user who is not a managed user in the mapping relationship, a managed user is created for the user so that the user becomes a managed user.

[0072] In this embodiment, referring to the mapping relationship configuration table in Table 1 in step S101, the mapping relationship includes users A, B, C, and D. Assuming that A, B, and C are managed users created in the operating system, and D has not yet created a corresponding managed user in the operating system, it is necessary to first change user D to a managed user in the operating system. That is, create a storage space and application data directory for the user. The specific implementation method can refer to the managed user mechanism of the Android system, which will not be repeated here.

[0073] In one implementation, the system distinguishes and isolates data of different users and applications based on user IDs (userId), and only users or applications with corresponding permissions can access or modify the corresponding data.

[0074] Step S1052: in response to the creation of the managed user, updating the corresponding user ID and screen ID in the mapping relationship.

[0075] In this embodiment, it is assumed that the configuration file (user_context.json) is as follows: [

[0077] {

[0078] "userId":-10000,

[0079] "displayPhyPort":1,

[0080] "userName":"A",

[0081] "displayId":-1

[0082] },

[0083] {

[0084] "userId":-10000,

[0085] "displayPhyPort":2,

[0086] "userName":"B",

[0087] "displayId":-1

[0088] } ]

[0090] Among them, userName (user name) and displayPhyPort (physical port of the screen) in the configuration file are used to indicate the mapping relationship between the user and the screen. "userId": -10000, "displayId": -1 are invalid values. When the Android system is started for the first time and the configuration file is loaded for the first time, the system will assign corresponding values ​​to "userId" (user ID) and "displayId" (screen ID). It should be noted that "userId" is used to distinguish the storage space corresponding to multiple users. For example, if "userId" is added to the storage path of the data directory, when the physical port of the screen is long, "displayId" can be used instead of displayPhyPort to match the screen corresponding to "userId", thereby improving the search efficiency and system security performance.

[0091] In an optional implementation, after step S104, the method further includes step S106, specifically including the following steps S1061 and S1062:

[0092] Step S1061, obtaining the change information of the connection status of the screen.

[0093] In this embodiment, DisplayManagerService is a very important service in the Android system, responsible for managing all display devices, including the connection and disconnection of the screen and external display devices; processing display-related events and requests, such as screen rotation, resolution adjustment, display mode switching; providing query and setting of the status and properties of all display devices, etc. DisplayManagerService provides a DisplayManager interface to the outside world, which can be called to monitor the change information of the screen connection status.

[0094] Step S1062, in response to obtaining that the screen with a connection status of connected changes to disconnected, stopping the current process of the corresponding user.

[0095] In this embodiment, when the connection status of a connected screen changes to unconnected, the current process of the user corresponding to the screen is stopped, that is, the running process is terminated, thereby providing a clean environment when the user starts next time.

[0096] Specifically, the above step S1062 further includes the following steps S10621 and S10622:

[0097] Step S10621, in response to obtaining that the screen whose connection status is connected changes to unconnected, querying the user corresponding to the screen whose status changes.

[0098] In this embodiment, when it is obtained that the screen whose connection status is connected changes to being disconnected, the configuration file previously loaded into the memory can be called to query the user corresponding to the screen.

[0099] Step S10622, stop the current process of the corresponding user.

[0100] In this embodiment, according to the query result of step S10622, the current process of the user corresponding to the screen whose connection state changes from connected to unconnected is stopped, that is, the process running under the user identity is terminated.

[0101] In an optional implementation, the above step S104 may further include the following steps S1041 to S1043:

[0102] Step S1041 : for a screen whose connection status is connected, query the managed user corresponding to the connected screen.

[0103] In this embodiment, the steps in the above embodiment are referred to to query the managed users corresponding to the connected screens. Specifically, assuming that screens 1 and 2 are connected, according to the configuration file (user_context.json), it can be queried that screens 1 and 2 correspond to users A and B respectively, and users A and B are managed users created by the operating system.

[0104] Step S1042, start the managed user.

[0105] In this embodiment, according to the query result in step S1041, users A and B found out by the connected screen query are started. The managed users A and B have application data separated from the user 0 profile, which belongs to a managed profile and has separate application data, so that the purpose of controlling the application separately based on the managed users can be achieved.

[0106] Step S1043: The managed user independently starts the system interface and launcher of the connected screen.

[0107] In this embodiment, after the managed users A and B are started, applications on the connected screen, such as a system interface and a launcher, may be started based on the managed users A and B, respectively.

[0108] In one implementation, system applications, such as the user interface and launcher provided by the system, may be started based on the managed user, or third-party applications, such as applications downloaded by the user, may be started based on the managed user.

[0109] It is understandable that the system interface usually includes a navigation bar, a status bar, a notification bar, and a prompt box. Among them, the navigation bar usually includes a back button, a home button, and a menu button; the status bar usually refers to a row of display areas at the top of the screen, which is used to display current status information, such as time, signal strength, battery power, network connection status, etc.; the notification bar is often displayed in a pull-down manner, and is a component provided by the Android system to display important information and reminders to users; the prompt box is a type of message box used to display information to users, collect input, or confirm user operations. The launcher is usually used to manage other applications other than itself, such as: allowing users to customize and adjust the layout, theme, and wallpaper of the desktop; providing some practical tools, such as weather forecast, quick dialing, and calendar, so that users can directly obtain relevant information on the desktop without opening the corresponding application; providing better program management and organization functions, automatically classifying applications according to different categories, making it easier for users to find related applications; allowing users to create folders to organize similar applications together; supporting quick search of contacts and address books, making it easier for users to find and make calls.

[0110] In an optional implementation, after step S104, the method further includes step S107, specifically including steps S1071 to S1073:

[0111] Step S1071, for a screen whose connection status is connected, obtain information on whether the home screen key is touched.

[0112] In this embodiment, whether the home button is touched is monitored by SystemService to obtain information on whether the home button is touched.

[0113] Step S1072: In response to the information that the home button is touched, query the corresponding user in the mapping relationship.

[0114] In this embodiment, when information is obtained that the home screen key is touched, for example, information that the home screen key of screen 2 is touched is obtained, it means that the screen needs to return to the launcher interface, but at this time there is only the screen information (such as the screen ID is equal to 2), and there is no corresponding managed user information. Therefore, in response to the event that screen 2 needs to return to the launcher, it is also necessary to query the corresponding managed user in the mapping relationship.

[0115] Step S1073: The corresponding user controls the screen where the home button is touched to return to the launcher interface.

[0116] In this embodiment, it can be known from the query of the mapping relationship that the managed user corresponding to screen 2 is B. Therefore, user B controls the screen 2 whose home button is touched to return to the launcher interface.

[0117] In an optional implementation, after step S104, the method further includes step S108, specifically, including the following steps S1081 to S1083:

[0118] Step S1081, for a screen whose connection status is connected, obtain information on whether it is awakened.

[0119] In this embodiment, for a connected screen, information is obtained as to whether it is awakened. For example, if a screen is in a locked state after the power button is clicked, information that the screen is awakened can be obtained through a custom service when the power button is clicked again.

[0120] Step S1082: In response to the information that the screen is awakened, query the corresponding user in the mapping relationship.

[0121] In this embodiment, when the information that the screen is awakened is obtained, such as the information that the screen 1 is awakened, the user corresponding to the screen 1 is queried from the mapping relationship table.

[0122] Step S1083: The corresponding user controls the awakened screen to return to the launcher interface.

[0123] In this embodiment, according to the user queried in step S1082, the control screen 1 returns to the launcher interface.

[0124] In an application scenario according to an embodiment of the present application, the present embodiment utilizes the managed user mechanism provided by the native Android system, and at the same time modifies the process (logic) of starting multiple screens in the native Android system. Specifically, Figure 2a Schematic diagram of the framework of the multi-screen startup process of the Android system in the related art. Figure 2a As shown, taking the in-car scenario as an example, assuming that the car has two rear screens connected to the same Android system, the left screen and the right screen are used to distinguish the two rear screens, and the left screen corresponds to (managed) user 10, and the right screen corresponds to (managed) user 11.

[0125] In the prior art, the Android system starts by first starting the Linux kernel. The first user process started in the kernel is the init process (init startup). The init process starts the zygote service, and Zygote will further start the SystemServer. The specific process is as follows: SystemServer starts the virtual screen user 0, where the virtual screen user 0 is a special system user. It does not directly correspond to a specific individual user, but is mainly used to run system services and applications to ensure the normal operation of the system. Further, the SystemServer process will start the SystemUI application, that is, the virtual screen SystemUi is started, and the virtual screen SystemUI faces user 0, and then SystemServer starts Home, which also faces user 0. It should be noted that Home is mainly used to manage and display the user's home screen and application list, allowing users to interact by sliding the desktop and clicking icons. For the two rear screens, the Android system displays the SystemUI and Home of user 0 on multiple secondary screens by default, that is, the two rear screens will display the same SystemUI and Home as the system user. Among them, SystemUi and Home of user 0 are virtual operating interfaces within the Android system, which can also be called virtual screens. However, when a separate screen is connected to the virtual screen, SystemUI and Home of virtual screen user 0 can also be displayed on the screen.

[0126] In order to allow the two rear screens to display different content, this application modifies the startup process of the Android system. Figure 2b , Figure 2b FIG. 1 is a schematic diagram of a framework of a multi-screen startup process of an Android system according to an embodiment of the present application. Figure 2b As shown, after init is started, SystemServer is started, wherein SystemServer startup includes: starting virtual screen user 0, after virtual screen user 0 is started, that is, after ensuring the normal operation of the system, user 10 and user 11 are started respectively, and then user 10 starts the corresponding (left screen) SystemUi and Home, and user 11 starts the corresponding (right screen) SystemUi and Home.

[0127] In an optional implementation, many Android system services will be started in SystemServer, among which startBootstrapServices (start bootstrap service), startCoreServices (start core service), and startOtherServices (start other services) are the three most important services. This embodiment creates a custom service UserContextService to start when startOtherServices is started, thereby modifying the Android native system startup process. Figure 3 , Figure 3 Schematic diagram of the overall framework of a multi-screen control method according to an embodiment of the present application. Figure 3 As shown in the figure, the first startup of the Android system is used to explain the modified startup process. The modified startup process runs during the process of SystemServer starting other services (startOtherServices). The specific process is as follows:

[0128] "SystemServiceManager.startService(UserContextService.class)" means using the startService() method of the SystemServiceManager class to start the custom user context service, namely UserContextService. Among them, the SystemServiceManager class is used to create and start various system services. startService() is the method provided by Android to start the Service. After starting through startService, the service will continue to run indefinitely. Only when the stopService() or stopSelf() method is called externally, the Service will stop running and be destroyed. When the startService() method is used to start the service, if the service has not been created, the system will first call the onCreate() method of the service, and then call the onStart() method. If the service has been created before calling the startService() method, calling the startService() method multiple times will not result in multiple creation of the service, but will result in multiple calls to the onStart() method.

[0129] Assuming that the user context service UserContextService.class has been created before calling the startService() method, "UserContextService.onStart" indicates that the user context service responds to the start event and performs some basic initialization operations, such as loading the configuration file user_context.json into the memory and storing it as a mapping relationship, where the mapping relationship can be a mapping relationship between the screen physical address, user ID, and user name. When the initialization operation is completed, "UserContextService.onSystemReady" is used to notify the Activity Manager Service (AMS) that it is ready to start.

[0130] After the user context service, i.e., UserContextService, is started and ready, all user names in the mapping relationship are traversed to determine whether the user already exists. If not (corresponding to the first system startup or the first system startup after restoring factory settings), a managed user (profile user) is created based on the user name. It is understandable that the user ID can only be determined after the managed user is created for the first time. The user ID is used to distinguish different managed users and can be stored in the mapping relationship.

[0131] If the user already exists (corresponding to the situation where the system is not started for the first time) or the user does not exist but the user has been created, start the system user (user 0), for example, use the onUserUnlocked() method to start the system user: UserContextService.onUserUnlocked(user 0).

[0132] Then, the screen plug-in and unplug-out actions are monitored. Assuming that screens 1, 2, and 3 in the configuration table are in a connected state and no screen plug-in and unplug-out events are monitored, all physical screens are traversed at this time, and the online screen is started, that is, the user corresponding to the connected screen, that is, the user corresponding to screens 1, 2, and 3. It can be understood that the user corresponding to the screen can be obtained by calling the mapping relationship. Referring to the mapping relationship in Table 1, the users corresponding to screens 1, 2, and 3 are users A, B, and C, so the user corresponding to the online screen is started at this time, that is, users A, B, and C are started; assuming that a screen in a connected state, such as screen 2, is unplugged at this time, that is, a screen plug-in and unplug-out event is monitored, and the user corresponding to the offline screen, that is, the user corresponding to screen 2, needs to be stopped at this time. Specifically, by calling the mapping relationship, it can be known that stopping the user corresponding to the offline screen is to stop user B, that is, to terminate the running process under user B; assuming that screen 4 changes from an unconnected state to a connected state at this time, that is, a screen plug-in and unplug-out event is monitored, and the user corresponding to the online screen, that is, the user D corresponding to screen 4, needs to be started at this time. It should be noted that when it is necessary to obtain the mapping relationship between the screen and the user, the mapping relationship in the memory may be called for query.

[0133] When the users corresponding to the connected (online) screens are all started, such as using UserContextService.onUserUnlocked(user X) to start user X, user X can start SystemUi and Home on the corresponding screen.

[0134] It should be noted that this embodiment modifies the logic of starting SystemUi and starting Home in the Android system by programming before the Android system is running. Figure 4 , Figure 4 FIG. 1 is a schematic diagram of a modified SystemUi startup process according to an embodiment of the present application. Figure 4 As shown in the figure, after the Android system is turned on, SystemServer is started, including starting core services (startCoreServices), starting other services (startOtherServices), and starting SystemUI. Among them, the process of starting other services includes starting a custom user context service (UserContextService), which stores the configuration table as a mapping relationship in the memory. It should be noted that starting SystemUI and UserContextService is asynchronous and there is no specific order.

[0135] Then the system will start the SystemUi of the corresponding screen as user X (i.e. the managed user in the configuration table). Specifically, the SystemUi startup process mainly includes: running the ActivityThread.bindApplication method in the Framework, which is a key method in the Android application startup process and is responsible for initializing the context environment of the application. When multiple screens are connected to the same Android system, the native Android system will display the same SystemUi on multiple screens. In order to realize the control of SystemUi of multiple screens respectively, after the context environment of SystemUi is initialized, this embodiment first calls the mapping relationship table in the memory to obtain the screen corresponding to user X, such as updating the display associated with user X through Context.updateDisplay. Since different programs in the Android system cannot share memory, this embodiment uses UserContextService to query the (mapping relationship) table across processes, and then initializes the application and monitors its status and behavior, such as using the instrumentation.callApplicationOnCreate method, and then starts and manages the SystemUI service through the SystemUIApplication.onCreate method, and starts the navigation bar (createNavigationBar only for my display) on the screen corresponding to user X. It should be noted that, since the native Android system only limits the system user's navigation bar to be displayed on multiple secondary screens, when modifying the system interface startup logic, you only need to modify the navigation bar startup logic.

[0136] See attached Figure 5 , Figure 5 FIG. 1 is a schematic diagram of a modified Home startup process according to an embodiment of the present application. Figure 5As shown, starting SystemServer includes starting core services (startCoreServices), starting other services (startOtherServices), and initializing the key service AMS (Activity Manager Service). After the initialization is completed, the systemReady method is called to notify the application that the system is ready, that is, mActivityManagerService.systemReady. Among them, the process of starting other services includes starting a custom user context service (UserContextService), which stores the configuration table as a mapping relationship in the memory. After the application is ready, the native Android system will traverse all screens to start the system user's Home. In this embodiment, the system user's Home is started only on the virtual screen (mAtmInternal.startHomeOnDisplay). For other screens, the Home is started on the corresponding screen as the (managed) user X, that is, the Home is started on the required screen with the found user identity.

[0137] In addition, this embodiment also makes corresponding modifications to the power button wake-up scenario and the Home button press scenario. Since when user X starts Home on the corresponding screen, the identity of user X is already there, but when the power button or the Home button is touched, only the ID of the screen can be obtained, and it is necessary to call the mapping relationship to obtain the user ID corresponding to the screen, so as to control the screen separately. Exemplarily, after using the PhoneWindowManager.wakeUpFromWakeKey method to obtain the window wake-up action or the Home button click event through PhoneWindowManager.handleHomeButton, the Home corresponding to the button is called through startDockOrHome, and further, the RootWindowContainer.startHomeOnTaskDisplayArea method is used to cross-process table lookup to obtain the user corresponding to the touched screen, and the obtained parameters (such as the user's ID) are passed to start Home on the required screen with the found user identity (user ID).

[0138] This embodiment achieves the purpose of controlling multiple screens connected to an Android system separately by modifying the startup process of the Android system and combining it with the managed user mechanism, so that the multiple screens appear to the user as completely independent systems. When it is applied in a vehicle-mounted scenario, using one SOC (System on a Chip) to drive two or more screens can achieve the effect of saving hardware resources and reducing the cost of the entire vehicle.

[0139] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effect of the present application, different steps do not have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders. These adjusted schemes are equivalent to the technical schemes described in this application, and therefore will also fall within the scope of protection of this application.

[0140] It is understood by those skilled in the art that all or part of the processes in the method for implementing the above-mentioned embodiment of the present application can also be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable storage medium may include: any entity or device, medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory, random access memory, electrical carrier signal, telecommunication signal and software distribution medium, etc. that can carry the computer program code.

[0141] Another aspect of the present application also provides a computer-readable storage medium.

[0142] In an embodiment of a computer-readable storage medium according to the present application, the computer-readable storage medium may be configured to store a program for executing the multi-screen control method of the above-mentioned method embodiment, and the program may be loaded and run by a processor to implement the above-mentioned multi-screen control method. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The computer-readable storage medium may be a storage device formed by various electronic devices. Optionally, the computer-readable storage medium in the embodiment of the present application is a non-temporary computer-readable storage medium.

[0143] Another aspect of the present application also provides a smart device.

[0144] In an embodiment of an intelligent device according to the present application, the intelligent device may include at least one processor; and a memory connected to the at least one processor in communication; wherein a computer program is stored in the memory, and when the computer program is executed by the at least one processor, the method described in any of the above embodiments is implemented. The intelligent device described in the present application may include a driving device, a smart car, a robot, and the like. Figure 6 , Figure 6 FIG. 4 exemplarily shows that the memory 11 and the processor 12 are communicatively connected via a bus.

[0145] In some embodiments of the present application, the smart device may further include at least one sensor, which is used to sense information. The sensor is connected to any type of processor mentioned in the present application. Optionally, the smart device may also include an automatic driving system, which is used to guide the smart device to drive itself or assist driving. The processor communicates with the sensor and / or the automatic driving system to complete the method described in any of the above embodiments. The smart device described in the present application may be, but is not limited to, a mobile phone, a tablet computer, a desktop, a laptop, a handheld computer, a notebook computer, a vehicle-mounted device, an ultra-mobile personal computer (UMPC), etc., and the embodiments of the present application are not limited to this.

[0146] So far, the technical solution of the present application has been described in conjunction with an embodiment shown in the accompanying drawings, but it is easy for those skilled in the art to understand that the protection scope of the present application is obviously not limited to these specific embodiments. Without departing from the principles of the present application, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present application.

Claims

1. A multi-screen control method, characterized in that: include: Acquire a mapping relationship, wherein the mapping relationship includes a preset correspondence relationship between a screen and a user; Determining whether the user in the mapping relationship is a managed user created by the operating system; For a user belonging to the managed user in the mapping relationship, determining a connection state of a corresponding screen; as well as For a screen whose connection status is connected, the corresponding user independently starts the system interface and the launcher of the connected screen.

2. The multi-screen control method according to claim 1, characterized in that: The method further includes: representing the screen by a physical address of the screen and representing the user by a user name to form the mapping relationship.

3. The multi-screen control method according to claim 1, characterized in that: The acquiring of the mapping relationship comprises: in response to the start of the system service, loading a configuration file from a non-volatile storage medium into a memory, wherein the configuration file comprises the mapping relationship.

4. The multi-screen control method according to claim 1, characterized in that: The method further comprises: For a user who is not a managed user in the mapping relationship, a managed user is created for the user so that the user becomes a managed user.

5. The multi-screen control method according to claim 4, characterized in that: The method further comprises: In response to the creation of a managed user, the corresponding user ID and screen ID in the mapping relationship are updated.

6. The multi-screen control method according to claim 1, characterized in that: The method further includes acquiring change information of a connection state of the screen.

7. The multi-screen control method according to claim 6, characterized in that: The method further comprises: In response to obtaining that the screen in the connection state of being connected changes to being disconnected, stopping the current process of the corresponding user.

8. The multi-screen control method according to claim 1, characterized in that: For a screen in a connected state, the corresponding user independently starts the system interface and the launcher of the connected screen, including: For a screen whose connection status is connected, query the managed user corresponding to the connected screen; Starting the managed user; The system interface and launcher of the connected screen are independently launched by the managed user.

9. The multi-screen control method according to claim 7, characterized in that: In response to obtaining that the screen in the connection state of being connected changes to being disconnected, stopping the current process of the corresponding user includes: In response to obtaining that the screen in the connection state of connected changes to unconnected, querying a user corresponding to the state-changed screen; Stop the current process of the corresponding user.

10. The multi-screen control method according to claim 1, characterized in that: The method further comprises: For a screen in connected state, obtain information on whether the home screen button is touched; In response to the information that the home screen key is touched, querying a corresponding user in the mapping relationship; The corresponding user controls the screen where the home key is touched to return to the launcher interface.

Images