CN117932589A - Authority management method and related device - Google Patents

Abstract

The permission management method and related device provided by the embodiment of the present application relate to the field of terminal technology. The method includes: the system can judge the status of the implicitly authorized permission applied for by the application. If the implicitly authorized permission is in an unauthorized state, and the targetSDK version of the application is within a preset version range, the system can perform a secondary authorization for the implicitly authorized permission applied for by the application. In this way, the implicitly authorized permission applied for by the application can be authorized, so that the application can run normally.

Description

Rights management method and related device

Technical Field

The present application relates to the field of terminal technology, and in particular to a rights management method and related devices.

Background technique

An electronic device may include multiple applications. In some scenarios, an application may access data in an external storage of the electronic device or media files of other applications. For example, an application may access pictures and videos in a gallery.

However, in some scenarios, the application may not be able to access the pictures and videos in the gallery.

Summary of the invention

The permission management method and related devices provided in the embodiments of the present application can determine the status of the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission applied for by the application. If the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission is unauthorized, and the targetSDK version of the application is between Android system version 6 and Android system version 12, the system can perform secondary authorization for the application. In this way, when the application accesses the external storage of the electronic device to read data, the system can determine that the application is granted READ_MEDIA_IMAGES permission, etc., and then allow the application to access the data in the storage.

In a first aspect, the method for rights management provided by the embodiment of the present application includes:

In response to the system version of the electronic device being upgraded from the first system version to the second system version, the first permission of the first application is set to an unauthorized state, wherein the application version of the first application is the first application version, in the first application version, the first application applies for a first permission, the first system version does not define the first permission, and the second system version defines the first permission; when the system version of the electronic device is the second system version, in response to the application version of the first application being upgraded from the first application version to the second application version, the first permission of the first application is set to an authorized state. In this way, when the first application accesses the external storage of the electronic device to read data, the system can determine that the application is granted the first permission, and then can allow the application to access the data in the storage.

In a possible implementation, the second application version is a software development kit SDK version within a preset version range. In this way, when the first application accesses data in the external storage of the electronic device, it can be determined that the first application is granted the first permission, so that the operation of the application is not affected, and the first application can normally access the data in the storage, thereby improving the user experience.

In a possible implementation, a preset list is stored in the electronic device, and the preset list includes the first permission. Before setting the first permission of the first application to the authorized state, it also includes: determining whether the first application has applied for the permission in the preset list; setting the first permission of the first application to the authorized state, including: if the first application has applied for the first permission in the preset list, setting the first permission of the first application to the authorized state. In this way, when the first application accesses data in the external storage of the electronic device, the system will check the implicit storage permission. If the system determines that the first application is granted the implicit storage permission, the first application can access the data in the storage, so that the first application can operate normally.

In a possible implementation, the method further includes: the first application requests to access the data of the second application; when the application version of the first application is the second application version, the first permission of the first application is verified; when the first permission is in an authorized state, the first application accesses the data of the second application. In this way, the security of data access between applications is improved, so that the data of the second application can be better protected and the user experience can be improved.

In a possible implementation, the first application also applies for the second permission in both the first application version and the second application version, and the method further includes: the first application requests to access the data of the second application; when the application version of the first application is the first application version, the second permission of the first application is verified; when the second permission is in the authorized state, the first application accesses the data of the second application. In this way, the security of data access between applications is improved, so that the data of the second application can be better protected and the user experience can be improved.

In a possible implementation, the first permission includes one or more of the following: READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, or READ_MEDIA_VIDEO permission, and the second permission includes: READ_EXTERNAL_STORAGE permission. In this way, the electronic device can better control the security of data access between applications by controlling the authorization status of the first permission and/or the second permission, and reasonably open the first permission and/or the second permission for the first application, so that the first application can run normally.

In a second aspect, an embodiment of the present application provides a device for rights management, which may be an electronic device, or a chip or chip system in an electronic device. The device may include a processing unit. The processing unit is used to implement any method related to processing performed by the electronic device in the first aspect or any possible implementation of the first aspect. When the device is an electronic device, the processing unit may be a processor. The device may also include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit so that the electronic device implements the method described in the first aspect or any possible implementation of the first aspect. When the device is a chip or chip system in an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit so that the electronic device implements the method described in the first aspect or any possible implementation of the first aspect. The storage unit may be a storage unit in the chip (for example, a register, a cache, etc.), or a storage unit in the electronic device located outside the chip (for example, a read-only memory, a random access memory, etc.).

Exemplarily, a processing unit is used to set the first permission of the first application to an unauthorized state in response to the system version of the electronic device being upgraded from a first system version to a second system version; and is also used to set the first permission of the first application to an authorized state in response to the application version of the first application being upgraded from a first application version to a second application version.

In a possible implementation, the second application version is a software development kit SDK version within a preset version range.

In a possible implementation, the processing unit is used to determine whether the first application has applied for a permission in a preset list, and is further used to set the first permission of the first application to an authorized state if the first application has applied for the first permission in the preset list.

In one possible implementation, the processing unit is used to request access to data of a second application; is also used to verify the first permission of the first application; and is specifically used to access the data of the second application when the first permission is in an authorized state.

In one possible implementation, the processing unit is used to request access to data of the second application; and is also used to verify the second permission of the first application; and is specifically used to allow the first application to access data of the second application when the second permission is in an authorized state.

In a possible implementation, the first permission includes one or more of the following: READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, or READ_MEDIA_VIDEO permission, and the second permission includes: READ_EXTERNAL_STORAGE permission.

In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a memory, the memory being used to store code instructions, and the processor being used to run the code instructions to execute the method described in the first aspect or any possible implementation of the first aspect.

In a fourth aspect, the present application provides a chip or a chip system, the chip or chip system comprising at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and the at least one processor is used to run a computer program or instruction to execute the method described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input/output interface, a pin or a circuit, etc.

In a possible implementation, the chip or chip system described above in the present application further includes at least one memory, in which instructions are stored. The memory may be a storage unit inside the chip, such as a register, a cache, etc., or a storage unit of the chip (e.g., a read-only memory, a random access memory, etc.).

In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program or instructions are stored. When the computer program or instructions are run on a computer, the computer executes the method described in the first aspect or any possible implementation of the first aspect.

In a sixth aspect, an embodiment of the present application provides a computer program product comprising a computer program, which, when the computer program runs on a computer, enables the computer to execute the method described in the first aspect or any possible implementation manner of the first aspect.

It should be understood that the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of an application storage permission and its granting status change provided by an embodiment of the present application;

FIG2 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

FIG3 is a schematic diagram of a software structure of an electronic device provided in an embodiment of the present application;

FIG4 is a flow chart of a method for managing permissions provided in an embodiment of the present application;

FIG5 is a schematic diagram of a permission management method provided in an embodiment of the present application;

FIG6 is a schematic diagram of the structure of a chip provided in an embodiment of the present application.

Detailed ways

In order to clearly describe the technical solutions of the embodiments of the present application, some terms and technologies involved in the embodiments of the present application are briefly introduced below:

1. Storage permissions:

(1.1) READ_EXTERNAL_STORAGE permission: This permission allows an application to read data from the external storage of an electronic device. For example, the data may include pictures, audio, video, files, etc.

(1.2) READ_MEDIA_IMAGES permission: This permission allows the application to read image files from the external storage of the electronic device. For example, image files may include pictures, etc.

(1.3) READ_MEDIA_AUDIO permission: This permission allows the application to read audio files from the external storage of the electronic device. For example, audio files may include recordings, voice, etc.

(1.4)READ_MEDIA_VIDEO permission: This permission allows the application to read video files from the external storage of the electronic device.

2. targetSDK version: The target version of the software development kit (SDK), also known as targetSdkVersion. The targetSDK version can be understood as the application programming interface (API) level corresponding to the application runtime. The application can set the targetSdkVersion to a certain API level according to its own business needs.

It is understandable that different Android system versions can have corresponding API levels, for example, Android system version 13 corresponds to API level 33, Android system version 12 corresponds to API level 31 or 32, Android system version 11 corresponds to API level 30, Android system version 10 corresponds to API level 29, Android system version 6 corresponds to API level 23, and so on.

In some implementations, Android system version 13 may also be called version T, Android system version 12 may also be called version S, and Android system version 6 may also be called version M.

3. Terminology

In the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same functions and effects. For example, the first chip and the second chip are only used to distinguish different chips, and their order is not limited. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

In the embodiments of the present application, "at least one" refers to one or more, and "plurality" refers to two or more. "And/or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character "/" generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers 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, a-b, a--c, b-c, or a-b-c, where a, b, c can be single or multiple.

4. Electronic equipment

The electronic device of the embodiment of the present application may also be a terminal device in any form. For example, the electronic device may include: a mobile phone, a tablet computer, a PDA, a laptop computer, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, a vehicle-mounted device, a wearable device, an electronic device in a 5G network or a public land mobile communication network (public land mobile communication network) to be evolved in the future. Mobile network, PLMN) and the like, the embodiments of the present application are not limited to this.

As an example but not limitation, in the embodiments of the present application, the electronic device may also be a wearable device. Wearable devices may also be referred to as wearable smart devices, which are a general term for wearable devices that are intelligently designed and developed using wearable technology for daily wear, such as glasses, gloves, watches, clothing, and shoes. A wearable device is a portable device that is worn directly on the body or integrated into the user's clothes or accessories. Wearable devices are not only hardware devices, but also powerful functions achieved through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include full-featured, large-sized, and fully or partially independent of smartphones, such as smart watches or smart glasses, as well as devices that only focus on a certain type of application function and need to be used in conjunction with other devices such as smartphones, such as various types of smart bracelets and smart jewelry for vital sign monitoring.

In addition, in the embodiments of the present application, the electronic device may also be an electronic device in an Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network that interconnects people and machines and things.

The electronic device in the embodiments of the present application may also be referred to as: user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, etc.

In an embodiment of the present application, the electronic device or each network device includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and a memory (also called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux operating system, Unix operating system, Android operating system, iOS operating system, or Windows operating system. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

An electronic device may include multiple applications. In some scenarios, an application may access data in the external storage of the electronic device or media files of other applications. For example, an application may access pictures and videos in a gallery.

For example, if an application can access pictures and videos in the gallery, the application needs to apply for the READ_EXTERNAL_STORAGE permission before accessing the gallery. If the system grants the application the READ_EXTERNAL_STORAGE permission, the application can access pictures and videos in the gallery.

In one possible scenario, the READ_EXTERNAL_STORAGE permission is invalid starting from Android version 13. The API level corresponding to Android version 13 is 33, that is, if the application uses 33 as the target SDK version, when the application wants to read data from the external storage of the electronic device or access the media files of other applications, the application no longer needs to apply for the READ_EXTERNAL_STORAGE permission, but needs to apply for one or more of the following permissions: READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, or READ_MEDIA_VIDEO permission.

However, if the targetSDK version of the application is lower than Android system version 13, the application may not be able to access data in the external storage of the electronic device or media files of other applications.

As shown in Figure 1, taking the application accessing the gallery as an example, the changes in storage permissions and their granting status in different operating system (OS) versions and different targetSDK versions of the application are explained. In the embodiment of the present application, the OS version can also be understood as the Android system version or ROM version.

(1) Case 1: Android system version 13 or below, targetSDK version 30 or below.

Taking Android system version 12 and the application's targetSDK version 29 as an example, if the application wants to access the gallery, the application needs to apply for the READ_EXTERNAL_STORAGE permission.

In some scenarios, in addition to applying for the READ_EXTERNAL_STORAGE permission, an application will also pre-apply for the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and/or READ_MEDIA_VIDEO permission. For the sake of convenience, the application that does not pre-apply for the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and/or READ_MEDIA_VIDEO permission will be referred to as application A, and the application that pre-applies for the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and/or READ_MEDIA_VIDEO permission will be referred to as application B.

However, in the Android 12 version, the system does not define the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission, so the system does not check the authorization status of these three permissions. Among them, permissions that are not defined in the system can be called free permissions. When application A or application B accesses the gallery, the system will check the READ_EXTERNAL_STORAGE permission of application A or application B, but will not check the free permissions.

If the system determines that application A or application B is granted the READ_EXTERNAL_STORAGE permission, application A or application B can be allowed to access pictures, videos and other content in the gallery.

If the system determines that application A or application B is not granted the READ_EXTERNAL_STORAGE permission, application A or application B is not allowed to access pictures, videos and other content in the gallery.

(2) Case 2: Android system version 13 or above, targetSDK version 30 or below.

When the system is upgraded to Android version 13, the system defines the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and READ_MEDIA_VIDEO permission.

It is understandable that the APIs corresponding to different Android system versions may change. For forward compatibility, that is, for compatibility with previous versions, if the targetSDK version set by the application is lower, even if there is a higher API level on the Android system, the Android system will still use the API level corresponding to the lower targetSDK version set by the application.

For example, if the targetSDK version set by the application corresponds to API level 32, and there is a higher API level on the Android system, such as API level 33, the Android system will still use the API level set by the application, that is, API level 32.

Therefore, if the targetSDK version of an app is lower than 30, the system will still determine whether the app is granted the READ_EXTERNAL_STORAGE permission instead of the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission.

Since Android 13, the system defines the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and READ_MEDIA_VIDEO permission. However, some apps still use the READ_EXTERNAL_STORAGE permission.

For application A that has applied for the READ_EXTERNAL_STORAGE permission, the system can implicitly grant application A the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and the READ_MEDIA_VIDEO permission. The system can also record these implicit storage permissions as authorization status, for example, the authorization status can be marked as "YES". Among them, the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and the READ_MEDIA_VIDEO permission can also be called implicit storage permissions.

For application B, the system will not grant the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission to application B. In this case, the system will record these implicit storage permissions as unauthorized states, for example, the unauthorized state can be marked as "NO".

When an app accesses the gallery, since the targetSDK version of app A or app B is below 30, the system will check the READ_EXTERNAL_STORAGE permission of app A or app B, but will not check the READ_MEDIA_IMAGES permission of app A or app B. In other words, if an app is not granted the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission, the app can still access the gallery through the READ_EXTERNAL_STORAGE permission.

If the system determines that application A or application B is granted the READ_EXTERNAL_STORAGE permission, application A or application B can be allowed to access pictures, videos and other content in the gallery.

If the system determines that application A or application B is not granted the READ_EXTERNAL_STORAGE permission, application A or application B is not allowed to access pictures, videos and other content in the gallery.

(3) Case 3: Android system version 13, targetSDK version 30-32.

If the target SDK version of your app is 30, 31, or 32, the system checks your app's READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and/or READ_MEDIA_VIDEO permission.

For application A, the system may implicitly grant the application the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission, and record these implicitly granted permissions as the authorization status.

For application B, the system does not grant the application READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and/or READ_MEDIA_VIDEO permission. In this case, the system records these implicitly authorized permissions as unauthorized.

When an app accesses the gallery, the system checks the app's READ_MEDIA_IMAGES permission.

If the system determines that application A or application B is granted the READ_MEDIA_IMAGES permission, application A or application B can be allowed to access pictures, videos and other content in the gallery.

If the system determines that application A or application B is not granted the READ_MEDIA_IMAGES permission, application A or application B is not allowed to access pictures, videos and other content in the gallery.

In view of this, the permission management method provided in the embodiment of the present application can determine the status of the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission applied for by the application. If the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission is unauthorized, and the targetSDK version of the application is between Android system version 6 and Android system version 12, the system can perform secondary authorization for the application. In this way, when the application accesses the external storage of the electronic device to read data, the system can determine that the application is granted READ_MEDIA_IMAGES permission, etc., and then allow the application to access the data in the storage.

Exemplarily, FIG2 shows a schematic structural diagram of an electronic device.

The electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The illustrated components may be implemented by hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and/or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated into one or more processors. The controller may generate an operation control signal according to the instruction opcode and the timing signal to complete the control of fetching and executing instructions.

The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation of the electronic device. In other embodiments of the present application, the electronic device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

The internal memory 121 can be used to store computer executable program codes, and the executable program codes include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, at least one application required for a function, etc. The data storage area may store data created during the use of the electronic device, etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in the internal memory 121 and/or instructions stored in a memory provided in the processor.

The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the electronic device may include 1 or N display screens 194, where N is a positive integer greater than 1. The electronic device implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. For example, in an embodiment of the present application, the display screen is used to display photos or videos in applications such as a gallery.

FIG3 is a software structure diagram of an electronic device of an embodiment of the present application. The layered architecture divides the software into several layers, each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers, from top to bottom, namely, the application layer, the application framework layer, the Android runtime (Android runtime) and the system library, and the kernel layer.

The application layer can also be called the application layer, and the application layer can include a series of application packages. As shown in Figure 3, the application package can include applications such as gallery, video, calendar, camera, game, memo, etc. Applications can include system applications and third-party applications.

The application framework layer can also be called the Framework layer. The Framework layer can provide APIs and programming frameworks for the application layer applications. The Framework layer can include some predefined functions.

As shown in FIG. 3 , the Framework layer may include a package manager service (PMS), a window manager, a resource manager, a content provider, a view system, and the like.

PMS can be responsible for installing, managing, and uninstalling applications on electronic devices. When an application is installed, PMS can identify all components of the application, such as activity components, service components, and broadcast components, and assign corresponding permissions to these components. PMS can also detect the running status of installed applications to ensure the integrity and security of the applications.

Android runtime includes core libraries and virtual machines. Android runtime is responsible for the control and management of the Android system.

The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

The application layer and the framework layer run in a virtual machine. The virtual machine executes the java files of the application layer and the framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection. For example, in the embodiment of the present application, the virtual machine can be used to verify the permissions applied for by the application, access applications such as the gallery, and upgrade the system version.

The system library can also be called the Native layer, which can include multiple functional modules, such as the media library, function library, and graphics processing library.

The kernel layer is the layer between hardware and software. The kernel layer may include display driver, camera driver, audio driver, battery driver, CPU driver, etc.

It should be noted that the embodiments of the present application are only illustrated using the Android system as an example. In other operating systems (such as Windows system, IOS system, etc.), as long as the functions implemented by each functional module are similar to those in the embodiments of the present application, the solutions of the present application can also be implemented.

FIG4 shows a flow chart of a rights management method.

S401. Application running in S version.

Exemplarily, the embodiment of the present application is described by taking an application running in version S as an example. Among them, version S can also be understood as version 12 of the Android system.

S402: The system records application permissions.

For applications running on Android system version 12, the system can record the status of storage permissions applied for by the application, such as the status of free permissions such as READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission.

S403, the application accesses the gallery.

S404: Verify the storage permission applied for by the application.

When an application accesses the gallery, the system can verify the storage permission applied by the application. The storage permission verified varies depending on the targetSDK version of the application. The specific process of verifying the storage permission applied by the application can refer to the relevant description in the embodiment corresponding to FIG. 3 above, which will not be repeated here.

S405: Verify whether it is successful.

If the storage permission check succeeds, the application can access the gallery, corresponding to step S406; if the storage permission check fails, the application will fail to access the gallery, corresponding to step S407.

It is understandable that when accessing the gallery, checking the storage permissions can improve the security of accessing the data in the gallery, thereby better protecting the data in the gallery and improving the user experience.

S406: The application can access the gallery.

S407: The application fails to access the gallery.

S408. The system is upgraded from version S to version T.

The T version can also be understood as Android system version 13. Upgrading the system from S version to T version can be understood as upgrading the system from Android system version 12 to Android system version 13.

When the system is upgraded from Android system version 12 to Android system version 13, step S409 can be executed.

In a possible implementation, when the system is upgraded to Android system version 13, the system can execute step S409 during the first upgrade and startup process to re-authorize the unauthorized READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission. Of course, the system can also perform the secondary authorization process at other times. For example, other times may include when the application is upgraded or in response to the user's consent to authorize the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission. The specific secondary authorization time is not limited in the embodiments of this application.

S409: The system authorizes the application to store permissions.

The package manager service (PMS) at the system Framework layer can be used to authorize storage permissions for applications.

S410: The system detects whether the application applies for implicit storage permission.

PMS can also be used to detect whether an application applies for implicit storage permissions.

If the application does not apply for the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission and/or the READ_MEDIA_VIDEO permission, step S411 may be executed.

If the application has applied for the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission and/or the READ_MEDIA_VIDEO permission, step S412 may be executed.

S411. Authorization.

The system can grant an application the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission.

S412, not authorized.

The system does not grant the app the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission.

It is understandable that the system may also execute step S413 to record the permissions granted to the application.

S413: Whether it is a hota upgrade scenario, the targetSDK version is between M and T, and whether it is an implicit storage permission.

Hota upgrade can also be called control download (over the air, OTA) upgrade, online upgrade or cloud upgrade. Hota upgrade can be used for system version upgrade of electronic equipment, and can also be understood as Android system version upgrade.

In a possible implementation, the system may call a related interface to determine whether the application needs to be upgraded to a hota version. For example, if the system detects that the cloud server includes a version higher than the current application version, a hota upgrade may be performed.

The system can determine whether a second authorization is required for the implicit storage permission. For example, if the system is a hota upgrade scenario, the targetSDK version is between Android system version 6 and Android system version 12, and it is an implicit storage permission, the system can perform a second authorization for the implicit storage permission during the hota upgrade process.

Among them, Android system version 6 can be understood as M version, and Android system version 12 can be understood as T version. The targetSDK version is between Android system version 6 and Android system version 12, which can also be understood as API level between 23 and 32. Implicit storage permissions can include READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and READ_MEDIA_VIDEO permission.

S414, hota upgrade.

In a possible implementation, the cloud server may include a higher version of the system upgrade package, and the system may call an interface for downloading the upgrade package to perform a hota upgrade. The specific hota upgrade method is not limited in the embodiment of the present application.

S415: traverse the system implicit authorization list, and authorize the permissions that the application has applied for implicit authorization.

It is understandable that an implicit authorization list may be created in the system, and the implicit authorization list may include one or more permissions that require implicit authorization, for example, permissions that require implicit authorization may include READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission, and/or READ_MEDIA_VIDEO permission, etc. The system may traverse the implicit authorization list, and if an application applies for one or more permissions that require implicit authorization in the implicit authorization list, the system may authorize the one or more permissions that require implicit authorization applied for by the application, and update the authorization status of each permission to the system.

In a possible implementation, the system can save the implicit authorization information of the application in a data structure such as a list or a map. The specific method of saving the information is not limited in the embodiment of the present application.

The system can re-authorize the implicit storage permission of the application if the implicit storage permission of the application is not authorized. In this way, when the application accesses the gallery, the system will check the READ_MEDIA_IMAGES permission. If the system determines that the application is granted the READ_MEDIA_IMAGES permission, the application can be allowed to access the pictures and other content in the gallery.

It is understandable that the above embodiment is explained by taking the application accessing the pictures, videos and other contents in the gallery as an example. The permission management method of the embodiment of the present application can also be applied to the scene where the application accesses the video application, the document application and the like, that is, it can be applied to the scene where the READ_MEDIA_IMAGES permission, the READ_MEDIA_AUDIO permission, and/or the READ_MEDIA_VIDEO permission need to be applied. In addition, the permission management method of the embodiment of the present application can also be applied to other scenes where the application permission changes with the change of the system version, and the embodiment of the present application is not limited.

The following is a detailed description of the method of the embodiment of the present application through specific embodiments. The following embodiments can be combined with each other or implemented independently, and the same or similar concepts or processes may not be repeated in some embodiments.

FIG5 shows a method for managing rights according to an embodiment of the present application. The method includes:

S501. In response to a system version of the electronic device being upgraded from a first system version to a second system version, setting a first permission of a first application to an unauthorized state, wherein the application version of the first application is a first application version, in the first application version, the first application applies for a first permission, the first system version does not define the first permission, and the second system version defines the first permission.

In the embodiment of the present application, the system version of the electronic device can be understood as the version of the operating system of the electronic device, and can also be understood as the Android system version or ROM version, which is not limited in the embodiment of the present application.

The first permission can be understood as a permission with different definitions on different system versions, or it can be understood as a free permission in the above embodiment. For example, the first permission can be the READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission in the embodiment corresponding to Figure 1 above. Exemplarily, in the Android system 13 version, READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission can be defined. In versions below Android system 13, READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission are not defined.

The first application may be any application in the electronic device, and the first application may be understood as an application applying for the first permission.

The first system version can be understood as a system version that does not define the first permission. For example, taking the first permission as READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission, the first system version can be understood as a version below Android system 13. For example, the first system version can include the S version.

The second system version can be understood as a system version that defines the first permission. For example, taking the first permission as READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission and/or READ_MEDIA_VIDEO permission, the second system version can be understood as the version of Android system 13. For example, the second system version can include version T.

The first application version can be understood as the targetSDK version, and the first application version can be included in versions below Android system 13, and the system of the electronic device does not need a version for the first permission check. It is understandable that the system version of the electronic device and the first application version may not correspond, and the first application version is smaller than the system version of the electronic device. At this time, in order to be forward compatible, the system may not check the first permission applied for by the first application in the first application version.

Exemplarily, in the embodiment corresponding to the above-mentioned Figure 3, in versions below Android system 13; for example, between Android system version 6 and Android system version 12, the first application version may include a version with a targetSDK version below 30.

S502: When the system version of the electronic device is the second system version, in response to the application version of the first application being upgraded from the first application version to the second application version, setting the first permission of the first application to an authorized state.

In the embodiment of the present application, the second application version may be included in the Android system 13 and above, and the system of the electronic device needs to verify the version of the first permission. It is understandable that the system version of the electronic device and the second application version may not correspond, and the first application applies for the first permission in the second application version. At this time, the system needs to verify the first permission applied by the first application in the second application version.

Exemplarily, in the embodiment corresponding to FIG. 3 above, in Android system versions 13 and above, the second application version may include versions with targetSDK versions 30, 31, and 32.

The system can determine the authorization status of the first permission applied for by the first application. If the first permission is in an unauthorized state and the targetSDK version of the first application is between Android system version 6 and Android system version 12, the system can perform secondary authorization for the first application. In this way, when the first application accesses the external storage of the electronic device to read data, the system can determine that the application is granted the first permission, and then allow the application to access the data in the storage.

Optionally, based on the embodiment corresponding to FIG. 5 , the second application version is a software development kit SDK version within a preset version range.

In the embodiment of the present application, the preset version range may include the targetSDK versions 30, 31, and 32 in the above embodiment. The second application version may refer to the relevant description in the above step S502, which will not be repeated here.

It can be understood that the system re-authorizes the first permission applied for by the first application in the second application version. In this way, when the first application accesses data in the external storage of the electronic device, it can be determined that the first application is granted the first permission, which will not affect the operation of the application, allowing the first application to normally access the data in the storage, thereby improving the user experience.

Optionally, based on the embodiment corresponding to Figure 5, a preset list is saved in the electronic device, the preset list includes the first permission, and before setting the first permission of the first application to the authorized state, it may also include: determining whether the first application has applied for the permission in the preset list; setting the first permission of the first application to the authorized state may include: if the first application has applied for the first permission in the preset list, setting the first permission of the first application to the authorized state.

In the embodiment of the present application, the preset list can be understood as the implicit authorization list in the embodiment corresponding to Figure 4. The specific process of determining whether the first application has applied for permissions in the preset list can refer to the relevant description of step S415 in the embodiment corresponding to Figure 4, which will not be repeated here.

The system can re-authorize the implicit storage permission of the first application when the implicit storage permission of the first application is not authorized. In this way, when the first application accesses data in the external storage of the electronic device, the system will check the implicit storage permission. If the system determines that the first application is granted the implicit storage permission, the first application can access the data in the storage, so that the first application can run normally.

Optionally, based on the embodiment corresponding to Figure 5, the method may also include: the first application requests access to data of the second application; when the application version of the first application is the second application version, verifying the first permission of the first application; when the first permission is in an authorized state, the first application accesses the data of the second application.

In the embodiment of the present application, the second application can be understood as an application that needs to apply for the first permission to access the data of the second application. For example, the second application may include a gallery application, an audio application, a video application, a file management application, etc., and the specific type of the second application is not limited in the embodiment of the present application. The data of the second application may include pictures, audio, video, files, etc., which are not limited in the embodiment of the present application.

When the system version of the electronic device is the second system version and the application version of the first application is the second application version, the first application needs to apply for the first permission when accessing the data of the second application. The first application can access the data of the second application only when the first permission is in the authorized state. In this way, the security of data access between applications is improved, so that the data of the second application can be better protected and the user experience can be improved.

Optionally, based on the embodiment corresponding to Figure 5, the first application also applies for the second permission in both the first application version and the second application version, and the method may also include: the first application requests access to data of the second application; when the application version of the first application is the first application version, the second permission of the first application is verified; when the second permission is in an authorized state, the first application accesses the data of the second application.

In the embodiment of the present application, the second permission may include the READ_EXTERNAL_STORAGE permission in the embodiment corresponding to FIG. 1 above. When the first application accesses the data of the second application,

When the system version of the electronic device is the first system version or the second system version and the application version of the first application is the first application version, the first application needs to apply for the second permission when accessing the data of the second application. The first application can access the data of the second application only when the second permission is in the authorized state.

In this way, the security of data access between applications is improved, so that the data of the second application can be better protected and the user experience is improved.

Optionally, based on the embodiment corresponding to FIG. 5 , the first permission includes one or more of the following: READ_MEDIA_IMAGES permission, READ_MEDIA_AUDIO permission or READ_MEDIA_VIDEO permission, and the second permission includes: READ_EXTERNAL_STORAGE permission.

In the embodiment of the present application, the functions of the first permission and the second permission can refer to the description in the above embodiment and will not be repeated here.

By controlling the authorization status of the first permission and/or the second permission, the electronic device can better control the security of data access between applications and reasonably open the first permission and/or the second permission for the first application, so that the first application can run normally.

It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to realize the above functions, it includes hardware structures and/or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the method steps of each example described in the embodiment disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

The embodiment of the present application can divide the functional modules of the device implementing the method according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

FIG6 is a schematic diagram of the structure of a chip provided in an embodiment of the present application. The chip 600 includes one or more (including two) processors 601 , a communication line 602 , a communication interface 603 and a memory 604 .

In some implementations, the memory 604 stores the following elements: executable modules or data structures, or a subset thereof, or an extended set thereof.

The method described in the above embodiment of the present application can be applied to the processor 601, or implemented by the processor 601. The processor 601 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware or software instructions in the processor 601. The above processor 601 can be a general processor (for example, a microprocessor or a conventional processor), a digital signal processor (digital signal processing, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC), a field-programmable gate array (field-programmable gate array, FPGA) or other programmable logic devices, discrete gates, transistor logic devices or discrete hardware components. The processor 601 can implement or execute the methods, steps and logic block diagrams related to each processing disclosed in the embodiment of the present application.

The steps of the method disclosed in the embodiment of the present application can be directly embodied as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. Among them, the software module can be located in a mature storage medium in the field such as a random access memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable read only memory (EEPROM). The storage medium is located in the memory 604, and the processor 601 reads the information in the memory 604 and completes the steps of the above method in combination with its hardware.

The processor 601 , the memory 604 , and the communication interface 603 may communicate with each other via the communication line 602 .

In the above embodiments, the instructions stored in the memory for execution by the processor may be implemented in the form of a computer program product, wherein the computer program product may be pre-written in the memory, or may be downloaded and installed in the memory in the form of software.

The present application embodiment also provides a computer program product including one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. For example, the available medium may include a magnetic medium (e.g., a floppy disk, a hard disk or a tape), an optical medium (e.g., a digital versatile disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

The embodiments of the present application also provide a computer-readable storage medium. The methods described in the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. Computer-readable media may include computer storage media and communication media, and may also include any medium that can transfer a computer program from one place to another. The storage medium may be any target medium that can be accessed by a computer.

As a possible design, the computer readable medium may include a compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM or other optical disc storage; the computer readable medium may include a magnetic disk storage or other magnetic disk storage device. Moreover, any connection line may also be appropriately referred to as a computer readable medium. For example, if the software is transmitted from a website, server or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology (such as infrared, radio and microwave), the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology such as infrared, radio and microwave are included in the definition of medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while optical discs reproduce data optically using lasers.

The present application embodiment is described with reference to the flowchart and/or block diagram of the method, device (system) and computer program product according to the embodiment of the present application. It should be understood that each process and/or box in the flowchart and/or block diagram, and the combination of the process and/or box in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processing unit of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processing unit of the computer or other programmable data processing device produce a device for realizing the function specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

Claims (10)

1.A rights management method, the method comprising:

in response to upgrading a system version of the electronic device from a first system version to a second system version, setting a first right of a first application to an unauthorized state, wherein the application version of the first application is a first application version in which the first application applies for the first right, the first right is not defined in the first system version, and the first right is defined in the second system version;

and in the case that the system version of the electronic device is the second system version, setting the first authority of the first application to an authorized state in response to the application version of the first application being upgraded from the first application version to the second application version.

2. The method of claim 1, wherein the second application version is a Software Development Kit (SDK) version within a preset version interval.

3. The method according to claim 1 or 2, wherein a preset list is stored in the electronic device, the preset list including the first right, and further comprising, before setting the first right of the first application to an authorized state:

judging whether the first application applies for permission in the preset list or not;

Setting the first right of the first application to an authorized state, including:

And setting the first authority of the first application to be in an authorized state under the condition that the first application applies for the first authority in the preset list.

4. A method according to any one of claims 1-3, wherein the method further comprises:

the first application requests to access the data of the second application;

checking the first authority of the first application under the condition that the application version of the first application is the second application version;

and under the condition that the first authority is in an authorized state, the first application accesses the data of the second application.

5. The method of any of claims 1-4, wherein the first application also applies for second rights in both the first application version and the second application version, the method further comprising:

the first application requests to access the data of the second application;

Checking the second authority of the first application under the condition that the application version of the first application is the first application version;

and under the condition that the second authority is in an authorized state, the first application accesses the data of the second application.

6. A method as claimed in any one of claims 1 to 5, wherein the first rights include one or more of: READ MEDIA image rights, READ MEDIA AUDIO rights, or READ MEDIA VIDEO rights, the second rights comprising: READ_ EXTERNAL _STORAGE rights.

7. An electronic device, comprising: a memory and a processor;

The memory stores computer-executable instructions;

The processor executing computer-executable instructions stored in the memory to cause the electronic device to perform the method of any one of claims 1-6.

8. A system on a chip comprising at least one processor and a communication interface, the communication interface and the at least one processor being interconnected by a wire, the at least one processor being configured to execute a computer program or instructions to perform the method of any of claims 1-6.

9. A computer readable storage medium storing instructions that, when executed, cause a computer to perform the method of any one of claims 1-6.

10. A computer program product comprising a computer program which, when run, causes an electronic device to perform the method of any of claims 1-6.