Application running method and electronic device

Abstract

The application provides an application running method and an electronic device, and relates to the technical field of terminals. The electronic device is in a first scene mode. The electronic device receives a starting operation for a first application. In response to the starting operation, the electronic device can determine a first target application policy corresponding to an attribute label of the first application and the first scene mode, so as to determine whether to run the first application by using the first target application policy. The attribute label of the first application indicates whether the first application is a risk application. Then, the electronic device switches to a second scene mode in response to a scene mode switching operation input by a user. Then, the user starts the first application again, and the electronic device can determine a second target application policy corresponding to the attribute label of the first application and the second scene mode, so as to determine whether to run the first application by using the second target application policy, thereby realizing flexible running of the application and meeting the use demand of the user in different scene modes.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to an application operation method and electronic device. Background Technology

[0002] With the development of electronic devices (such as mobile phones), mobile phone configurations have improved, and the number and types of applications (APPs) that can be installed on mobile phones have also increased. In order for users to use the services provided by APPs, the mobile phone needs to run the APP. For example, after receiving the user's launch operation for the APP, the mobile phone launches the APP to run it.

[0003] However, some apps may be risky applications, and running such apps on a mobile phone may pose security risks. Therefore, to ensure mobile phone security, there is an urgent need for a solution regarding how to run applications on a mobile phone. Summary of the Invention

[0004] This application provides an application running method and an electronic device to enable flexible operation of risky applications on the electronic device and meet user needs in different scenario modes.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, an application execution method is provided for an electronic device. The electronic device receives a first operation, which triggers the electronic device to launch a first application on the electronic device.

[0007] In response to the first operation, when the electronic device is in a first scenario mode, the electronic device can use the attribute access control module to find the first target application policy corresponding to the attribute tag of the first application and the information of the first scenario mode. The attribute tag of the first application is a risk tag. Subsequently, if the first target application policy indicates that operation is prohibited, the electronic device stops launching the first application.

[0008] Subsequently, the electronic device receives a second operation input by the user, which triggers the electronic device to switch to a second scene mode. In response to this second operation, the electronic device switches from the first scene mode to the second scene mode.

[0009] Subsequently, the electronic device receives another first user input indicating that it needs to launch the first application. In response to this first input, the electronic device can use the attribute access control module to find the second target application policy corresponding to the attribute tag and second scene mode information of the first application. If the second target application policy instructs the device to run, the first application is launched.

[0010] In this application, when the electronic device is in a first scenario mode and needs to launch a first application, it determines a first target application policy corresponding to the risk label of the first application and the first scenario mode. Since the first target application policy indicates that the application should not run, the electronic device does not run the first application; that is, in the first scenario mode, the risky application is prohibited from running to ensure the security of the electronic device. Afterwards, the electronic device switches to a second scenario mode. When the electronic device needs to launch the first application again, it determines a second target application policy corresponding to the risk label of the first application and the second scenario mode. Considering that the second scenario mode has lower security requirements, or considering that the application's risk attributes may be misidentified, the second target application policy may indicate that the application should run. The electronic device can then continue to run the first application, thus enabling the risky application to run in the second scenario mode, achieving flexible operation of the risky application and meeting user needs in different scenario modes.

[0011] In one possible design, the aforementioned second target application strategy indication can mean that operation occurs after successful authentication. Accordingly, when the second target application strategy indicates that operation occurs after successful authentication, the electronic device can perform authentication and obtain an authentication result. This authentication result indicates whether the user currently using the electronic device is the target user corresponding to the second scenario mode. The authentication result can indicate authentication success or authentication failure.

[0012] If the authentication result indicates successful authentication, it means that the user currently using the electronic device is the target user corresponding to the second scenario mode, and the electronic device can launch the first application.

[0013] If the authentication result indicates that the authentication failed, it means that the user currently using the electronic device is not the target user corresponding to the second scenario mode, and the electronic device can stop launching the first application.

[0014] Based on this, when the second target application strategy instructs the electronic device to run after successful authentication, the electronic device determines whether to continue running the first application based on the authentication result, thereby enabling flexible operation of the application and ensuring the security of the electronic device to a certain extent.

[0015] In one possible design, the aforementioned second target application strategy instructs the application to run only after confirmation. Accordingly, when the second target application strategy instructs the application to run only after confirmation, a confirmation prompt is output, prompting the user to confirm whether to run the first application. Subsequently, upon receiving confirmation from the user, indicating that the user has confirmed running the first application, the electronic device can respond to this confirmation and launch the first application. This allows for flexible application operation and avoids situations where the user knows the application is safe but the electronic device mistakenly identifies it as a risky application, preventing the user from using it.

[0016] In one possible design, the aforementioned second target application policy indication allows operation. Accordingly, when the second target application policy indicates that operation is allowed, the electronic device can directly launch the first application, enabling flexible application operation.

[0017] In one possible design approach, the application strategy corresponding to the aforementioned first scenario mode can be set based on user needs. The electronic device can obtain user-inputted application strategy settings through the attribute access control module. This settings include at least a mapping relationship between attribute tags and operation mode information; the attribute tags are risk tags, and the operation mode information indicates that operation is prohibited. Then, the electronic device can determine a first target application strategy, including the application strategy settings and the first scenario mode in which the electronic device is located, through the attribute access control module. Finally, the electronic device can save the first target application strategy through the attribute access control module, thus generating the first target application strategy and meeting the user's needs regarding how to run risky applications in the first scenario mode.

[0018] In one possible design approach, the electronic device can detect whether any applications on the device pose a risk through a risk awareness service. If a risk is detected in a first application through the risk awareness service, the device sends the identifier of the first application to the attribute access control module. Subsequently, the electronic device can use the attribute access control module to set the attribute label of the first application as a risk label based on the first application's identifier, thus achieving the setting of the risk attribute.

[0019] In one possible design, the electronic device is in a first scenario mode. When it needs to launch a first application, the electronic device sends the identifier of the first application to the attribute access control module via the activity manager. This allows the attribute access control module to look up the attribute tags of the first application and determine whether it is a risky application. Then, based on the identifier, the attribute access control module determines that the attribute tag of the first application is a risk tag. Next, the electronic device can use the attribute access control module to find the first target application policy corresponding to the risk tag and the information of the first scenario mode (i.e., the first scenario mode). If the first target application policy indicates that it should not run, the electronic device can send a prohibition result to the activity manager via the attribute access control module, indicating that it should not run. Then, in response to the prohibition result, the electronic device can stop launching the first application via the activity manager. Based on this, the electronic device, through the attribute access control module and the activity manager, determines whether the first application should run, thus achieving lifecycle management of risky applications.

[0020] Secondly, an electronic device is provided, which has the function of implementing the method described in the first aspect. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0021] Thirdly, an electronic device is provided, including a memory and one or more processors; the memory and the processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs an application running method as described in any one of the first aspects above.

[0022] Fourthly, a computer-readable storage medium is provided, including computer instructions that, when executed on an electronic device, cause the electronic device to perform the application execution method described in any one of the first aspects.

[0023] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the application running method described in any one of the first aspects above.

[0024] It is understood that the beneficial effects achieved by the electronic devices described in the second and third aspects above, the computer storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can be referred to the beneficial effects in the first aspect and any possible implementation thereof, and will not be repeated here. Attached Figure Description

[0025] Figure 1A This application provides an example of an application running scenario diagram.

[0026] Figure 1B This is a schematic diagram of an application operation scenario provided in an embodiment of this application;

[0027] Figure 1C This application provides an example of an application scenario. Figure 3 ;

[0028] Figure 2A This application provides an example of an application scenario. Figure 4 ;

[0029] Figure 2B This application provides an example of an application scenario. Figure 5 ;

[0030] Figure 2C This application provides an example of an application scenario. Figure 6 ;

[0031] Figure 3 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0032] Figure 4 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0033] Figure 5 A schematic diagram of resource access provided in this application embodiment;

[0034] Figure 6 A flowchart illustrating an application running method provided in an embodiment of this application;

[0035] Figure 7A A schematic diagram of an application strategy setting process provided in an embodiment of this application;

[0036] Figure 7B A schematic diagram of an application strategy setting scenario provided in this application embodiment;

[0037] Figure 7C This application provides an example of an application strategy setting scenario. Figure 3 ;

[0038] Figure 7D This application provides an example of an application strategy setting scenario. Figure 4 ;

[0039] Figure 8 This is a second schematic diagram of resource access provided in an embodiment of this application. Detailed Implementation

[0040] To facilitate a clear description of the technical solutions in the embodiments of this application, the terms "exemplary" or "for example" are used in the embodiments of this application to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a specific manner. In the embodiments of this application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. In the embodiments of this application, "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more.

[0041] For ease of understanding, some terms involved in the embodiments of this application will be explained below.

[0042] Media files, also known as multimedia files, refer to files that contain various media content such as images, audio, and video, including photos, music, and video files. Multimedia files are generally stored in binary format.

[0043] Structured data refers to data stored in a structured form on electronic devices, such as contact data, metadata of multimedia files, call logs, text messages, calendars, etc.

[0044] Metadata for multimedia files refers to the data that describes the multimedia file. For example, for a photograph, metadata may include basic information such as the photograph's name and size, shooting information such as shooting location, shooting time, and exposure time, and photograph attribute information such as resolution.

[0045] In some embodiments, electronic devices (such as mobile phones) have multi-user functionality, meaning the phone can enter different user modes, such as owner mode, child mode, and guest mode. After entering a user mode (such as owner mode), the phone frequently involves running applications on the phone. The phone can run the application based on an application policy that matches that application. For example, if the application to be run is a security application, the phone can run the application normally. For instance, such as... Figure 1A As shown, the user clicks the icon 10 of the first game application on the phone's home screen. In response to the click, the phone launches the first game application and loads its startup content (such as displaying...). Figure 1B The startup animation 11 shown and as shown Figure 1C The loading interface shown in 12) is used to run the first game application. Here, the first game application is a security application.

[0046] When the application to be run is a risky application, the phone can directly block its execution, displaying a warning message indicating that the application is prohibited from running. This prevents privacy data leaks and other security issues caused by running risky applications, ensuring the phone's security. For example, if the phone receives a user's click on an app such as... Figure 2A The icon 20 for the first shopping app is shown. The phone needs to run this first shopping app; however, this first shopping app is a risky application, therefore, the phone stops launching the app, and the following output is displayed: Figure 2B The risk application is prohibited from running (Message 21) shown here, informing the user why the First Shopping application has stopped running.

[0047] Alternatively, when the app to be run is a risky app, the phone can run the app normally, but while the app is running, the phone displays a risky app warning message to inform the user that the app is risky and may cause security problems. For example, the phone receives a user's click on an app such as... Figure 2A The icon 20 for the first shopping app is shown. The phone launches the first shopping app normally, and it displays as shown below. Figure 2C The startup interface 22 shown is displayed, and a risk application warning message 23 is displayed on the startup interface 22.

[0048] However, the application strategy matched with the application is the same in different scenario modes (such as user mode), resulting in poor application operation flexibility and the inability to meet the user's usage needs in different scenario modes.

[0049] Therefore, to address the aforementioned problems, this application provides a method for running an application on an electronic device. The electronic device is in a first scenario mode. The electronic device receives a launch operation for a first application. In response to this launch operation, the electronic device determines that the attribute label of the first application is a risk label, i.e., it determines that the first application is a risky application. Then, the electronic device obtains a first target application policy corresponding to the first scenario mode and the risk label. If the first target application policy indicates that operation is prohibited, the electronic device stops launching the first application. Afterwards, when a user wants the electronic device to switch to another scenario mode, the user can input a scenario mode switching operation (or a second operation). In response to this scenario mode switching operation, the electronic device can switch to the second scenario mode. Then, upon receiving a launch operation from the user for the first application, the electronic device, in response to this launch operation, obtains a second target application policy corresponding to the second scenario mode and the risk label. Considering that the second scenario mode has lower security requirements, or that the application's risk attribute may be misidentified, the risky application can run in the second scenario mode. Therefore, the electronic device can determine that the second target application policy indicates operation (e.g., operation after authentication, operation after confirmation, or operation allowed), and launch the first application to achieve the operation of the first application. Based on this, the application strategy for matching the attribute tags of the first application can be different in different scenario modes, so as to realize the flexible setting of the application strategy, thereby enabling the flexible operation of the application, meeting the user's usage needs in different scenario modes, and improving the user experience.

[0050] For example, the electronic device in the embodiments of this application may be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as wearable device, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, and other electronic devices with object resources. The embodiments of this application do not impose special restrictions on the specific form of the electronic device.

[0051] Figure 3 A schematic diagram of the structure of the electronic device 100 is shown.

[0052] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc.

[0053] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0054] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0055] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0056] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0057] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0058] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the electronic device 100.

[0059] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0060] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0061] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0062] The modem processor may include a modulator and a demodulator. The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as Wi-Fi), Bluetooth, Global Navigation Satellite System (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0063] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with networks and other devices through wireless communication technology.

[0064] Electronic device 100 implements display functions through GPU, display screen 194, and application processor.

[0065] The display screen 194 is used to display images, videos, etc. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0066] The electronic device 100 can implement shooting functions through an ISP, a camera 193, a video codec, a GPU, a display 194, and an application processor. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0067] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0068] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as multimedia files (e.g., images, videos, audio, etc.), structured data, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0069] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0070] The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0071] Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc.

[0072] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1.

[0073] For example, the software system of the aforementioned electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to illustrate the software structure of the electronic device 100.

[0074] Figure 4 This is a software structure block diagram of the electronic device 100 according to an embodiment of the present invention.

[0075] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0076] The application layer can include a series of application packages.

[0077] like Figure 4 As shown, the application package may include applications such as camera, gallery, calendar, call, map, video, SMS, scene modes, and risk awareness services.

[0078] The scenario mode is used to provide a relevant interface for users to input application strategy settings.

[0079] The aforementioned risk awareness service can be used to determine the attributes of an application. For example, the risk awareness service can be a security application on an electronic device, such as a system administrator application or an antivirus application.

[0080] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0081] like Figure 4 As shown, the application framework layer may include an activity manager service (AMS) and an attribute access control module.

[0082] The aforementioned activity manager can be used to manage the lifecycle of an application, such as the processes of starting, running, pausing, stopping, and destroying the application.

[0083] The attribute access control module described above can be used to manage application policies, such as modifying, generating (or setting), deleting, and querying application policies. It can also be used to manage application attributes (i.e., application attribute tags). These attributes indicate whether the application is a secure or risky application. Furthermore, the attribute access control module can determine the application policy that matches the application, allowing the system to decide whether to run the application based on that policy.

[0084] In addition, the attribute access control module can also determine the scene mode of the electronic device. For example, scene mode may include functional mode (such as airplane mode, do not disturb mode, etc.) and / or user mode.

[0085] In some embodiments, the attribute access control module described above may include a policy management module, an attribute management module, and a decision module. The policy management module manages application policies, the attribute management module manages application attributes, and the decision module decides whether to run the application.

[0086] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0087] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0088] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0089] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0090] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0091] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0092] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0093] A 2D graphics engine is a drawing engine for 2D drawing.

[0094] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0095] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0096] It is understood that the software layer and its contents included in the electronic device described above are merely examples, and this application does not limit them.

[0097] In the embodiments of this application, such as Figure 5 As shown, electronic devices can set application policies for object resources on the device, enabling the addition of access control points. Then, when a subject object of the electronic device, such as an application or user, accesses the object resource, the electronic device can use a resource access service (such as an attribute access control module) to determine an appropriate target policy (such as a target application policy) based on the subject object and the object resource's attribute tags, combined with the scenario mode—that is, the current environment of the electronic device. This target policy is then used to decide whether the subject object can access the object resource. If it is determined that the subject object cannot access the resource, the electronic device can block the subject object's access. If it is determined that the subject object can access the resource, the subject object can continue to access the object resource.

[0098] The attribute tags of the aforementioned object resources can include tag 1 and tag 2, where tag 1 and tag 2 are different. For example, such as Figure 5 As shown, when the object resource is an application, the application's attribute tags can indicate whether the application is a risky application. Specifically, tag 1 can be a safe tag (or a normal tag), and tag 2 can be a risky tag. It is understandable that when the object resource is an application, the description of a subject object accessing an application can also be replaced with the subject object calling or using the application to make the application run.

[0099] When the object resource is a file or structured data, the attribute tags of the file or structured data can indicate whether the file or structured data is privacy data. Specifically, tag 1 can be a privacy tag, and tag 2 can be a regular tag (i.e., a non-privacy tag).

[0100] Optionally, the attribute labels of the aforementioned object resources can be automatically identified and set by the electronic device. Alternatively, the attribute labels of the object resources can be set by the electronic device in response to user operations. For example, the user can input corresponding operations according to their own needs to trigger the electronic device to set the attribute labels of the object resources; or, the electronic device can recommend attribute labels of object resources to the user, and then, upon receiving the user's trigger operation, the electronic device will set the attribute labels of the object resources to the recommended attribute labels.

[0101] In addition, such as Figure 5 As shown, object resources can also include hardware resources and functional services. Hardware resources may include microphones, cameras, Wi-Fi chips, positioning chips, Bluetooth chips, NFC chips, etc. Functional services may include application installation / uninstallation services, system sharing services, device discovery services, etc.

[0102] The following will take the aforementioned electronic device as a mobile phone, the subject as the user, and the object as the application, in conjunction with the above... Figure 4 The software structure shown illustrates the access process for object resources on electronic devices provided in this application. Specifically, as... Figure 6 As shown, the process can be as follows:

[0103] S201, The attribute access control module obtains application policy setting information input by the user.

[0104] For example, the attribute access control module obtains application policy settings information input by the user through other applications (such as scene mode applications). When the user wants to set application policies on the phone, the user enters the application policy settings information on the relevant interface provided by the phone. In response to the user's... Figure 7A The click action shown in the settings app launches the settings app and displays the following: Figure 7B The settings interface shown. Then, in response to user requests... Figure 7B Clicking the scene mode control in the settings interface will launch the scene mode application and display the scene mode settings interface (e.g., ...). Figure 7C As shown, the scenario mode settings interface is used to set application policies. Afterwards, the scenario mode application receives the application policy settings information entered by the user in the application policy interface and sends this information to the attribute access control module so that the attribute access control module can generate the corresponding application policy.

[0105] The application policy settings mentioned above may include at least attribute tags and operating mode information. Attribute tags include security tags and risk tags. If an application's attribute tag is security, the application is a secure application. If an application's attribute tag is risk, the application is a risky application.

[0106] The operation mode information indicates how the application corresponding to the attribute tag should operate, which can indicate either forbidden or enabled. For example, enabled can include one or more of allowed, enabled after user confirmation (or enabled after confirmation), and enabled after authentication.

[0107] "Allow to run" means the phone can run the corresponding application directly. "Run after user confirmation" means the phone will only continue running the corresponding application after receiving confirmation from the user. "Run after successful authentication" means the phone will only continue running the corresponding application after successfully authenticating the user's identity. "Disallow running" means the phone will stop running the corresponding application. Optionally, "Run after successful authentication" can also be called "locked running".

[0108] It is understandable that the application policy settings information input by the user can be the attribute tags and operating mode information selected by the user. The application policy settings information can actually be a mapping relationship (or correspondence) between attribute tags and operating mode information.

[0109] It should be noted that the operating methods described above are merely examples. Other methods may also be included, such as the hidden operating method. This hidden operating method means the phone hides the application, meaning the user cannot find the application from the phone's home screen, global search, or application management list.

[0110] S202. The attribute access control module generates the corresponding application policy 1 based on scenario mode 1 and the above application policy setting information.

[0111] Here, Scene Mode 1 (or alternatively described as the first Scene Mode) represents the current scene mode of the phone. The attribute access control module determines the current scene mode of the phone so that it can generate the application policy under the current scene mode using the application policy settings information input by the user. For example, if the phone is currently in owner mode, then Scene Mode 1 is owner mode. Another example is that if the phone's current user mode is "Xiaoming" mode, then Scene Mode 1 is "Xiaoming" mode.

[0112] Application strategy 1 (or alternatively described as the first target application strategy) may include information about scenario mode 1 (i.e., identifier), attribute labels, and operation mode information.

[0113] In this embodiment, the attribute access control module includes an application policy management function (FileAccessPolicyManager). This application policy management function may include at least application policy setting (set) functionality, application policy query (get) functionality, application policy clearing (clear) functionality, and application policy modification functionality.

[0114] The application policy setting function described above is used to generate application policies. The application policy query function is used to query application policies. The application policy clearing function is used to delete application policies. The application policy modification function is used to update application policies.

[0115] S203, The attribute access control module displays the policy setting results. The policy setting results indicate that the policy was set successfully.

[0116] If the policy setting result indicates successful policy setting, it means that application policy 1 has been successfully generated based on the user-input application policy setting information. Alternatively, application policy 1 may fail to be generated. In this case, the attribute access control module displays a policy setting result indicating failure, so that the user is promptly informed whether the application policy was set successfully. Optionally, the policy setting prompt message can indicate to the user that the application policy setting failed and that they can try setting it again after a certain period of time.

[0117] It should be noted that displaying the policy setting results is only one possible way to output the policy setting results. The attribute access control module can also output the policy setting results in other ways, such as voice output.

[0118] In addition, after generating application policy 1, the attribute access control module can also display application policy 1 (e.g., ...). Figure 7D Application strategy 1 shown).

[0119] In some embodiments, S203 above is an optional step, that is, regardless of whether the attribute access control module successfully generates application policy 1, the mobile phone does not need to display the policy setting result through the attribute access control module.

[0120] In some embodiments, the application policy can be generated not only based on the application policy information input by the user, but also automatically generated by the mobile phone, that is, preset.

[0121] S204. The attribute access control module saves application strategy 1 to database 1.

[0122] For example, the attribute access control module can save the application policy 1 corresponding to the current scene mode information to data table 1 in database 1. Data table 1 (e.g., the AppAccessPolicy table) is used to store application policies. Data table 1 includes at least three fields: scene mode (mode), attribute label (security_attribute), and operation mode information (access_policy).

[0123] The attribute label field can have a value of either character 1 (or label 1) or character 2 (or label 2). Character 1 (normal) represents a safety label, and character 2 (risk) represents a risk label. Character 1 and character 2 are different; for example, character 1 can be 0 and character 2 can be 1. Of course, character 1 and character 2 can also be other characters, and this application does not limit them. For ease of description, this application uses character 1 being 0 and character 2 being 1 as an example.

[0124] The value of the Scene Mode field can be an identifier for the scene mode. For example, the identifier for owner mode is 0, and the identifier for visitor mode is 1.

[0125] The value of the operation mode information field can be character 3, character 4, character 5, or character 6. Character 3 indicates that operation is allowed, character 4 indicates that operation is prohibited, character 5 indicates that operation is allowed after successful authentication, and character 6 indicates that operation is allowed after user confirmation. Characters 3, 4, 5, and 6 are different. For example, character 3 is 0, character 4 is 1, character 5 is 2, and character 6 is 3. Of course, characters 3, 4, 5, and 6 can also be other characters, and this application does not limit them. For ease of description, this application uses character 3 as 0, character 4 as 1, character 5 as 2, and character 6 as 3 as an example.

[0126] Optionally, the type of the above-mentioned operation mode information can be int. The type of attribute label can be int. The type of scene mode can also be int. Of course, the types of operation mode information and application identifier can also be other types, and this application does not limit them.

[0127] In this embodiment, scene modes are associated with application policies, allowing users to set application policies for different scene modes according to their needs, thus achieving personalized application policy settings. Afterwards, when the phone enters a certain scene mode, the application policy corresponding to that scene mode takes effect. Therefore, when an application needs to be run, the phone can determine whether to run the application based on the application policy corresponding to that scene mode, ensuring phone security and enabling flexible application operation to meet user needs.

[0128] Furthermore, considering that application attributes are subject to change rather than remaining constant, to avoid the impact of attribute changes on application strategies, application strategies are associated with application attributes rather than with specific application identifiers. This ensures that even if an application's attributes change, the phone's application strategies do not need to be updated. Moreover, users can flexibly combine application strategies (i.e., operating methods) with attributes according to their needs, providing strong scalability and meeting the personalized needs of different users.

[0129] In some embodiments, the application policy setting process described in S201-S204 above may be performed by the policy management module within the attribute access control module (e.g., ...). Figure 6 (As shown). In addition, this application also relates to the process of setting application attribute tags, which will be described below.

[0130] S205. When the risk perception service detects that application 1 is a risky application, it sends the identifier of application 1 to the attribute access control module.

[0131] For example, the risk awareness service can detect risky applications. After detecting a risky application (such as application 1 mentioned above), the risk awareness service can send the identifier of the detected risky application (such as the application's package name) to the attribute access control module to trigger the attribute access control module to update the application's attributes.

[0132] Among them, risky apps are those that may cause security problems on the phone, such as apps from unknown sources or apps that carry viruses.

[0133] In some embodiments, the risk perception service can perceive risky applications in real time, periodically, during idle time, or when the mobile phone is in a specific state (such as a black screen state).

[0134] S206. The attribute access control module updates database 2 based on the identifier of application 1, resulting in an updated database 2. The attribute label of the identifier of application 1 in the updated database 2 is a risk label.

[0135] In some embodiments, the attribute access control module has attribute management functions. These attribute management functions may include at least the application's risk label setting (set) function, risk label querying (get) function, and risk label clearing (clear) function.

[0136] The Risk Tag Setting function sets an application's attribute tag to a risk tag. The Risk Tag Query function queries applications with a risk tag. The Attribute Tag Update function updates an application's attribute tag. The Risk Tag Removal function removes an application's risk tag, effectively changing its attribute tag from risky to safe.

[0137] For example, the attribute access control module can add the identifier of application 1 and the attribute tag of application 1 (i.e., the attribute tag of the identifier of application 1) to table 2 of database 2. Table 2 (e.g., the AppSecurityAttribute table) is used to store the application's attribute tags. Table 2 includes at least two fields: the application's identifier (app_name) and the attribute tag (security_attribute).

[0138] Optionally, the type of the application identifier mentioned above can be string. Of course, the type of the application identifier can also be other types, and this application does not limit it.

[0139] The aforementioned database 2 and database 1 may be the same database or different databases; this application does not limit them.

[0140] In some embodiments, if the mobile phone does not detect any risk in application 1 after installation, it can set the attribute label of application 1 to a safe label. Later, after using application 1 for a period of time, if the mobile phone detects a risk in application 1 and determines that application 1 is a risky application, it can update the attribute label of application 1 from a safe label to a risky label. For example, as shown in Table 1, com.bXXX is the identifier of application 1, and the attribute label of application 1 is 0, which is a safe label. After detecting that application 1 is a risky application, the mobile phone's risk awareness service notifies the mobile phone's attribute access control module to update the attribute label of application 1 to a risky label, and the attribute label of application 1 becomes 1 (as shown in Table 2).

[0141] Table 1

[0142] app_name security_attribute com.aXXX 0 com.bXXX 0

[0143] Table 2

[0144] app_name security_attribute com.aXXX 0 com.bXXX 1

[0145] Alternatively, the initial attribute label of application 1 may not be a security label, but a risk label. For example, if the phone detects that application 1 is a risky application after it is installed, the initial attribute label of application 1 can be set to a risk label.

[0146] S207. The attribute access control module sends the tag setting result to the risk perception service. The tag setting result indicates that the tag setting was successful.

[0147] In this embodiment, after the attribute access control module successfully sets the attribute label of application 1 as a risk label, it can return the label setting result indicating successful label setting to the aforementioned risk awareness service, so that the risk awareness service knows that application 1 has been successfully set as a risk application. Alternatively, there is a possibility that the risk label setting of application 1 may fail; that is, the aforementioned label setting result may also indicate label setting failure. Accordingly, upon receiving a label setting result indicating label setting failure, the risk awareness service, in response to this result, can immediately or after a certain period of time, send the identifier of application 1 to the attribute access control module again, triggering the attribute access control module to retry setting the attribute label of application 1 as a risk label, thus ensuring the success of the attribute label setting.

[0148] In some embodiments, S207 above is an optional step, that is, regardless of whether the attribute access control module successfully sets the attribute label of application 1 as a risk label, the mobile phone does not need to send the label setting result to the risk perception service through the attribute access control module.

[0149] It should be noted that the application strategy setting process described in S201-S204 can be executed before, after, or simultaneously with the attribute tag setting process described in S205-S207. This application does not impose any restrictions on the order of execution of the two. In general, the step numbers in the embodiments of this application do not represent the order of execution of the steps.

[0150] In some embodiments, the process of setting the attribute labels of the application described in S205-S207 above can be performed by the attribute management module in the attribute access control module (as described above). Figure 6 (As shown). Of course, it can also be executed by other modules in the attribute access control module, and this application does not restrict it.

[0151] The preceding text introduced the process of risk application detection and application policy setting. When an application on a mobile phone needs to run, the phone (such as the attribute access control module on the phone) can determine the corresponding application policy, which is then used to determine whether to run the application, thus implementing the application policy. The following section will continue to describe how the phone utilizes application policies during application execution.

[0152] S208, Activity Manager receives the user's launch operation for application 2.

[0153] For example, taking application 2 (or alternatively described as the first application) as the first game application, the user's launch operation on application 2 can be as described above. Figure 1A The click operation of the first game application icon 10 is shown.

[0154] Application 2 can be the same application as Application 1, or it can be a different application. It is understood that when Application 2 and Application 1 are different applications, the process of setting the attribute tags for Application 2 is similar to the process of setting the attribute tags for Application 1.

[0155] S209. In response to the launch operation of application 2, the Activity Manager sends request 1 to the Attribute Access Control Module. Request 1 includes the identifier of application 2.

[0156] Request 1 is used to trigger the attribute access control module to decide whether to run application 2.

[0157] S210. The attribute access control module, based on the identifier of application 2, queries the database 2 to find that the attribute tag of application 2 is a risk tag, and determines that the current scenario mode is scenario mode 2.

[0158] In this embodiment, the attribute access control module has a decision-making function. When application 2 needs to be launched, the attribute access control module can first determine whether application 2 is a risky application, thereby determining whether application 2 can be launched. For example, the attribute access control module can query the attribute tags identifying application 2 from database 2 through the attribute management module. If the attribute access control module determines that the attribute tag is a risk tag, it determines that application 2 is a risky application, and then uses the application policy corresponding to the risky application to determine whether application 2 can run.

[0159] S211. The attribute access control module queries the database 1 for the target application strategy corresponding to the risk label and scenario mode 2.

[0160] For example, the attribute access control module can look up the application strategy where the attribute label is a risk label and the scenario mode is scenario mode 2 from data table 1 in database 1 (as shown in Table 3 below), and use it as the target application strategy.

[0161] Table 3

[0162]

[0163]

[0164] It is understandable that each row in Table 3 indicates an application policy. For example, the application policy indicated in the second row means that in scenario mode with a flag of 0, the phone can directly run secure applications (i.e., applications with a secure attribute label). As another example, the application policy indicated in the third row means that in scenario mode with a flag of 1, the phone can run risky applications (i.e., applications with a risky attribute label) after successful authentication. As yet another example, in scenario mode with a flag of 0, the phone can directly prohibit the running of risky applications. And as yet another example, in scenario mode with a flag of 2, the phone can directly run risky applications after user confirmation.

[0165] S212. If the running mode information in the target application policy indicates that running is prohibited, the attribute access control module sends the prohibition result to the activity manager.

[0166] The "disable running" result is used to trigger the Activity Manager to prevent application 2 from starting, thus avoiding any impact on the phone's security from the operation of application 2.

[0167] S213. In response to the result of the ban, Activity Manager stops launching application 2 and displays a message indicating that the risky application is prohibited from running.

[0168] For example, the aforementioned warning message about the prohibited operation of risky applications can be displayed via a pop-up window.

[0169] The above sections S212-S213 describe the scenarios where the target application policy indicates that execution is prohibited (i.e., the target application policy indicates that execution is prohibited). The following sections, in conjunction with S214-S227, will further describe the scenarios where the target application policy indicates execution. Specifically, S214-S215 describe the scenarios where execution is permitted, S216-S220 describe the scenarios where execution occurs after successful authentication, and S221-S227 describe the scenarios where execution occurs after user confirmation (i.e., execution after confirmation).

[0170] S214. If the execution mode information in the target application policy indicates that execution is allowed, the attribute access control module sends the execution result to the activity manager.

[0171] The execution result is used to trigger the Activity Manager to launch application 2 normally, so as to avoid the user being unable to use application 2 due to the prohibition of application 2 running, and to ensure the user experience.

[0172] S215. Activity Manager responds to the running results and launches application 2.

[0173] In this embodiment of the application, when the target application policy indicates that it is allowed to run, the mobile phone can directly run application 2 to meet the user's need to use risky applications in the current scenario mode, and avoid application 2 being unable to run due to incorrect identification of its attributes.

[0174] S216. If the target application strategy indicates that the operation mode information is valid after successful authentication, the attribute access control module performs authentication and obtains the authentication result.

[0175] The authentication result indicates whether authentication was successful or failed. For example, the attribute access control module receives the user's input identity information. Then, the attribute access control module determines whether this identity information matches the target user's identity information corresponding to the current scenario mode, thus obtaining the authentication result. For instance, if the current scenario mode is the owner mode, the target user corresponding to the current scenario mode is the owner.

[0176] If the system determines that the user's input identity information matches the target user information corresponding to the current scenario mode, it indicates that the current user is the target user for the current scenario mode, and the attribute access control module can determine the authentication result to indicate successful authentication. If the system determines that the user's input identity information does not match the target user identity information corresponding to the current scenario mode, it indicates that the current user is not the target user for the current scenario mode, and the attribute access control module can determine the authentication result to indicate authentication failure.

[0177] In some embodiments, the attribute access control module can display an authentication interface. The attribute access control module then receives the identity information entered by the user on the authentication interface for use in authentication. For example, if the authentication method is facial recognition, the authentication interface can be a facial recognition interface, and the corresponding identity information can be a facial image captured by a mobile phone. It should be understood that facial recognition is only one possible implementation of authentication; the attribute access control module can also perform authentication through other methods, such as behavioral, password, or fingerprint authentication.

[0178] S217. If the authentication result indicates successful authentication, the attribute access control module sends the running result to the activity manager.

[0179] S218. Activity Manager responds to the running results and launches application 2.

[0180] S219. If the authentication result indicates that the authentication failed, the attribute access control module sends a prohibition result to the activity manager.

[0181] S220, In response to the result of the prohibition, Activity Manager stops launching application 2 and displays a warning message indicating that the risky application is prohibited from running.

[0182] In this embodiment of the application, when the target application policy indicates that the first application should run after successful authentication, the mobile phone determines whether to continue running the first application based on the authentication result, thereby enabling flexible operation of the application, meeting the user's need to use risky applications in the current scenario mode, and ensuring the security of the electronic device to a certain extent.

[0183] S221. When the target application strategy indicates that the application should be run only after user confirmation, the attribute access control module displays a risky application running prompt.

[0184] Among them, the aforementioned risk application operation prompt information (or confirmation prompt information) is used to prompt the user whether to continue running the risky application 2.

[0185] S222, The attribute access control module receives confirmation input from the user.

[0186] The confirmation action is used to trigger the phone to continue running application 2. For example, the phone (such as the phone's property access control module) displays a confirmation control and a cancel control. Upon receiving a user's click on the confirmation control, the property access control module indicates that it has received the user's confirmation input.

[0187] S223. In response to the confirmation operation, the attribute access control module sends the running result to the activity manager.

[0188] S224. Activity Manager responds to the running results and launches application 2.

[0189] S225, The attribute access control module receives user input for a rejection operation.

[0190] For example, a rejection operation could be a user clicking the cancel control mentioned above.

[0191] S226. In response to the denial operation, the attribute access control module sends a prohibition result to the activity manager.

[0192] S227. In response to the result of the ban, Activity Manager stops launching application 2 and displays a message indicating that the risky application is prohibited from running.

[0193] In this embodiment, considering the possibility of misidentification or omission of application attributes, for example, the phone's risk perception service might identify an application as risky because it cannot confirm the safety of the application's installation source, even if the user confirms that the application's safe source is safe, leading to an incorrect attribute identification. To avoid this situation causing the phone to malfunction and the risky application, in scenario mode 2, if the phone needs to run a risky application, it can output a risky application running prompt to confirm with the user whether to continue running the risky application, thus ensuring that the risky application still has the possibility of normal use and improving the user experience.

[0194] In some embodiments, the operations performed by the attribute access control module in S209-S227 above may be performed by the decision module in the attribute access control module.

[0195] In some embodiments, the interaction between the modules or services described above is actually a mutual invocation between modules or services. For example, the risk perception service sending the identifier of application 1 to the attribute access control module to trigger the attribute access control module to set the attribute label of the identifier of application 1 to a risk label can actually be the risk perception service invoking the attribute access control module to set the attribute label of the identifier of application 1 to a risk label.

[0196] It should be noted that the user's launch operation of application 2 described above is only one possible example of the first operation that triggers the launch of application 2. This first operation can also be other types of operations. For example, if the user performs a specific operation on application 3, the phone will respond to the specific operation and need to jump from application 3 to application 2. Therefore, application 2 needs to be launched.

[0197] In this embodiment, users can set application policies corresponding to different scenario modes according to their needs. Application policies in different scenario modes do not affect each other. Once a scenario mode is entered, the application policy corresponding to that scenario mode takes effect. When the phone launches an application, it queries the application policy corresponding to that scenario mode for a target application policy that matches the application's attribute tags. This target application policy is used to determine whether application 2 can launch normally, ensuring the security of application operation and thus the security of the phone. Furthermore, the application policy is flexible and meets personalized needs. Additionally, this application utilizes an attribute access control module, an activity manager, and a risk awareness service (such as...) Figure 8 (As shown) It enables the identification of risky applications, management of application policies, management of attribute tags, and decision-making on whether to run applications, instead of making application running decisions through Linux Kernel modules.

[0198] In this embodiment, for the same attribute tag, the application strategy corresponding to that attribute tag can be different in different scenario modes, making the operation more refined and flexible, thereby meeting the user's usage needs in different scenario modes. For example, in a first scenario mode, the mobile phone receives a first operation, which triggers the mobile phone to launch a first application. Then, in response to the first operation, the mobile phone, through the attribute access control module, determines a first target application strategy corresponding to the first scenario mode and the attribute tag of the first application. The attribute tag of the first application can be a risk tag. If the first target application strategy indicates that operation is prohibited (i.e., the operation mode information in the first target application strategy indicates that access is prohibited), the mobile phone stops launching the first application. In a second scenario mode, the mobile phone receives the first operation. Then, in response to the first operation, the mobile phone, through the attribute access control module, determines a second target application strategy corresponding to the second scenario mode and the attribute tag of the first application. If the second target application strategy indicates that operation is permitted, the mobile phone continues to launch the first application.

[0199] Optionally, the above-mentioned operation can refer to the operation as described above, operation after identity authentication, or operation after user confirmation.

[0200] In some embodiments, the attribute tags and application strategies described in this application can also be applied to other app-related scenarios, such as app installation, uninstallation, and hiding. After receiving a relevant request from the user, the mobile phone triggers the phone to perform operations such as installing, uninstalling, or hiding the app. In response to this request, the mobile phone can determine the corresponding strategy based on the app's attribute tags through the attribute control access module, and use this strategy to decide whether to perform the operation. The attribute tags can be automatically identified and set by the mobile phone or set by the user.

[0201] In some embodiments, the process described above for determining whether a subject object can access a subject resource based on the attributes of that subject resource is described above. The attribute access control module can also determine whether a subject object can access a subject resource based on the attributes of that subject object. In simpler terms, the database 1 described above (such as data table 1 described above) can also include the attributes of the subject object. Correspondingly, when a subject object accesses application 3, such as when application 3 is running, the attribute access control module can search the database 1 for a target application policy that matches the attributes of the subject object, the current scene mode, and the attribute tags of the application, so as to determine whether to run application 3 using the target application policy.

[0202] Taking an application as the primary object as an example, the application's attributes can include at least one of the following: application type, installation source, security attributes, and age-appropriateness. Taking a user as the primary object as an example, the user's attributes can include the user's identity.

[0203] The types to which the above applications belong, that is, the categories of applications, can include one or more of the following: office, education, payment, shopping, sports, travel, audio and video, games, and social networking.

[0204] The installation sources mentioned above can include one or more of system applications, app stores, and non-app stores. Specifically, when the installation source of an application on an electronic device is a system application, the application is pre-installed on the electronic device; for example, the application can be installed within the electronic device's operating system.

[0205] When an application on an electronic device is installed from an app store, it is a third-party application; the application was installed from the app store's app section. When an application on an electronic device is installed from a source other than an app store, it is also a third-party application; the application was not installed from the app store's app section, but rather from a browser application.

[0206] The security attributes mentioned above indicate whether an application is a risky application. Security attributes can include both risky and normal attributes. Specifically, risky attributes indicate that the application is a risky application, while normal attributes indicate that the application is a safe application.

[0207] The above applicable age indicates the age required for users to use the application. For example, the applicable age for the application is 6 years old, 18 years old, etc.

[0208] It should be noted that the operations performed by modules or applications on the mobile phone described above are merely examples. These operations can also be performed by other modules or applications, and this application does not impose any restrictions on the subject performing the operation. Furthermore, the operations performed by modules or applications on the mobile phone are actually performed by the mobile phone itself; that is, the subject performing the operations described above can all be the mobile phone.

[0209] In some embodiments, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the application execution method described above.

[0210] In some embodiments, this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the application running method described above.

[0211] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0212] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0213] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0214] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0215] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0216] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An application running method, characterized in that, Applied to electronic devices, the method includes: Receive a first operation; wherein the first operation is used to trigger the electronic device to launch a first application; In response to the first operation, when the electronic device is in a first scene mode, the attribute access control module determines a first target application strategy corresponding to the attribute tag of the first application and the information of the first scene mode; wherein, the attribute tag of the first application is a risk tag. If the first target application policy indicates that it is prohibited from running, stop starting the first application; In response to the second user input, switch to the second scene mode; Receive the first operation; In response to the first operation, the attribute access control module determines the second target application strategy corresponding to the attribute tags of the first application and the information of the second scene mode. When the second target application policy instructs to run, the first application is launched.

2. The method according to claim 1, characterized in that, The second target application policy instruction indicates that the application will run after successful authentication. When the second target application policy instructs to run, launching the first application includes: If the second target application strategy indicates that identity authentication has been successfully performed, identity authentication is performed to obtain an identity authentication result; wherein, the identity authentication result indicates whether the user currently using the electronic device is the target user corresponding to the second scenario mode; If the authentication result indicates successful authentication, the first application is launched.

3. The method according to claim 1, characterized in that, The second target application strategy indicates that the program will run after confirmation; The step of launching the first application when the second target application policy indicates that it can run, and launching the first application when the second target application policy indicates that it can run, includes: If the application is run after confirmation of the second target application strategy, a confirmation prompt message is output; wherein, the confirmation prompt message is used to prompt whether to run the first application; Receive confirmation input from the user; In response to the confirmation operation, the first application is launched.

4. The method according to claim 1, characterized in that, The second target application policy indicates that operation is allowed; if the second target application policy indicates that operation is allowed, the first application is launched.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The attribute access control module obtains application policy settings information input by the user; wherein, the application policy settings information includes at least a mapping relationship between attribute tags and running mode information; the attribute tags are risk tags, and the running mode information indicates that running is prohibited; The attribute access control module determines a first target application policy, including the application policy setting information and the first scene mode in which the electronic device is located. The attribute access control module saves the first target application policy.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: If the risk perception service detects that the first application has a risk, the identifier of the first application is sent to the attribute access control module. The attribute access control module sets the attribute tags of the first application as risk tags based on the identifier of the first application.

7. The method according to any one of claims 1 to 4, characterized in that, Before determining the first target application strategy corresponding to the attribute tags and the first scene mode information of the first application through the attribute access control module, the method further includes: The activity manager sends the identifier of the first application to the attribute access control module. Based on the identifier of the first application, the attribute access control module determines that the attribute tag of the first application is a risk tag. The step of stopping the startup of the first application when the first target application policy indicates that it is prohibited from running includes: If the first target application policy indicates that operation is prohibited, the attribute access control module sends the prohibition result to the activity manager. In response to the prohibition result, the first application is stopped from starting via the Activity Manager.

8. An electronic device, characterized in that, The electronic device includes a memory and one or more processors; the memory and the processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images