CN117932589A

CN117932589A - Authority management method and related device

Info

Publication number: CN117932589A
Application number: CN202311722748.8A
Authority: CN
Inventors: 余岳锋; 李哲
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-12-14
Filing date: 2023-12-14
Publication date: 2024-04-26

Abstract

The embodiment of the application provides a right management method and a related device, and relates to the technical field of terminals. The method comprises the following steps: the system may determine the state of authority of the implicit authorization applied for the application. If the implicit authorized authority is in an unauthorized state and the TARGETSDK version of the application is in a preset version interval, the system can perform secondary authorization for the implicit authorized authority applied by the application. In this way, the implicitly granted permissions applied by the application may be granted, thereby allowing the application to function properly.

Description

Authority management method and related device

Technical Field

The application relates to the technical field of terminals, in particular to a rights management method and a related device.

Background

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, etc., for example, an application may access pictures and videos in a gallery.

However, in some scenarios, situations may arise where an application cannot access pictures and videos in a gallery.

Disclosure of Invention

The system can judge the READ_MEDIA_IMAGES authority, READ_MEDIA_AUDIO authority and/or READ_MEDIA_VIDEO authority states applied by the application. If the read_media_image rights, read_media_audio rights, and/or read_media_video rights are unauthorized, and the TARGETSDK version of the application is between the Android system 6 version and the Android system 12 version, the system may perform secondary authorization for the application. Thus, when the application accesses data in the external storage of the electronic device, the system can determine that the application is granted READ MEDIA image rights, etc., and can 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 upgrading a system version of the electronic device from a first system version to a second system version, setting a first authority 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 authority, the first system version is undefined with the first authority, and the second system version is defined with the first authority; in response to an upgrade of an application version of a first application from a first application version to a second application version, setting a first right of the first application to an authorized state. Thus, when the first application accesses the data in the external storage of the electronic device, the system can judge that the application is granted the first authority, and the application can be allowed to access the data in the storage.

In one possible implementation, the second application version is a software development kit SDK version within a preset version interval. Therefore, when the first application accesses the data in the external storage of the electronic device, the first application can be judged to be granted with the first authority, so that the running of the application is not influenced, the first application can normally access the data in the storage, and the user experience is improved.

In a possible implementation, the electronic device stores a preset list, where the preset list includes a first right, and before the first right of the first application is set to an authorized state, the method further includes: judging whether the first application applies for permission in a preset list or not; setting the first right of the first application to an authorized state includes: 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. Thus, when the first application accesses the data in the external storage of the electronic device, the system can check the implicit storage authority, and if the system judges that the first application is granted the implicit storage authority, the first application can access the data in the storage, so that the first application can normally run.

In a possible implementation, the method further includes: the first application requests to access the data of the second application; under the condition that the application version of the first application is the second application version, verifying the first authority of the first application; and under the condition that the first authority is in an authorized state, the first application accesses the data of the second application. Therefore, the security of accessing data between the applications is improved, so that the data of the second application can be better protected, and the user experience is improved.

In one possible implementation, the first application further applies for the second right 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; under the condition that the application version of the first application is the first application version, verifying the second authority of the first application; and under the condition that the second authority is in an authorized state, the first application accesses the data of the second application. Therefore, the security of accessing data between the applications is improved, so that the data of the second application can be better protected, and the user experience is improved.

In one possible implementation, the first right includes one or more of the following: READ MEDIA image rights, READ MEDIA AUDIO rights, or READ MEDIA VIDEO rights, the second rights including: READ_ EXTERNAL _STORAGE rights. In this way, the electronic device can better control the security of accessing data between applications by controlling the authorization states of the first authority and/or the second authority and the like, and reasonably opens the first authority and/or the second authority for the first application, so that the first application operates normally.

In a second aspect, an embodiment of the present application provides an apparatus for rights management, where the apparatus may be an electronic device, or may be a chip or a chip system in an electronic device. The apparatus may include a processing unit. The processing unit is configured to implement any method related to processing performed by the electronic device in the first aspect or any of the possible implementations of the first aspect. When the apparatus is an electronic device, the processing unit may be a processor. The apparatus may further comprise a storage unit, which may be a memory. The storage unit is configured 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 one of the possible implementation manners of the first aspect. When the apparatus is a chip or a system of chips within an electronic device, the processing unit may be a processor. The processing unit executes instructions stored by the storage unit to cause the electronic device to implement the method described in the first aspect or any one of the possible implementations of the first aspect. The memory unit may be a memory unit (e.g., a register, a cache, etc.) within the chip, or a memory unit (e.g., a read-only memory, a random access memory, etc.) within the electronic device that is external to the chip.

The processing unit is configured to set the first right of the first application to an unauthorized state in response to upgrading the system version of the electronic device from the first system version to the second system version; and the first authority of the first application is set to be in an authorized state in response to the upgrading of the application version of the first application from the first application version to the second application version.

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

In one possible implementation manner, the processing unit is configured to determine whether the first application applies for the permission in the preset list, and is further configured to set the first permission of the first application to an authorized state if the first application applies for the first permission in the preset list.

In a possible implementation manner, the processing unit is configured to request access to data of the second application; the first authority of the first application is verified; and the method is particularly used for accessing the data of the second application under the condition that the first authority is in the authorized state.

In a possible implementation manner, the processing unit is configured to request access to data of the second application; the second authority of the first application is also used for checking; the method is particularly used for the first application to access the data of the second application under the condition that the second authority is in the authorized state.

In a possible implementation, the first right includes one or more of the following: READ MEDIA image rights, READ MEDIA AUDIO rights, or READ MEDIA VIDEO rights, the second rights including: READ_ EXTERNAL _STORAGE rights.

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

In a fourth aspect, the present application provides a chip or chip system comprising at least one processor and a communication interface, the communication interface and the at least one processor being interconnected by wires, the at least one processor being adapted to execute a computer program or instructions to perform the method described in the first aspect or any one of the possible implementations of the first aspect. The communication interface in the chip can be an input/output interface, a pin, a circuit or the like.

In one possible implementation, the chip or chip system described above further includes at least one memory, where the at least one memory has instructions stored therein. The memory may be a memory unit within the chip, such as a register, a cache, etc., or may be a memory unit of the chip (e.g., a read-only memory, a random access memory, etc.).

In a fifth aspect, embodiments of the present application provide a computer readable storage medium having stored therein a computer program or instructions which, when run on a computer, cause the computer to perform the method described in the first aspect or any one of the possible implementations of the first aspect.

In a sixth aspect, embodiments of the present application provide a computer program product comprising a computer program which, when run on a computer, causes the computer to perform the method described in the first aspect or any one of the possible implementations of the first aspect.

It should be understood that, the second aspect to the sixth aspect of the present application correspond to the technical solutions of the first aspect of the present application, and the advantages obtained by each aspect and the corresponding possible embodiments are similar, and are not repeated.

Drawings

FIG. 1 is a schematic diagram of an application storage authority and a grant status change thereof according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

Fig. 3 is a schematic software structure of an electronic device according to an embodiment of the present application;

FIG. 4 is a flowchart of a rights management method according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a rights management method according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a chip according to an embodiment of the present application.

Detailed Description

In order to facilitate the clear description of the technical solutions of the embodiments of the present application, the following simply describes some terms and techniques involved in the embodiments of the present application:

1. storing permission:

(1.1) READ_ EXTERNAL _STORAGE Authority: the rights allow the application to read data from an external storage of the electronic device, which may include, for example, pictures, audio, video, files, etc.

(1.2) READ_MEDIA_IMAGES rights: the rights allow the application to read the image file from an external storage of the electronic device, e.g. the image file may comprise a picture or the like.

(1.3) READ_MEDIA_AUDIO rights: the rights allow the application to read audio files from an external storage of the electronic device, e.g., the audio files may include recordings, speech, etc.

(1.4) READ_MEDIA_VIDEO rights: the rights allow the application to read the video file from an external storage of the electronic device.

2. TARGETSDK version: the target version of the software development kit (software development kit, SDK) may also be referred to as targetSdkVersion. the TARGETSDK version can be understood as the application programming interface (application programming interface, API) level corresponding to the application runtime, and the application can set targetSdkVersion to some API level according to its own business needs.

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

In some implementations, the version 13 of the Android system may also be referred to as a T version, the version 12 of the Android system may also be referred to as an S version, and the version 6 of the Android system may also be referred to as an M version.

3. Terminology

In embodiments of the present application, the words "first," "second," and the like are used to distinguish between identical or similar items that have substantially the same function and effect. For example, the first chip and the second chip are merely for distinguishing different chips, and the order of the different chips is not limited. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ.

It should be noted that, in the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a alone, a and B together, and B alone, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural.

4. Electronic equipment

The electronic device according to the embodiment of the present application may also be any form of terminal device, for example, the electronic device may include: a mobile phone, a tablet, a palmtop, a notebook, a mobile internet device (mobile INTERNET DEVICE, MID), a wearable device, a Virtual Reality (VR) device, an augmented reality (augmented reality, AR) device, a wireless terminal in industrial control (industrial control), a wireless terminal in unmanned (SELF DRIVING), a wireless terminal in teleoperation (remote medical surgery), a wireless terminal in smart grid (SMART GRID), a wireless terminal in transportation security (transportation safety), a wireless terminal in smart city (SMART CITY), a wireless terminal in smart home (smart home), a cellular phone, a cordless phone, a session initiation protocol (session initiation protocol, SIP) phone, a wireless local loop (wireless local loop, WLL) station, a personal digital assistant (personal DIGITAL ASSISTANT, PDA), a handheld device with wireless communication functionality, 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 an electronic public land mobile network (public land mobile network) in the future evolution, and the like, without limiting the application.

By way of example, and not limitation, in embodiments of the application, the electronic device may also be a wearable device. The wearable device can also be called as a wearable intelligent device, and is a generic name for intelligently designing daily wear by applying wearable technology and developing wearable devices, such as glasses, gloves, watches, clothes, shoes and the like. The wearable device is a portable device that is worn directly on the body or integrated into the clothing or accessories of the user. The wearable device is not only a hardware device, but also can realize a powerful function through software support, data interaction and cloud interaction. The generalized wearable intelligent device includes full functionality, large size, and may not rely on the smart phone to implement complete or partial functionality, such as: smart watches or smart glasses, etc., and focus on only certain types of application functions, and need to be used in combination with other devices, such as smart phones, for example, various smart bracelets, smart jewelry, etc. for physical sign monitoring.

In addition, in the embodiment of the application, the electronic device can also be an electronic device in an internet of things (internet of things, ioT) system, and the IoT is an important component of the development of future information technology, and the main technical characteristics of the IoT system are that the article is connected with a network through a communication technology, so that the man-machine interconnection and the intelligent network of the internet of things are realized.

The electronic device in the embodiment of the application may also be referred to as: a User Equipment (UE), a Mobile Station (MS), a Mobile Terminal (MT), an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote terminal, a mobile device, a user terminal, a wireless communication device, a user agent, or a user equipment, 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 top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer includes hardware such as a central processing unit (central processing unit, CPU), a memory management unit (memory management unit, MMU), and a memory (also referred to as a main memory). The operating system may be any one or more computer operating systems that implement business processes through processes (processes), such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a windows operating system. The application layer comprises applications such as a browser, an address book, word processing software, instant messaging software and the like.

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

Taking an example that an application can access pictures and videos in a gallery, before the application accesses the gallery, the application needs to apply READ_ EXTERNAL _STORAGE STORAGE permission. In the case where the system grants permission to the application READ_ EXTERNAL _STORGE, the application can access pictures, videos, etc. in the gallery.

In one possible scenario, from Android system 13 version, READ_ EXTERNAL _STORAGE permissions are invalidated. The API level corresponding to the Android system 13 version is 33, that is, if the application is in the TARGETSDK version 33, 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 image rights, READ MEDIA AUDIO rights, or READ MEDIA VIDEO rights.

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

As shown in fig. 1, taking an application access gallery as an example, the storage rights and the changes of the granted states thereof in different Operating System (OS) versions and different TARGETSDK versions of the application are described. In the embodiment of the application, the OS version can be understood as an Android system version or a ROM version.

(1) Case 1: and the version of the Android system is below 13 and the version of the Android system is below TARGETSDK.

Taking version of Android system 12 as an example, version TARGETSDK of application is 29, if the application wants to access the gallery, the application needs to apply READ_ EXTERNAL _STORAGE permission.

In some scenarios, the application may apply for READ_MEDIA_IMAGES rights, READ_MEDIA_AUDIO rights, and/or READ_MEDIA_VIDEO rights in advance in addition to READ_ EXTERNAL _STORAGE rights. For convenience of description, an application for which the read_media_image right, the read_media_audio right, and/or the read_media_video right are not previously applied will be referred to as an application a, and an application for which the read_media_image right, the read_media_audio right, and/or the read_media_video right are previously applied will be referred to as an application B.

However, on the version of the Android system 12, the read_media_image rights, read_media_audio rights, and/or read_media_video rights are not defined in the system, and therefore, the system will not check the authorization status of these three rights. Where rights not defined in the system may be referred to as free rights. When application A or application B accesses the gallery, the system will verify the READ_ EXTERNAL _STORAGE rights of application A or application B, but will not verify the free rights.

If the system determines that application A or application B is granted READ_ EXTERNAL _STORAGE rights, application A or application B may be allowed to access the content in the gallery, such as pictures, videos, etc.

If the system determines that application A or application B is not granted READ_ EXTERNAL _STORAGE permission, application A or application B is not allowed to access the contents of the gallery, such as pictures, videos, and the like.

(2) Case 2: and the version 13 of the Android system are more than the version 13, and the version TARGETSDK is less than the version 30.

When the system upgrades to Android system 13 version, the system defines read_media_image rights, read_media_audio rights, and read_media_video rights.

It can be appreciated that APIs corresponding to different Android system versions may vary. For forward compatibility, that is, for compatibility with the previous version, if the TARGETSDK version of the application setting is lower, the Android system will use the API level corresponding to the lower TARGETSDK version of the application setting even if the Android system has a higher API level.

For example, if the API level corresponding to the TARGETSDK version of the application setting is 32, the Android system has a higher API level, for example, the API level is 33, but the Android system still uses the API level set by the application, that is, the API level is 32.

Thus, for applications with TARGETSDK versions below 30, the system will still determine if the application is granted READ EXTERNAL STORAGE rights, rather than READ MEDIA image rights, READ MEDIA AUDIO rights, and/or READ MEDIA VIDEO rights.

Since the Android system 13 version, the system defines read_media_image rights, read_media_audio rights, and read_media_video rights. But some applications still use READ EXTERNAL store rights.

For application a that applied for READ EXTERNAL STORAGE rights, the system may implicitly grant READ MEDIA image rights, READ MEDIA AUDIO rights, and READ MEDIA VIDEO rights to application a. The system may also record these implicit storage rights as an authorization status, which may be marked as "YES", for example. Among them, the read_media_image right, the read_media_audio right, and the read_media_video right may also be referred to as an implicit storage right.

For application B, the system does not grant read_media_image rights, read_media_audio rights, and/or read_media_video rights to application B. In this case, the system will record these implicit storage rights as unauthorized states, which may be marked as "NO", for example.

When an application accesses the gallery, because the TARGETSDK version of application A or application B is below 30, the system will verify the READ_ EXTERNAL _STORAGE rights of application A or application B, but will not verify the READ_MEDIA_IMAGES rights of application A or application B, etc. That is, for the case where the application is not granted read_media_image rights, read_media_audio rights, and/or read_media_video rights, the application may still access the gallery through the read_ EXTERNAL _store rights.

(3) Case 3: android system 13 version, TARGETSDK version 30-32.

For applications with TARGETSDK versions 30, 31, or 32, the system will verify the read_media_image rights, read_media_audio rights, and/or read_media_video rights of the application.

For application a, the system may implicitly grant read_media_image rights, read_media_audio rights, and/or read_media_video rights to the application and record these implicitly authorized rights as an authorized state.

For application B, the system does not grant application read_media_image rights, read_media_audio rights, and/or read_media_video rights. In this case, the system will record these implicitly authorized rights as unauthorized.

When an application accesses the gallery, the system verifies the READ _ MEDIA _ image rights of the application.

If the system determines that application A or application B is granted READ_MEDIA_IMAGES permission, application A or application B may be allowed to access the content, such as pictures, videos, etc. in the gallery.

If the system judges that the application A or the application B is not granted the READ_MEDIA_IMAGES permission, the application A or the application B is not allowed to access the contents such as pictures, videos and the like in the gallery.

In view of this, the system can determine the read_media_image rights, the read_media_audio rights, and/or the read_media_video rights status applied by the application. If the read_media_image rights, read_media_audio rights, and/or read_media_video rights are unauthorized, and the TARGETSDK version of the application is between the Android system 6 version and the Android system 12 version, the system may perform secondary authorization for the application. Thus, when the application accesses data in the external storage of the electronic device, the system can determine that the application is granted READ MEDIA image rights, etc., and can allow the application to access the data in the storage.

By way of example, fig. 2 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 (universal serial bus, USB) interface 130, a charge 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, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It should be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the application, the electronic device may include more or less components than illustrated, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may comprise hardware, software, or a combination of software and hardware implementations.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (IMAGE SIGNAL processor, ISP), a controller, a video codec, a digital signal processor (DIGITAL SIGNAL processor, DSP), a baseband processor, and/or a neural-Network Processor (NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

It should be understood that the connection relationship between the modules illustrated in the embodiments of the present application is only illustrative, and does not limit the structure of the electronic device. In other embodiments of the present application, the electronic device may also use different interfacing manners, or a combination of multiple interfacing manners in the foregoing embodiments.

The internal memory 121 may be used to store computer-executable program code that includes instructions. The internal memory 121 may include a storage program area and a storage data area. The storage program area may store an operating system, an application program required for at least one function, and the like. The storage data area may store data created during use of the electronic device, etc. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like. The processor 110 performs various functional applications of the electronic device and data processing by executing 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, and the like. The display 194 includes a display panel. In some embodiments, the electronic device may include 1 or N display screens 194, N being a positive integer greater than 1. The electronic device implements display functions via a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. For example, in the embodiment of the present application, the display screen is used to display photos or videos in applications such as gallery.

Fig. 3 is a software configuration block diagram of an electronic device according to an embodiment of the present application. The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into five layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun rows (Android runtime) and system libraries, and a kernel layer, respectively.

The application layer may also be referred to as an application layer, which may include a series of application packages. As shown in FIG. 3, the application package may include gallery, video, calendar, camera, game, memo, etc. applications. Applications may include system applications and three-way applications.

The application Framework layer may also be referred to as a Framework layer, which may provide APIs and programming frameworks for application-layer applications. The frame layer may include some predefined functions.

As shown in fig. 3, the Framework layer may include a package manager service (PACKAGE MANAGER SERVICE, PMS), a window manager, a resource manager, a content provider, and a view system, etc.

The PMS may be responsible for installing, managing, and uninstalling applications on the electronic device, and the like. When a certain application is installed, the PMS may identify all components of the application, such as components including Activity components, service components Service and broadcast components Broadcast Receiver, etc., and assign corresponding rights to these components. The PMS may also detect the running status of the installed application, ensuring the integrity and security of the application.

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

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the Framework layer run in virtual machines. The virtual machine executes java files of the application layer and the Framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like. For example, in the embodiment of the application, the virtual machine can be used for checking the authority applied by the application, accessing the gallery and other applications, upgrading the system version and other functions.

The system library may also be referred to as Native layer, which may include a plurality of functional modules. For example: media libraries, function libraries, graphics processing libraries, etc.

The kernel layer is a layer between hardware and software. The kernel layer may include display drivers, camera drivers, audio drivers, battery drivers, CPU drivers, and the like.

It should be noted that, the embodiment of the present application is only illustrated by using an android system, and in other operating systems (such as a Windows system, an IOS system, etc.), the scheme of the present application can be implemented as long as the functions implemented by each functional module are similar to those implemented by the embodiment of the present application.

Fig. 4 shows a flow chart of a rights management method.

S401, running the application in the S version.

The embodiment of the present application is illustrated by taking an application running in S version as an example. The S version may also be understood as the Android system 12 version.

S402, the system records the application permission.

For an application running on the Android system 12 version, the system may record the state of the storage rights applied by the application, including, for example, the state of free rights such as read_media_image rights, read_media_audio rights, and/or read_media_video rights.

S403, accessing a gallery by the application.

S404, checking the storage authority of the application.

When an application accesses the gallery, the system may verify the storage rights of the application. The TARGETSDK versions of the application are different, the verified storage rights are also different, and the process of specifically verifying the storage rights of the application may refer to the related description in the embodiment corresponding to fig. 3, which is not repeated.

S405, checking whether the check is successful.

If the storage authority check is successful, the application can access the gallery, corresponding to step S406; if the storage authority check fails, the application fails to access the gallery, corresponding to step S407.

It can be understood that when the gallery is accessed, the security of the data in the access gallery can be improved by checking the storage authority, so that the data in the gallery can be better protected, and the user experience is improved.

S406, the application can access the gallery.

S407, the application fails to access the gallery.

S408, the system is upgraded from the S version to the T version.

The T version may also be understood as the Android system 13 version. The upgrade of the system from the S version to the T version can be understood as the upgrade of the system from the Android system 12 version to the Android system 13 version.

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

In an implementation, when the system is upgraded to the Android system 13 version, the system may execute step S409 to perform secondary authorization on the unauthorized read_media_image rights, read_media_audio rights, and/or read_media_video rights during the first upgrade startup process. Of course, the system may perform the secondary authorization process at other occasions, for example, other occasions may include when the upgrade version is applied or when the user agrees to the operation of authorizing the read_media_image right, the read_media_audio right, and/or the read_media_video right, and the embodiment of the present application is not limited.

S409, the system grants the application storage rights.

A packet manager service (PACKAGE MANAGER SERVICE, PMS) of the system Framework layer may be used to grant storage rights for applications.

S410, the system detects whether the application applies for implicit storage rights.

The PMS may also be used to detect whether an application applies for implicit storage rights.

If the application does not apply for READ _ MEDIA _ image rights, READ _ MEDIA _ AUDIO rights and/or READ _ MEDIA _ VIDEO rights, step S411 may be performed.

If the application has applied for READ MEDIA image rights, READ MEDIA AUDIO rights and/or READ MEDIA VIDEO rights, step S412 may be performed.

S411, authorization.

The system may grant READ _ MEDIA _ image rights, READ _ MEDIA _ AUDIO rights, and/or READ _ MEDIA _ VIDEO rights to the application.

S412, unauthorized.

The system does not grant READ _ MEDIA _ image rights, READ _ MEDIA _ AUDIO rights, and/or READ _ MEDIA _ VIDEO rights to the application.

It will be appreciated that the system may also perform step S413, recording the rights granted to the application.

S413, whether hota upgrades the scene, whether TARGETSDK version is between M version and T version, and whether the version is implicit storage authority.

Hota upgrades may also be referred to as Over The Air (OTA) upgrades, online upgrades, or cloud upgrades. The hota upgrade can be used for upgrading the system version of the electronic equipment and can also be understood as upgrading the Android system version.

In a possible implementation, the system may invoke the relevant interface to determine whether the application needs to be upgraded hota. For example, if the system detects that a version higher than the current application version is included in the cloud server, then a hota upgrade may be performed.

The system can determine whether secondary authorization is required for the implicit storage rights. For example, if the system is hota in the upgrade scenario, the TARGETSDK version is between the Android system 6 version and the Android system 12 version, and is the implicit storage permission, the system may perform secondary authorization for the implicit storage permission in the process of performing hota upgrade.

The version 6 of the Android system can be understood as an M version, and the version 12 of the Android system can be understood as a T version. the TARGETSDK version is between the Android system 6 version and the Android system 12 version, and can be understood as the API level of 23 to 32. Implicit storage rights may include read_media_image rights, read_media_audio rights, and read_media_video rights.

S414, hota.

In a possible implementation, a cloud server may include a higher version of the system upgrade package, and the system may call an interface for downloading the upgrade package for hota upgrades. The manner in which hota is specifically updated is not limited in this embodiment.

S415, traversing a system implicit authorization list, and authorizing the application to apply for the implicit authorization authority.

It will be appreciated that an implicit authorization list may be created in the system, which may include one or more rights requiring implicit authorization, e.g., the rights requiring implicit authorization may include READ MEDIA image rights, READ MEDIA AUDIO rights, READ MEDIA VIDEO rights, etc. The system can traverse the implicit authorization list, if the application applies for one or more rights requiring implicit authorization in the implicit authorization list, the system can authorize the one or more rights requiring implicit authorization applied by the application, and update the authorization status of each right into the system.

In a possible implementation, the system may store the implicit authorization information of the application in a data structure such as a list, map, etc., and the specific way of storing the information is not limited in the embodiment of the present application.

The system can perform secondary authorization for the implicit storage rights of the application under the condition that the implicit storage rights of the application are not authorized. Thus, when the application accesses the gallery, the system will verify the read_media_image rights, and if the system determines that the application is granted read_media_image rights, the application may be allowed to access the content such as the pictures in the gallery.

It can be understood that the foregoing embodiments are described by taking the content such as pictures and VIDEOs in the application access gallery as an example, and the rights management method according to the embodiments of the present application may also be applied to the application access VIDEO application, the document application, and other scenes, that is, the scenes where the read_media_image rights, the read_media_audio rights, and/or the read_media_video rights need to be applied. In addition, the rights management method of the embodiment of the application can be applied to other scenes with the application rights changed along with the system version change, and the embodiment of the application is not limited.

The method according to the embodiment of the present application will be described in detail by way of specific examples. The following embodiments may be combined with each other or implemented independently, and the same or similar concepts or processes may not be described in detail in some embodiments.

Fig. 5 shows a rights management method of an embodiment of the application. The method comprises the following steps:

S501, in response to upgrading of a system version of the electronic equipment from a first system version to a second system version, setting a first authority of a first application to an unauthorized state, wherein the application version of the first application is a first application version, the first application is applied for the first authority in the first application version, the first authority is not defined in the first system version, and the first authority is defined in the second system version.

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

The first rights may be understood as rights having different definitions on different system versions, as well as free rights in the above embodiments. For example, the first rights may be read_media_image rights, read_media_audio rights, and/or read_media_video rights in the embodiments corresponding to fig. 1. Illustratively, in the Android system 13 version, read_media_image rights, read_media_audio rights, and/or read_media_video rights may be defined. In versions below the Android system 13, read_media_image rights, read_media_audio rights, and/or read_media_video rights 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 right.

The first system version may be understood as a system version not defined with the first authority, and by way of example, the first authority may be read_media_image authority, read_media_audio authority, and/or read_media_video authority, and then the first system version may be understood as a version below the Android system 13, for example, the first system version may include an S version.

The second system version may be understood as a system version defining a first authority, and illustratively, the first authority is read_media_image authority, read_media_audio authority, and/or read_media_video authority, and the second system version may be understood as a version of the Android system 13, for example, the second system version may include a T version.

The first application version may be understood as TARGETSDK version, and the first application version may be included in a version below the Android system 13, and the system of the electronic device does not need a version for checking the first authority. It is understood 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, the system may not verify the first authority of the first application in the first application version for forward compatibility.

Exemplary, in the embodiment corresponding to fig. 3, versions below the Android system 13; for example, between Android system 6 version and Android system 12 version, the first application version may include a version with TARGETSDK version below 30.

S502, under the condition that the system version of the electronic equipment is the second system version, the first authority of the first application is set to be in an authorized state in response to the upgrading of the application version of the first application from the first application version to the second application version.

In the embodiment of the present application, the second application version may be included in versions of Android systems 13 and above 13, where the system of the electronic device needs to verify the first permission. It is understood that the system version of the electronic device and the second application version may not correspond, and that the first application has the first right in the second application version. At this time, the system needs to verify the first authority of the first application in the second application version.

For example, in the embodiment corresponding to fig. 3, in the versions above the Android systems 13 and 13, the second application version may include the version TARGETSDK with versions 30, 31, and 32.

The system may determine an authorization status of the first right applied by the first application. If the first authority is in an unauthorized state and the TARGETSDK version of the first application is between the Android system 6 version and the Android system 12 version, the system can perform secondary authorization for the first application. Thus, when the first application accesses the data in the external storage of the electronic device, the system can judge that the application is granted the first authority, and the application can be allowed 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 interval.

In the embodiment of the present application, the preset version interval may include versions of TARGETSDK versions 30, 31, and 32 in the above embodiment. The second application version may refer to the related description in step S502, and will not be described again.

It can be understood that the system grants the first authority applied by the first application in the second application version again, so that when the first application accesses the data in the external storage of the electronic device, the first application can be judged to be granted the first authority, thereby not affecting the running of the application, enabling the first application to normally access the data in the storage, and improving the user experience.

Optionally, on the basis of the embodiment corresponding to fig. 5, a preset list is stored in the electronic device, where the preset list includes the first permission, and before the first permission of the first application is set to the authorized state, the method may further include: judging whether the first application applies for permission in a preset list or not; setting the first right of the first application to the authorized state may include: 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.

In the embodiment of the present application, the preset list may be understood as an implicit authorization list in the embodiment corresponding to fig. 4. The specific process of determining whether the first application applies for the permission in the preset list may refer to the description related to step S415 in the embodiment corresponding to fig. 4, which is not repeated.

The system may secondarily authorize the implicit storage rights of the first application in the event that the implicit storage rights of the first application are not authorized. Thus, when the first application accesses the data in the external storage of the electronic device, the system can check the implicit storage authority, and if the system judges that the first application is granted the implicit storage authority, the first application can access the data in the storage, so that the first application can normally run.

Optionally, on the basis of the embodiment corresponding to fig. 5, the method may further include: the first application requests to access the data of the second application; under the condition that the application version of the first application is the second application version, verifying the first authority of the first application; and under the condition that the first authority is in an authorized state, the first application accesses the data of the second application.

In the embodiment of the application, the second application can be understood as an application which needs to apply the first authority 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 embodiments of the present application are not limited with respect to a specific type of the second application. The data of the second application may include pictures, audio, video, files, and the like, which are not limited by the embodiment of the present application.

When the system version of the electronic device is a 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 authority when accessing the data of the second application. The first application may access the data of the second application only if the first right is in an authorized state. Therefore, the security of accessing data between the applications is improved, so that the data of the second application can be better protected, and the user experience is improved.

Optionally, on the basis of the embodiment corresponding to fig. 5, the first application further applies for the second right in both the first application version and the second application version, and the method may further include: the first application requests to access the data of the second application; under the condition that the application version of the first application is the first application version, verifying the second authority of the first application; and under the condition that the second authority is in an authorized state, the first application accesses the data of the second application.

In an embodiment of the present application, the second authority may include the read_ EXTERNAL _store authority in the embodiment corresponding to fig. 1. When a first application accesses data of a second application,

When the system version of the electronic device is a first system version or a second system version and the application version of the first application is a first application version, the first application needs to apply for the second authority when accessing the data of the second application. The first application may access the data of the second application only if the second right is in an authorized state.

Therefore, the security of accessing data between the applications is improved, so that the data of the second application can be better protected, and the user experience is improved.

Optionally, on the basis of the embodiment corresponding to fig. 5, the first authority includes one or more of the following: READ MEDIA image rights, READ MEDIA AUDIO rights, or READ MEDIA VIDEO rights, the second rights including: READ_ EXTERNAL _STORAGE rights.

In the embodiment of the present application, the functions of the first right and the second right may refer to the descriptions in the above embodiment, and will not be repeated.

The electronic equipment can better control the security of the access data among the applications by controlling the authorization states of the first authority and/or the second authority and the like, and reasonably opens the first authority and/or the second authority for the first application, so that the first application can normally run.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.

The foregoing description of the solution provided by the embodiments of the present application has been mainly presented in terms of a method. To achieve the above functions, it includes corresponding hardware structures and/or software modules that perform the respective functions. Those of skill in the art will readily appreciate that the present application may be implemented in hardware or a combination of hardware and computer software, as the method steps of the examples described in connection with the embodiments disclosed herein. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The embodiment of the application can divide the functional modules of the device for realizing the method according to the method example, for example, each functional module can be divided corresponding to each function, and two or more functions can be integrated in one processing module. The integrated modules may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be implemented in actual implementation.

Fig. 6 is a schematic structural diagram of a chip according to an embodiment of the present application. Chip 600 includes one or more (including two) processors 601, communication lines 602, communication interfaces 603, and 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 embodiments of the present application may 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 implementation, the steps of the above method may be performed by integrated logic circuits of hardware in the processor 601 or instructions in the form of software. The processor 601 may be a general purpose processor (e.g., a microprocessor or a conventional processor), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gates, transistor logic, or discrete hardware components, and the processor 601 may implement or perform the methods, steps, and logic diagrams related to the disclosed processes in the embodiments of the present application.

The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in any well-known storage medium such as ram, rom, or EEPROM (ELECTRICALLY ERASABLE PROGRAMMABLE READ ONLY MEMORY, EEPROM). The storage medium is located in a memory 604, and the processor 601 reads information in the memory 604 and in combination with its hardware performs the steps of the method described above.

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

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

Embodiments of the present application also provide a computer program product comprising one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in 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, computer, server, or data center of one website, through a wired (e.g., coaxial cable, fiber optic, digital subscriber line (digital subscriber line, DSL), or wireless (e.g., infrared, wireless, microwave, etc.) means to the website, computer, server, or data center of another website, the computer-readable storage medium may be any available medium that can be stored or data storage device such as a server, data center, etc., that includes an integration of one or more available media, for example, the available media may include magnetic media (e.g., floppy disk, hard disk, or magnetic tape), optical media (e.g., digital versatile disk (DIGITAL VERSATILEDISC, DVD)), or semiconductor media (e.g., solid state disk (solid STATE DISK, SSD)), and the like.

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

As one possible design, the computer-readable medium may include compact disk read-only memory (CD-ROM), RAM, ROM, EEPROM, or other optical disk storage; the computer readable medium may include disk storage or other disk storage devices. Moreover, any connection is properly termed 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 technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, digital versatile disc (DIGITAL VERSATILEDISC, DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processing unit of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

Claims

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.