Digital resource publishing method, cloud device, readable storage medium and program product

Abstract

The application relates to the technical field of computers, and provides a digital resource publishing method, a cloud device, a readable storage medium and a program product, which comprises the following steps: when digital resource publishing is performed, such as when application component publishing is performed, different types of electronic devices required to be published are distinguished according to different combinations of software and hardware indicated by publishing information, and the digital resource is independently published for different types of electronic devices; then, quality measurement is performed on different types of electronic devices according to quality data, and when there is a first electronic device with a quality problem, publishing control and quality early warning are performed on the first electronic device and electronic devices of the same type as the first electronic device. In this way, the quality problem can be accurately positioned and measured, and fine quality measurement and automatic control can be realized from the dimension of the software and hardware system, so that the spread and intensification of the quality problem can be timely and targetedly prevented after the quality problem occurs.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a digital resource publishing method, cloud device, readable storage medium, and program product. Background Technology

[0002] With the development of functionalities in electronic devices, the increasing demands of users, and the iterative updates of software development technologies, developers of electronic devices now push and release the necessary digital resources to electronic devices based on actual needs, in order to improve existing functions, solve known problems, or provide users with new functions.

[0003] Currently, the way electronic device developers release digital resources is usually by packaging them together with the operating system, which makes it difficult to accurately locate and measure the quality problems caused by the release of digital resources. Summary of the Invention

[0004] This application provides a digital resource publishing method, cloud device, readable storage medium, and program product for accurately locating and measuring quality problems caused by the publishing of digital resources (such as application component publishing).

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, a method for publishing digital resources is provided. This method includes: acquiring digital resources to be published and publishing information; the publishing information includes at least one software and hardware combination, where different software and hardware combinations correspond to different software systems and / or hardware systems; determining at least one publishing device type based on the publishing information, and publishing the digital resources to target electronic devices corresponding to the publishing device type; wherein the software and / or hardware systems of target electronic devices corresponding to different publishing device types are different, while the software and hardware systems of target electronic devices corresponding to the same publishing device type are the same; receiving quality data sent by multiple target electronic devices, the quality data corresponding to the published digital resources; performing quality measurement on each target electronic device based on the quality data; and when it is determined based on the quality measurement that a first electronic device with quality problems exists among the target electronic devices, performing publishing control and quality warning on candidate electronic devices; the candidate electronic devices include the first electronic device and target electronic devices with the same publishing device type as the first electronic device.

[0007] In this implementation, quality measurement is performed using quality data reported by electronic devices, which enables precise location and measurement of quality problems caused by the release, thereby allowing for accurate assessment of the impact of these quality problems.

[0008] Furthermore, by differentiating between different hardware and software combinations, different types of electronic devices can be independently released, quality measured, and automatically controlled. This enables refined quality measurement and automatic control from the perspective of hardware and software systems, and allows for timely and targeted prevention of the spread and escalation of quality problems after they occur.

[0009] In one possible implementation of the first aspect, digital resources include application components, software systems, resource data, or large model data. This implementation enables refined quality measurement and automated control over the release of digital resources such as application components, software systems, resource data, and large model data, and allows for timely and targeted prevention of the spread and escalation of quality problems after they arise.

[0010] In one possible implementation of the first aspect, if the quality problem of the first electronic device is caused by the software system of the first electronic device, the candidate electronic devices include the first electronic device and a target electronic device that includes the same software system as the first electronic device; if the quality problem of the first electronic device is caused by the hardware system of the first electronic device, the candidate electronic devices include the first electronic device and a target electronic device that includes the same hardware system as the first electronic device; if the quality problem of the first electronic device is caused by both the software system and the hardware system of the first electronic device, the candidate electronic devices include the first electronic device and a target electronic device that includes the same software system and hardware system as the first electronic device; if the quality problem of the first electronic device is a quality problem of the published digital resource itself, the candidate electronic devices include all the target electronic devices.

[0011] In this implementation method, quality problems caused by different factors are distinguished, and release control and quality warnings are implemented for candidate electronic devices including different software and hardware systems, which can realize release control and quality warnings in a timely and targeted manner.

[0012] In one possible implementation of the first aspect, the release control and quality warning for the candidate electronic device include: matching release control rules and release warning rules according to the quality problems of the first electronic device; performing release control on the candidate electronic device based on the release control rules; and providing quality warnings for the candidate electronic device based on the release warning rules. The quality warning includes pushing warning information to the release device, and the warning information is used to indicate that there are quality problems in the release of the candidate electronic device.

[0013] In this implementation, release control and quality warnings are achieved by matching quality issues with corresponding release control rules and release warning rules, which ensures the accuracy of release control and quality warnings.

[0014] In one possible implementation of the first aspect, release control is performed on candidate electronic devices based on release control rules, including: determining release control operations according to the release control rules; performing release control operations on candidate electronic devices; the release control operations include any one or more of the following: removing release resources, stopping release, and version rollback.

[0015] In this implementation, release control operations such as delisting, stopping release, and version rollback are performed on candidate electronic devices according to the instructions of the matched release control rules, which can prevent the spread and escalation of quality problems in a timely and targeted manner.

[0016] In one possible implementation of the first aspect, matching release control rules and release warning rules based on the quality problem of the first electronic device includes: performing rule matching based on release information; determining the release control rules corresponding to the digital resource in a rule base; the rule base pre-sets release control rules corresponding to different release device types, the release control rules including at least one release control rule and release warning rule corresponding to a severity level; determining a target rule from the release control rules corresponding to the digital resource, the release device type corresponding to the target rule being the same as the release device type of the first electronic device; matching the corresponding severity level based on the quality problem and the quality problem description corresponding to the quality problem; and in the target rule, using the release control rule and release warning rule corresponding to the matched severity level as the release control rule and release warning rule matched to the quality problem.

[0017] In this implementation, matching the release control rules and release early warning rules according to the severity level of the quality problem can ensure the compatibility of the selected release control rules and release early warning rules with the quality problem, thereby improving the accuracy of automatic control and quality early warning.

[0018] In one possible implementation of the first aspect, the quality data includes quality information, application component information, software system details, and hardware system details. Quality measurement is performed on each target electronic device based on the quality data, including: classifying multiple quality data sets to determine the quality data corresponding to each target electronic device; the data classification is based on the software system details and hardware system details; using preset quality problem indicators as a reference, quality measurement is performed based on the quality data corresponding to the target electronic device to determine whether the target electronic device has a quality problem; wherein the quality problem indicators include any one or more of crashes, app crashes, functional errors, and memory overflows, and the quality problem corresponds to the quality problem indicator.

[0019] In this implementation, different target electronic devices are measured for quality through data classification and quality problem indicators, thereby enabling refined quality measurement from the perspective of software and hardware systems.

[0020] In one possible implementation of the first aspect, the digital resource publishing method further includes: acquiring historical data, including historical public opinion data and historical quality data; determining historical quality issues and quality issue descriptions based on the historical quality data; analyzing historical public opinion data to determine the probability of public opinion occurrence corresponding to the historical quality issues; determining the status label of the historical quality issues based on the quality issue descriptions; and determining at least one severity level based on the probability of public opinion occurrence, status label, historical quality issues, and corresponding quality issue descriptions.

[0021] In this implementation, the severity levels of matching release control rules and release warning rules are determined by public opinion and historical quality data. This not only takes into account user feedback on quality issues, but also considers existing quality issues in the past, thereby improving user experience while ensuring the accuracy of quality issue measurement.

[0022] Secondly, this application provides a cloud device, including: one or more processors and a memory, the memory being coupled to the processors; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the cloud device performs the following steps:

[0023] The system acquires digital resources to be published and publication information; the publication information includes at least one software and hardware combination, with different software and / or hardware systems corresponding to different combinations; it determines at least one publishing device type based on the publication information and publishes the digital resources to the target electronic devices corresponding to the publishing device type; wherein the software and / or hardware systems of the target electronic devices corresponding to different publishing device types are different, while the software and hardware systems of the target electronic devices corresponding to the same publishing device type are the same; it receives quality data sent by multiple target electronic devices, the quality data corresponding to the published digital resources; it performs quality measurement on each target electronic device based on the quality data; when it is determined based on the quality measurement that a first electronic device with quality problems exists among the target electronic devices, it performs publication control and quality warning on the candidate electronic devices; the candidate electronic devices include the first electronic device and target electronic devices with the same publishing device type as the first electronic device.

[0024] In one possible implementation of the second aspect, digital resources include application components, software systems, resource data, or large model data.

[0025] In one possible implementation of the second aspect, if the quality problem of the first electronic device is caused by the software system of the first electronic device, the candidate electronic devices include the first electronic device and a target electronic device that includes the same software system as the first electronic device; if the quality problem of the first electronic device is caused by the hardware system of the first electronic device, the candidate electronic devices include the first electronic device and a target electronic device that includes the same hardware system as the first electronic device; if the quality problem of the first electronic device is caused by both the software system and the hardware system of the first electronic device, the candidate electronic devices include the first electronic device and a target electronic device that includes the same software system and hardware system as the first electronic device; if the quality problem of the first electronic device is a quality problem of the published digital resource itself, the candidate electronic devices include all the target electronic devices.

[0026] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the cloud device further performs the following steps: matching release control rules and release warning rules according to the quality problem of the first electronic device; performing release control on candidate electronic devices based on the release control rules; and providing quality warnings to candidate electronic devices based on the release warning rules, wherein the quality warnings include pushing warning information to the release device, the warning information being used to indicate that there is a quality problem in the release of the candidate electronic device.

[0027] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the cloud device further performs the following steps: determining a release control operation based on release control rules; performing a release control operation on the candidate electronic device; the release control operation includes one or more of the following: removing the release resource, stopping the release, and rolling back the version.

[0028] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the cloud device further performs the following steps: matching rules based on the published information, determining the publication control rules corresponding to the digital resources in the rule base; the rule base pre-sets publication control rules corresponding to different publication device types, the publication control rules including at least one publication control rule and publication warning rule corresponding to a severity level; determining a target rule from the publication control rules corresponding to the digital resources, the publication device type corresponding to the target rule being the same as the publication device type of the first electronic device; matching the corresponding severity level based on the quality problem and the quality problem description corresponding to the quality problem; in the target rule, using the publication control rule and publication warning rule corresponding to the matched severity level as the publication control rule and publication warning rule matched to the quality problem.

[0029] In one possible implementation of the second aspect, the quality data includes quality information, application component information, software system details, and hardware system details. When the aforementioned computer instructions are executed by the processor, the cloud device further performs the following steps: classifying the multiple quality data to determine the quality data corresponding to each target electronic device; the data classification is based on the software system details and hardware system details; using preset quality problem indicators as a reference, quality measurement is performed based on the quality data corresponding to the target electronic device to determine whether the target electronic device has a quality problem; wherein, the quality problem indicators include any one or more of crashes, app crashes, functional errors, and memory overflows, and the quality problem corresponds to the quality problem indicator.

[0030] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the cloud device further performs the following steps: acquiring historical data, including historical public opinion data and historical quality data; determining historical quality issues and quality issue descriptions based on the historical quality data; analyzing historical public opinion data to determine the probability of public opinion occurrence corresponding to the historical quality issues; determining the status label of the historical quality issues based on the quality issue descriptions; and determining at least one severity level based on the probability of public opinion occurrence, status label, historical quality issues, and corresponding quality issue descriptions.

[0031] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor in a cloud device, causes the cloud device to perform a digital resource publishing method as described in the first aspect and any possible implementation thereof.

[0032] Fourthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect and any possible implementation thereof. The computer may be the aforementioned cloud device.

[0033] Fifthly, embodiments of this application provide a chip, the chip including a processor, the processor being configured to invoke a computer program in memory to perform the method as described in any one of the first aspects.

[0034] Understandably, the beneficial effects achievable by the cloud device of any possible implementation of the second aspect, the computer-readable storage medium of the third aspect, the computer program product of the fourth aspect, and the chip of the fifth aspect can be referenced to the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0035] Figure 1This is a schematic diagram of a digital resource publishing system provided in an embodiment of this application;

[0036] Figure 2 This is a schematic diagram of the structure of a cloud device provided in an embodiment of this application;

[0037] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0038] Figure 4 A software structure block diagram of an electronic device provided in an embodiment of this application;

[0039] Figure 5 A schematic diagram illustrating the principle of a digital resource publishing method provided in an embodiment of this application;

[0040] Figure 6 A flowchart illustrating a digital resource publishing method provided in an embodiment of this application;

[0041] Figure 7 This application provides a schematic diagram of a deployment scenario model for the independent deployment of an application component.

[0042] Figure 8 A schematic diagram of an interface for an automatic update switch provided in an embodiment of this application;

[0043] Figure 9 A schematic diagram of an update prompt interface provided in an embodiment of this application;

[0044] Figure 10 A schematic diagram illustrating the classification of quality problems provided in this application embodiment;

[0045] Figure 11 A schematic diagram illustrating the principle of severity level determination provided in this application embodiment;

[0046] Figure 12 A schematic diagram of a rule matching process provided for an embodiment of this application;

[0047] Figure 13 A schematic diagram illustrating the principle of independent release, independent control, and early warning provided for embodiments of this application;

[0048] Figure 14 This is a structural block diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., are not necessarily different. Also, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0050] With the development of functionalities in electronic devices, increasing user demands, and iterative updates in software development technology, developers of electronic devices regularly or irregularly push out new digital resources needed by the system to improve existing functions, solve known problems, or provide users with new features, based on actual needs. These digital resource releases include application component releases (such as standalone applications or plugins in mobile phone systems), system software releases, resource data releases, and large-scale model data releases.

[0051] Currently, the distribution methods used by electronic device developers to release digital resources, such as application components, are typically synchronized with operating system (OS) updates (i.e., updates to the entire electronic device). That is, if there are application components to be released, they are packaged and released together with the updated OS version onto the electronic device. Therefore, because the application components are packaged together with the updated OS, the application components are updated simultaneously when the electronic device undergoes an OS update.

[0052] However, the problem with packaging and releasing applications along with OS updates is that some digital resources within the system, such as certain application components (like the phonebook / contacts in a mobile calling app), are not version-aware to users. That is, some application components are released without clearly distinguishing between different versions. Therefore, if an application component is packaged and released with an OS update, and quality issues arise on the electronic device side, it's impossible to pinpoint and analyze the cause of the problem because the version information doesn't indicate when the problematic application component was released.

[0053] In other words, this method of releasing digital resources along with system updates makes it impossible to accurately locate and measure the quality problems caused by the release when quality issues occur in the released digital resources, such as the released application components, making it difficult to accurately assess the impact of the quality problems.

[0054] Furthermore, because different electronic devices may run different operating systems (OS), OS updates are typically based on the electronic devices that the OS is compatible with, and are released to the corresponding electronic devices (the target devices) for each OS update. However, packaging and releasing digital resources along with OS updates means that the resources can only be released to the target devices that follow the OS update. This makes it difficult to categorize quality issues that arise after the release of digital resources, hindering both precise quality measurement and automated management of the release process, thus failing to prevent the spread and escalation of quality problems in a timely manner.

[0055] Based on this, in order to accurately locate and measure the quality problems that arise after the digital resources are published, and to achieve automated control of the publication so as to prevent the spread and escalation of quality problems in a timely manner, this application provides a digital resource publishing method, which can be applied to a digital resource publishing system composed of cloud devices and electronic devices.

[0056] For example, Figure 1 A schematic diagram of a digital resource publishing system is shown.

[0057] refer to Figure 1 The electronic device 100 can communicate with the cloud device 200 via a network. When it is necessary to publish digital resources to the electronic device 200, the cloud device 200 can independently push the digital resources to be published to the electronic device 100, thereby realizing the independent publication of digital resources. That is, in the digital resource publishing method provided in this application embodiment, the digital resources required by the electronic device 100 are decoupled from the system updates of the electronic device 100.

[0058] Decoupled publishing refers to the practice where the digital resources to be published are no longer packaged and published along with system updates. Instead, the cloud device independently pushes the digital resources to be published to the electronic device. Taking application component publishing as an example, this embodiment of the application no longer packages and publishes the application components to be published along with system updates. Instead, the cloud device pushes the application components to be published to the electronic device separately. In other words, this embodiment of the application will independently publish and push the digital resources required by the electronic device, such as application components, system software, resource data, and large model data, to the electronic device.

[0059] After a digital resource is published, the electronic device collects quality data corresponding to the published digital resource and reports the collected quality data to the cloud device.

[0060] After receiving the quality data reported by the electronic device, the cloud device classifies and measures the data (such as analyzing, statistically analyzing, and calculating) to identify quality issues arising on the electronic device's side after the digital resource is published. This allows for precise location and measurement of quality problems caused by the publication based on the quality data reported by the electronic device, thus enabling accurate assessment of the impact of these quality issues.

[0061] Furthermore, this application embodiment will also distinguish different types of electronic devices (i.e., distinguish the release objects) based on different carrier software systems (such as OS differences) and different hardware systems, and perform independent release and quality measurement on the dimension of different types of electronic devices, so as to facilitate the subsequent classification of quality problems and realize refined quality measurement, automatic control and quality early warning.

[0062] Furthermore, the cloud device will match corresponding release control rules based on the identified quality issues. In some embodiments, release control rules include release control rules and release warning rules. Then, the cloud device will automatically control and issue quality warnings for this release based on the matched release control rules, such as release control rules and release warning rules. For example, when a quality issue is severe, the cloud device can perform operations such as removing the release resource, stopping the release, or instructing the release to be rolled back based on the release control rules. This enables automated release control, allowing for timely prevention of the spread and escalation of quality issues after they occur.

[0063] In some embodiments, the cloud device 200 described above may be a server or other computer device. The server may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers.

[0064] In other embodiments, the cloud device 200 described above may also be a cloud server that provides cloud computing services. These cloud computing services include, but are not limited to, cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms.

[0065] It is understood that the embodiments of this application do not impose any special restrictions on the specific type of the cloud device 200.

[0066] For example, Figure 2 A schematic diagram of the structure of a cloud device is shown.

[0067] The cloud device 200 may include one or more processors 201, one or more memories 202, a power supply component 203, an interface component 204, etc. The processor 201 may include one or more processing units, which can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0068] In this embodiment, the processor 201 in the cloud device 200 can perform quality measurement on the quality data reported by the electronic device to determine the resulting quality problems. Then, the processor 201 matches corresponding release control rules and release warning rules based on the quality problems, thereby achieving automated control and quality warnings for the release process.

[0069] Memory 202 can be used to store computer executable program code, including instructions. In some embodiments, memory 202 can be located in processor 201 for storing instructions and data. In some embodiments, memory 202 in processor 201 can be a cache memory. This memory can store instructions or data that the processor has used or that are used frequently. If the processor needs to use the instruction or data, it can directly retrieve it from this memory. This avoids repeated accesses, reduces processor waiting time, and thus improves system efficiency.

[0070] Power supply component 203 is used to power cloud device 200. Interface component 204 is used to provide various types of interfaces, such as a network interface for connecting to a network. Interface component 204 can also provide a USB interface for connecting peripheral devices.

[0071] It is understood that the structure of the cloud device illustrated in the embodiments of this application does not constitute a specific limitation on the cloud device 200. In other embodiments of this application, the cloud device 200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0072] In some embodiments, the electronic device 100 communicating with the cloud device 200 may include at least one of the following: mobile phone, foldable electronic device, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, wearable device, in-vehicle device, smart home device, or smart city device. This application embodiment does not impose any special limitation on the specific type of electronic device.

[0073] For example, Figure 3 A schematic diagram of the structure of an electronic device is shown.

[0074] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) connector 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera module 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer 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, etc.

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

[0076] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0077] The processor 110 can generate operation control signals based on the instruction opcode and timing signals to control the instruction fetching and execution.

[0078] Specifically, in this embodiment of the application, after receiving digital resources published by the cloud device 200, the electronic device 100 can use its processor 110 to run the received digital resources to complete the installation / update of the digital resources. For example, the processor 110 can run application components published by the cloud device to complete the installation / update of the application components.

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

[0080] For example, in this embodiment of the application, the electronic device can communicate with the cloud device via wireless communication to receive digital resources published by the cloud device. For instance, the electronic device 100 can receive digital resources such as application components, software systems, resource data, and large model data published by the cloud device 200 via wireless communication.

[0081] In some embodiments, the software system of the electronic device 100 may adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture of Android... TM Taking the system as an example, the software structure of electronic device 100 is illustrated.

[0082] Figure 4 A software architecture block diagram of an electronic device is shown.

[0083] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android...TM The system is divided into five layers, from top to bottom: application layer, application framework layer, Android runtime (ART) and native C / C++ libraries, hardware abstraction layer (HAL) and kernel layer.

[0084] The application layer can include a series of application packages. These application packages can include applications such as gallery, calendar, maps, WLAN, music, SMS, calling, navigation, Bluetooth, and video.

[0085] Understandably, applications in the application layer can be downloaded to electronic devices through application component publishing or have their application functions installed / updated through application component publishing.

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

[0087] like Figure 4 As shown, the application framework layer may include a window manager, activity manager, input manager, resource manager, notification manager, view system, content provider, etc.

[0088] The window manager provides window management services (WMS). The content provider stores and retrieves data, making it accessible to applications. The view system includes visual controls, such as controls for displaying text and images. The view system is used to build applications. The resource manager provides applications with various resources, such as localized strings, icons, images, layout files, video files, etc. The notification manager allows applications to display notifications in the status bar. The activity manager provides activity management services (AMS). The input manager provides input management services (IMS).

[0089] The Android runtime consists of the core libraries and the Android runtime itself. The Android runtime is responsible for translating source code into machine code. The core libraries primarily provide basic Java class library functionality. Native C / C++ libraries can include multiple functional modules, such as: surface manager, media framework, libc, OpenGL ES, SQLite, Webkit, etc.

[0090] The Hardware Abstraction Layer (HAL) runs in user space, encapsulates kernel drivers, and provides calling interfaces to higher layers. The kernel layer acts as the layer between hardware and software. Figure 4 As shown, the Hardware Abstraction Layer (HAL) can include display HAL, audio HAL, camera HAL, Bluetooth HAL, etc. The kernel layer contains at least display drivers, audio drivers, camera drivers, and Bluetooth drivers.

[0091] The digital resource publishing method proposed in this application will be described in detail below with reference to the accompanying drawings. It should be noted that the digital resource publishing methods in the following embodiments can all be implemented in electronic devices and cloud devices equipped with the above-described hardware structure. Furthermore, for ease of understanding and description, the following embodiments of this application will primarily use the publishing of application components in digital resource publishing as an example to illustrate the digital resource publishing method. It is understood that the publishing processes and principles of system software publishing, resource data publishing, and large model data publishing in digital resource publishing are the same as those of application component publishing. For details, please refer to the following description of application component publishing; this application embodiment will not repeat them here.

[0092] Figure 5 A schematic diagram illustrating the principle of a digital resource publishing method is shown.

[0093] refer to Figure 5 The digital resource publishing method provided in this application mainly includes four major steps. These four major steps are: independent publishing of application components (i.e., independent publishing of digital resources), quality data reporting, quality measurement, and publishing control and quality early warning.

[0094] In this context, independent deployment of application components refers to the independent deployment of application components. In this embodiment, independent deployment includes not only decoupling deployment from system updates but also differentiating between different types of electronic devices (deployment device types). That is, independent deployment is performed at the level of different types of electronic devices, with independent automatic control and quality warnings for the deployment of different types of electronic devices. Specific implementation details of independent deployment can be found in the descriptions in S1-S4 below.

[0095] Quality data reporting involves the electronic device collecting quality data and sending it to the cloud device. The reported quality data is used for analyzing and measuring quality issues. For details on the implementation of quality data reporting, please refer to the descriptions in S5 and S6 below.

[0096] Quality measurement, release control, and quality early warning primarily involve identifying quality issues based on reported quality data, and then matching corresponding release control rules and release early warning rules to these issues. This allows for automatic release control and quality early warning based on the matched release control and early warning rules. For specific implementation details regarding quality measurement, release control, and quality early warning, please refer to the descriptions in sections S7-S11 below.

[0097] In summary, in this application embodiment, considering that the same application component (i.e., the same digital resource) may cause different quality problems when deployed to different types of electronic devices (different software and hardware combinations), this application embodiment, while decoupling the deployment of application components, also distinguishes between quality problems generated by different types of electronic devices to achieve refined location and measurement of quality problems, and to achieve refined automatic control of deployment so as to prevent the spread and escalation of quality problems in a timely manner after they occur. Furthermore, this application embodiment also distinguishes between electronic devices with different software and hardware combinations for separate deployment of application components, and separately performs automated control and quality warnings for deployment on electronic devices with different software and hardware combinations.

[0098] Figure 6 A flowchart illustrating a digital resource publishing method is shown, including steps S1-S11. The following, in conjunction with... Figure 6 The digital resource publishing method provided in the embodiments of this application will be described in detail.

[0099] S1, cloud devices obtain application components and release information.

[0100] When there is a need to publish an application component, the cloud device can obtain the corresponding application component to be published and the publishing information. Electronic devices that receive the published application component from the cloud device can complete the installation / update of the application component by running it. The publishing information is instructions on how to publish the application component.

[0101] In some embodiments, such as Figure 6 As shown, cloud devices can obtain the application components and publishing information that need to be published by receiving application components and publishing information sent by the publisher through the publishing device.

[0102] Specifically, when there is a need to publish an application component, the publisher can send an application component publishing command to the cloud device through the interactive interface provided by the cloud device on the publishing device. The application component publishing command sent by the publisher carries the application component to be published, as well as the corresponding publishing information for that application component.

[0103] In other words, when there is a need to publish digital resources such as application components, system software, resource data, and large model data, the publisher can issue the corresponding digital resource publishing command through the interactive interface provided by the cloud device on the publishing device. This digital resource publishing command carries the digital resource to be published, as well as the corresponding publishing information. The electronic device receiving the published digital resource can complete the installation or update of the digital resource by running it.

[0104] In some embodiments, the release information includes different combinations of software and hardware, and the electronic devices corresponding to these combinations of software and hardware are the release objects specified in this release. In this application embodiment, the release object is also referred to as the target electronic device.

[0105] As shown in Table 1 below, in this embodiment of the application, the published information may specifically include the publishing channel, software system (OS), and device model. Different device models correspond to different hardware systems, which may be due to differences in chips and / or other hardware. For example, the difference between electronic device A and electronic device B may be due to different chips, different hardware other than chips, or different chips and other hardware.

[0106] Table 1

[0107]

[0108]

[0109] In other words, when cloud devices publish application components, they need to select the target electronic device for application component publishing according to the software and hardware combination indicated in the publishing information, that is, they need to push the application components to be published to the target electronic device specified in the publishing information.

[0110] For example, take Table 1 above as an example. Figure 7 A schematic diagram of a deployment scenario model for independently deploying application components is shown.

[0111] like Figure 7As shown, regardless of whether the release channel is beta or commercial, when a cloud device releases a received application component, it needs to independently push and release the application component to the target electronic device based on the release information shown in Table 1 above. The target electronic devices indicated in Table 1 specifically include electronic device A (Category 1 electronic device), electronic device B (Category 2 electronic device), and electronic device C (Category 3 electronic device) running OS1. Simultaneously, the cloud device also needs to independently push and release the application component to electronic device A (Category 4 electronic device), electronic device B (Category 5 electronic device), and electronic device C (Category 6 electronic device) running OS2. Therefore, the release device types corresponding to the release information shown in Table 1 include Category 1, Category 2, Category 3, Category 4, Category 5, and Category 6 electronic devices.

[0112] In some embodiments, the transmission format for application component distribution can be data packets. That is, electronic devices can complete the installation / update of application components by running application component data packets.

[0113] S2, cloud devices match rules based on the published information to determine the corresponding publication control rules for application components.

[0114] A rule base is a collection of pre-defined release control rules. In this embodiment, the release control rules in the rule base include release control rules and release warning rules. Release control rules are rules for automatically managing releases and can be understood as automatic release control strategies. In some embodiments, automatic release control strategies may specifically include removing release resources, stopping releases, or rolling back. Release warning rules are rules used to indicate the issuance of warning information.

[0115] In some embodiments, such as Figure 6 As shown, the rule base can be configured by the configuration personnel through the configuration module.

[0116] In this application embodiment, in order to achieve refined quality measurement, automatic control of release, and quality early warning, this application embodiment mainly distinguishes between different types of electronic devices (including different hardware and software combinations), independently releases application components, and independently controls and provides quality early warnings for release based on different types of electronic devices.

[0117] Based on this, the rule base stores corresponding release control rules for different types of electronic devices. Furthermore, this embodiment of the application subsequently needs to match the corresponding release control rules and release warning rules in the rule base based on the quality data uploaded by the target electronic device. Therefore, to facilitate the rapid matching of the corresponding release control rules and release warning rules in the rule base, the cloud device first performs rule matching based on the release information corresponding to the application component, thereby determining the release control rules corresponding to the released application component in the rule base.

[0118] In other words, the rule base includes release control rules and release warning rules corresponding to different types of electronic devices. For example, taking the first and second types of electronic devices mentioned above, the rule base includes release control rules and release warning rules corresponding to the first type of electronic devices. Simultaneously, the rule base also includes release control rules and release warning rules corresponding to the second type of electronic devices. Of course, the rule base can also include release control rules and release warning rules corresponding to other types of electronic devices, such as the third, fourth, fifth, and sixth types.

[0119] Meanwhile, for the release of application components, this application embodiment has corresponding release information. As described in S1 above, the release information indicates the release object (target electronic device) of the application component, that is, the release information corresponding to the application component indicates the different types of electronic devices that need to be pushed to the application component.

[0120] Therefore, when the rule base includes release control rules for different types of electronic devices, and the measurement, automatic control, and early warning of quality issues are based on different application components, cloud devices can perform rule matching in advance based on release information to determine the release control rules corresponding to the application component from the rule base in order to facilitate the rapid matching of the corresponding rules in the rule base.

[0121] For example, taking Table 1 above as an example, if the publishing information corresponding to the application component's publication indicates that the publishing objects include Class 1 electronic devices, Class 2 electronic devices, and Class 3 electronic devices, then the cloud device can match and determine from the rule base that the publishing control rules corresponding to Class 1 electronic devices, Class 2 electronic devices, and Class 3 electronic devices are the publishing control rules corresponding to the application component. Furthermore, the publishing control rules specifically include publishing control rules and publishing warning rules.

[0122] In simple terms, rule matching is the process of filtering out release control rules corresponding to the released application components from the rule base based on the release information. This associates the corresponding release control rules with the released application components so that the release control rules corresponding to the released application components can be directly located. Finally, the release control rules and release warning rules needed are determined from the release control rules corresponding to the released application components.

[0123] In some embodiments, if multiple different application components are released at the same time, each application component can determine the corresponding release control rules by matching the release information from the rule base.

[0124] Understandably, if different application components share the same publishing target, they can be associated with the same publishing control. For example, if both application component A and application component B need to be published to the first type of electronic device, then the publishing control for the first type of electronic device will be the publishing control for both application component A and application component B.

[0125] S3: Cloud devices publish application components to target electronic devices based on published information.

[0126] After receiving the application component publishing instruction from the publisher, the cloud device responds to the instruction by determining the target electronic device based on the different hardware and software combinations indicated in the publishing information. Then, it pushes the corresponding application component to be published to the target electronic device, completing the application component publishing. In this embodiment, the target electronic device refers to the publishing object specified in the publishing information, i.e., the electronic device corresponding to the different hardware and software combinations specified in the publishing information.

[0127] Taking the information released in Table 1 above as an example, the target electronic devices include Class I electronic devices, Class II electronic devices, Class III electronic devices, Class IV electronic devices, Class V electronic devices, and Class VI electronic devices.

[0128] In other words, taking the release information shown in Table 1 as an example, the cloud device needs to independently push the application components to the first type of electronic device, the second type of electronic device, the third type of electronic device, the fourth type of electronic device, the fifth type of electronic device, and the sixth type of electronic device. For example, assuming there are five electronic devices corresponding to the first type of electronic device, the cloud device needs to push the application components to these five electronic devices respectively. It is understood that the five devices are merely an example illustrating this application's embodiments; the number of different types of electronic devices depends on the actual situation, and this application's embodiments do not impose any limitations on this.

[0129] In some embodiments, such as Figure 6As shown, the cloud-based equipment includes a publishing system and a monitoring system. Steps S1-S3 described above can be implemented through the interaction between the publishing system and the monitoring system.

[0130] Specifically, the deployment of the application components described in S1 and S3 can be performed by the deployment system in the cloud device. For example... Figure 6 As shown, the publishing system includes an application component publishing module. That is, the application component publishing module in the publishing system can receive application component publishing instructions issued by the publisher. Responding to the application component publishing instruction, the application component publishing module pushes the application component carried by the instruction to the target electronic device, completing the publishing of the application component.

[0131] The implementation of rule matching based on release information to determine the release control rules corresponding to application components, as described in S2, can be executed by the monitoring system in the cloud device. For example... Figure 6 As shown, the application component publishing module in the publishing system can send the received application component and publishing information to the monitoring system after receiving them. The monitoring system then performs rule matching in the rule base based on the received publishing information to determine the publishing control rules corresponding to the application component. These publishing control rules can specifically include publishing control rules and publishing early warning rules.

[0132] S4, the target electronic device updates application components.

[0133] Once the target electronic device receives the application component pushed and released by the cloud device, it can run the application component to complete the installation / update of the application component.

[0134] In some embodiments, if the user allows the target electronic device to update automatically (e.g., the automatic update switch on the target electronic device is turned on), then the target electronic device can trigger the automatic execution of the application component upon receiving it to complete the installation / update. If the user does not allow the target electronic device to update automatically (e.g., the automatic update switch on the target electronic device is turned off), then the target electronic device can provide an update prompt upon receiving the application component, indicating to the user that an update is available. Furthermore, if the target electronic device receives an update request from the user, it will respond by running the application component to complete the installation / update.

[0135] In other embodiments, the cloud device may first push update information to the target electronic device based on the published information, notifying the target electronic device that there are application components available for download / update. Then, if the target electronic device can update automatically, it automatically downloads the corresponding application component from the cloud device and runs the downloaded application component to complete the installation / update. If the target electronic device cannot update automatically, it can display an update notification pushed by the cloud device, further informing the user that there are application components available for download / update. Then, if the target electronic device receives an update request from the user, it responds by downloading the corresponding application component from the cloud device and running the downloaded application component to complete the installation / update. This method, compared to the cloud device directly pushing application components, has the same implementation principle and function; the difference lies in the additional step of the electronic device downloading the application component from the cloud device.

[0136] For example, taking a mobile phone as an example, Figure 8 A schematic diagram of the interface for an automatic update switch is shown. Figure 9 A schematic diagram of an update prompt interface is shown.

[0137] refer to Figure 8 The phone can respond to the user's touch operation on the "Settings" app icon on the main interface 1, enter the settings, and display the settings interface 3. For example... Figure 8 As shown, settings interface 3 can include an update settings option. Then, the phone can respond to the user's touch operation on the update settings and display update settings interface 4. For example... Figure 8 As shown, the update settings interface 4 includes an automatic update control option 701, which includes an automatic update switch 702. The phone can enable / disable automatic updates in response to the user clicking the automatic update switch 702.

[0138] Therefore, when automatic updates are enabled, i.e., when the user turns on the automatic update switch 702 in the automatic update control option 701, the phone can automatically run the application component after receiving it from the cloud device to complete the installation / update. When automatic updates are disabled, i.e., when the user turns off the automatic update switch 702 in the automatic update control option 701, the phone can first display an update prompt message after receiving the application component pushed from the cloud device, to inform the user that there is an application component available for update, such as... Figure 9 As shown. After the phone receives the user's update request, it then responds by running the application component to complete the installation / update. For example... Figure 9 As shown, the update operation can be a user's touch operation of "click to update".

[0139] It should be noted that, Figure 8 and Figure 9 This is merely an example of an embodiment of this application and does not constitute any limitation on the settings, update prompts, or update operations for automatic updates.

[0140] S5, the target electronic device collects quality data.

[0141] S6, the target electronic device reports quality data.

[0142] After installing / updating application components, the target electronic device collects quality data to monitor for any quality issues or potential problems. This collected data is then reported to a cloud-based device for processing.

[0143] like Figure 6 As shown, because the cloud device receives quality data reported by all target electronic devices, the quality data reported by the target electronic devices can be stored in the cloud device's data warehouse (database) for easier management. Subsequently, the cloud device can retrieve the quality data from the data warehouse.

[0144] In this embodiment, it is considered that quality problems may be caused not only by the quality of the application components themselves, but also by incompatibility with the software or hardware system. In other words, quality problems are caused by multiple factors.

[0145] like Figure 10 The diagram shown illustrates a classification of quality problems.

[0146] refer to Figure 10 In this application embodiment, the factors causing quality problems are mainly divided into three categories, from top to bottom: application component quality problems, software system-induced quality problems, and hardware system-induced quality problems.

[0147] Among these, application component quality issues are inherent to the quality of the deployed application components themselves, making them a common problem. This means that if a quality issue is caused by the quality of an application component, then the deployment of that application component needs to be managed and controlled holistically. For example, when a quality issue arises due to an application component, the cloud device will not differentiate between different types of electronic devices for targeted deployment control and quality alerts; instead, it will apply deployment control and quality alerts to all electronic devices (i.e., all target electronic devices receiving the deployment).

[0148] Quality issues arising from software systems are generally due to incompatibility between the software system and application components. Such issues typically only occur in electronic devices with similar software systems. Therefore, release control and quality alerts can be implemented only for these devices. Similarly, quality issues arising from hardware systems are likely due to incompatibility between the hardware system and application components. These issues are also highly probable to occur in electronic devices with similar hardware systems. Therefore, release control and quality alerts should only be implemented for these devices.

[0149] Therefore, in order to facilitate cloud devices in distinguishing between the quality of application components themselves, quality problems caused by different software systems, and quality problems caused by different hardware systems, so as to achieve accurate location and measurement of quality problems, in this embodiment of the application, the quality data reported by the target electronic device includes quality information, application component information, detailed information of the software system on the device side, detailed information of the hardware system on the device side (including detailed information of the chip and other hardware on the device side), and channel information, etc.

[0150] S7, cloud-based devices classify and measure quality data to identify quality issues and their descriptions.

[0151] After receiving the quality data reported by the target electronic device, the cloud device needs to classify the quality data. Data classification is used to distinguish the quality data corresponding to different types of electronic devices. It is understood that in this embodiment, the classification of different types of electronic devices is based on different software systems and hardware systems (i.e., different software and hardware combinations). Therefore, the quality data classification can be performed using detailed information from the device's software system and hardware system.

[0152] After classifying the quality data, the cloud device performs quality measurements on the corresponding quality data for each target electronic device to determine whether any quality issues arise from the release of application components. The quality measurement involves analyzing, statistically processing, and calculating the quality data according to specified quality issue indicators to identify the quality issues caused by the released application components and their corresponding descriptions. In this way, the cloud device can identify the quality issues caused by the application components after their release for different types of electronic devices.

[0153] In some embodiments, quality issues may include crashes, app crashes, functional errors, memory overflows, etc. A quality issue description is a description of the overall situation of the quality issue, which may include, for example, the frequency, timing, etc.

[0154] Understandably, quality issues and quality issue indicators are correlated. In some embodiments, quality issue indicators can be pre-defined in a rule base. That is, the rule base pre-defines the quality issue indicators that need to be considered when measuring quality issues.

[0155] Furthermore, such as Figure 6 As shown, when cloud devices perform quality measurement, they can obtain the corresponding quality problem indicators from the rule base, and then perform quality problem analysis and measurement based on the quality problem indicators set in the rule base.

[0156] For example, the pre-defined quality issue indicators in the rule base include crashes, freezes, functional errors, and memory overflows. Therefore, when cloud devices perform quality analysis and measurement based on quality data, the quality issue indicators they need to consider include crashes, freezes, functional errors, and memory overflows. In other words, cloud devices will perform quality measurement from the perspective of quality issue indicators such as crashes, freezes, functional errors, and memory overflows to determine whether the released application components have quality issues such as crashes, freezes, functional errors, and memory overflows.

[0157] Understandably, specific quality problem indicators, quality problems, and corresponding quality problem descriptions can be set according to actual needs, such as based on the characteristics of the actual digital resources released, and this application does not impose any restrictions on them.

[0158] S8, cloud devices match and release warning rules and release control rules based on quality issues and quality issue descriptions.

[0159] After the cloud device obtains the quality problem and its description, it determines the rules corresponding to the published application component from the rule base because the cloud device has already performed rule matching based on the release information of the application component.

[0160] Meanwhile, the quality data reported by the target electronic device includes application component information, software system details, and hardware system details. Therefore, the cloud device can use this information to determine the rule (i.e., the target rule) corresponding to the quality data from the rule base. Furthermore, after determining the quality problem and its description through the quality data, the cloud device can match the determined quality problem and its description with the release control rule and release warning rule from the target rules.

[0161] For example, suppose the quality issue identified by the cloud device is a crash, and the corresponding quality issue description includes that the crash occurred n times, with an interval of n seconds between each crash. Then, the cloud device can match the corresponding release control rules and release alert rules from the target rules based on information such as the occurrence of crashes, the number of crashes being n, and the interval between each crash being n seconds.

[0162] In some embodiments, to achieve more refined quality metrics, different quality issues and quality issue descriptions can be further categorized into different degrees of severity. For example, for quality issue descriptions that can be quantified, such as frequency or recurrence, thresholds corresponding to different degrees of severity can be set, thereby determining the severity based on the relationship between frequency / recurrence and the threshold.

[0163] For example, the severity can be divided into five severity levels, which can be "L1: fatal, L2: very serious, L3: serious, L4: important, and L5: experiential".

[0164] Correspondingly, different release control rules in the rule base can be pre-configured with release control rules and release alert rules corresponding to various severity levels. Furthermore, when matching release alert rules and release control rules, cloud devices can first match the corresponding severity level based on the quality issue and its description. After matching a severity level, the release control rules and release alert rules corresponding to that severity level are the release control rules and release alert rules that match the quality issue and its description.

[0165] For example, quality issue 1 is a crash, and it occurs n times, with each crash occurring at intervals of n seconds. Quality issue 2 is a crash, and it occurs 3n times, with each crash occurring at intervals of 2 / n seconds. It is clear that although both quality issues 1 and 2 are crashes, the number of crashes and the time intervals are different. The crashes corresponding to quality issue 2 are significantly more severe than those of quality issue 1. Therefore, when matching release control rules and release warning rules, the release control rules and release warning rules matched for quality issue 1 and quality issue 2 may be different. Because quality issue 2 is more severe, the release control rules and release warning rules matched for quality issue 2 can be more stringent.

[0166] In some embodiments, the quality issues of different severity levels and their descriptions, namely the five preset severity levels in the examples above, can be specifically determined in advance using historical public opinion data and historical quality data.

[0167] For example, Figure 11 A schematic diagram illustrating the principle of severity level determination is shown.

[0168] First, obtain historical data. For example... Figure 11As shown, historical data includes historical public opinion data and historical quality data (i.e., historical data corresponding to quality issue indicators). Historical public opinion data allows analysis to determine user attitudes towards different quality issues and their descriptions, facilitating the classification of these issues and descriptions into different levels of severity based on user attitudes. For example, quality issues and descriptions that elicit strong user rejection or aversion can be classified as more severe. Historical public opinion data can be obtained from publicly available social media platforms. Historical quality data, on the other hand, directly reflects the historical data related to quality issues and their descriptions.

[0169] Then, analyze historical data. For example... Figure 11 As shown, historical data analysis can be performed using a pre-trained big data analytics model. Historical data, including public opinion data and historical quality data, are input into the big data analytics model. Based on this data, the model outputs different quality issues, descriptions of these quality issues, and the probability P of each quality issue and its corresponding public opinion occurrence (in percentages). It's understandable that quality issues identified based on historical data are historically existing quality issues, i.e., historical quality issues.

[0170] The probability of public opinion generation P represents the probability that the quality issue and its description may cause users to generate public opinion. The higher the probability of public opinion generation P, the higher the degree of discussion caused by the quality issue and its description, which means that the user dissatisfaction caused by the quality issue may also be higher.

[0171] In some embodiments, such as Figure 11 As shown, the probability P of public opinion incidents corresponds to probability levels P1, P2, P3, P4, and P5. Furthermore, P1 > P2 > P3 > P4 > P5, meaning that quality issues and their descriptions at P1 have the highest probability of causing public opinion incidents, while quality issues and their descriptions at P5 have the lowest probability.

[0172] Furthermore, since historical data consists of data that has already occurred, historical quality data can be a collection of historical quality data corresponding to multiple electronic devices. Thus, after analysis using a big data analytics model, the description of quality problems can also be statistically analyzed from the perspective of the electronic device. For example, in addition to descriptions such as frequency, occurrence, and time, the description of a quality problem can also include the type and number of electronic devices experiencing the problem.

[0173] It's understandable that the probability of a public opinion crisis arising from quality issues can vary depending on the frequency, timing, and number of electronic devices involved. For example, the more serious the quality issue, the higher the probability of it triggering public discussion. Therefore, different probabilities P of public opinion crisis may correspond to the same quality issue, but the descriptions of the quality issue may differ. For instance, both P1 and P2 correspond to crashes, but the frequency, timing, or number of electronic devices involved in the crashes under P1 is higher than that under P2.

[0174] Finally, the severity of public opinion incidents can be categorized based on the probability P of each incident, corresponding to the quality issues at that probability P. For example... Figure 11 As shown, quality issues can be matched with corresponding indicator labels (status labels) based on their descriptions. For example, the indicator labels (status labels) for quality issues could be continuity, frequency, perceived impact, functionality, or issue type. Furthermore, by combining the probability P of public opinion generation with the indicator labels corresponding to the quality issues, a severity level can be assigned to each quality issue and its description. Figure 11 As shown, the severity levels can be L1 to L5.

[0175] For example, generally speaking, the higher the probability P of public opinion occurrence, the higher the probability of causing public discussion. From the perspective of a good user experience, the severity of the corresponding quality problem and its description can be considered relatively serious. Therefore, the higher the probability P of public opinion occurrence, the higher the corresponding severity level can be.

[0176] For example, different indicator labels represent different phenomena of quality problems. For instance, continuous quality problems are more serious than frequent quality problems. Therefore, quality problems labeled as continuous can be more severe than those labeled as frequent.

[0177] In some embodiments, different thresholds can be set for each status label, meaning multiple different thresholds can be set under each indicator label. These thresholds can then be used to further classify the severity of quality issues within each status label. For example, taking a continuous crash quality issue as an example, although it can be determined that the crashes are continuous, the severity of the continuity can be further differentiated based on thresholds such as the duration and frequency of the continuous crashes. This provides more detailed reference data for classifying the severity levels.

[0178] It should be noted that the rules for classifying quality issues and their descriptions into different severity levels based on the probability P of public opinion arising from the quality issues and their corresponding descriptions, as well as the indicator labels, can be set according to actual needs, and this application embodiment does not impose any limitations on this. Furthermore, the five severity levels described in this application embodiment are merely one example and are not limited thereto; more or fewer severity levels can be established according to actual needs.

[0179] For example, Figure 12 This illustrates a flowchart of a rule-matching process. The following is combined with... Figure 12 This section provides an overall explanation of the rule matching process in the publication of digital resources.

[0180] like Figure 12 As shown, assume that the rule base includes rule A corresponding to electronic device A (i.e., the publishing control rule corresponding to electronic device A), rule B corresponding to electronic device B (the publishing control rule corresponding to electronic device B), and rule C corresponding to electronic device C (the publishing control rule corresponding to electronic device C).

[0181] Accordingly, based on different severity levels, Rule A, Rule B, and Rule C have different release control rules and release alert rules. For example, refer to... Figure 12 Rule A includes Rule L1, meaning it includes release control rules and release warning rules corresponding to L1. Similarly, Rule A also includes Rules L2, L3, L4, and L5, corresponding to L2 to L5, which will not be elaborated further. Of course, as not shown in the attached diagram, Rules B and Rule C also have corresponding release control rules and release warning rules for severity levels L1 to L5.

[0182] The rule matching process is as follows:

[0183] like Figure 12 As shown, firstly, after the cloud device receives the application component release instruction for application component A, the cloud device will first perform rule matching in the rule base based on the release information corresponding to application component A, thereby determining the release control rules corresponding to the application component A that needs to be released. For example... Figure 12 As shown, assuming that the target electronic devices for application component A to be published include electronic device A and electronic device B, then rule A corresponding to electronic device A and rule B corresponding to electronic device B can be determined in the rule base as the publishing control rules corresponding to application component A.

[0184] Next, after application component A is published and the cloud device receives the quality data reported by the target electronic device, the target rule corresponding to the quality data can be determined by matching the application component information and the target electronic device's detailed hardware and software information within the quality data. For example... Figure 12 As shown, if the application component information in the quality data reported by the target electronic device corresponds to application component A, and the detailed hardware and software information in the reported quality data corresponds to electronic device A, then rule A can be matched and determined to be the target rule.

[0185] Furthermore, cloud-based devices can match corresponding release control rules and release alert rules in Rule A based on the quality issues and quality issue descriptions identified by quality metrics. For example... Figure 12 As shown, by matching, rule L1 can be identified as a matching release control rule and release alert rule.

[0186] S9, cloud-based devices issue quality warnings based on published warning rules.

[0187] After the cloud-based device matches the quality issue and its description to the corresponding alert release rule, it can issue a quality alert according to the rule's instructions. For example... Figure 6 As shown, cloud-based devices can issue quality alerts by pushing alert information to the publishing device, notifying the publisher that a quality issue has occurred in the release of the application component. Subsequently, after receiving the quality alert, the publisher can decide whether to manually control the release of the application component based on actual needs.

[0188] For example, if the decision requires manual control, the publisher can send a command from the publishing device to the cloud device to stop the publishing process. The cloud device will then execute the stop operation, preventing target electronic devices that have not yet received the application component push or completed the application component installation / update, thus preventing quality issues from occurring. Furthermore, the publisher can also send commands to roll back published application components or patch published application components to prevent quality problems from spreading and worsening.

[0189] It should be noted that the methods for issuing early warning rules and quality early warnings can be set according to actual business needs, and this application embodiment does not impose any limitations on this.

[0190] S10, cloud devices determine the publishing control operation based on the publishing control rules.

[0191] S11, cloud devices perform release control operations.

[0192] After matching the quality issue and its description to the corresponding release control rule, the cloud device can determine the release control action based on that rule. For example, release control actions could include removing the released resource, stopping the release, or rolling back the application. In other words, once a quality issue is identified in a released application component, the cloud device can automatically manage the release using the matched release control rule to prevent the issue from escalating.

[0193] In some embodiments, automatic management of cloud devices can involve executing a stop-release operation, i.e., controlling the application component to stop being released. This can promptly prevent quality issues from occurring on target electronic devices that have not yet received the application component push or completed the application component installation / update. Automatic management can also involve the cloud device issuing commands to control the rollback of already released application components, thereby resolving quality issues.

[0194] In some embodiments, the implementation of steps S7-S11 above can also be performed by the publishing system and the monitoring system. Specifically, such as... Figure 6 As shown, the implementations of S7, S8, and S9 can be performed by the monitoring system of the cloud device. The implementations of S10 and S11 can be performed by the publishing system of the cloud device. The execution of the publishing control operations can be specifically implemented by the application component modules in the publishing system.

[0195] In some embodiments, because the application component publishing in this application is based on publishing information independently to different types of electronic devices, and the quality data collection is targeted at each target electronic device that receives the application component publishing, if a target electronic device experiences a quality problem due to the published application component, the cloud device can automatically control the publishing only for that type of electronic device, thereby achieving timely and targeted automatic control.

[0196] For example, if the software system details and hardware system details (i.e., software and hardware details) in the quality data reported by the target electronic device determine that there is a first electronic device with a quality problem in the target electronic device, then automatic control and quality warning are performed separately for the first electronic device and target electronic devices of the same type as the first electronic device (i.e., candidate electronic devices).

[0197] For example, assuming the first electronic device belongs to the first category of electronic devices, the cloud device will find a release control rule that matches the quality problem and quality problem description of the first electronic device from the rules corresponding to the first category of electronic devices in the rule base. Then, after determining the release control operation to be performed based on the matching release control rule, the cloud device can perform the determined release control operation only for the first category of electronic devices.

[0198] In other words, if a quality problem occurs in the first electronic device after the application component is released, and the quality problem is caused by the software system of the first electronic device (such as the software system being incompatible with the application component), then the cloud device can perform release control operations on the first electronic device and on target electronic devices with the same software system as the first electronic device.

[0199] Alternatively, if a quality issue occurs in the first electronic device after the application component is released, and the quality issue is caused by the hardware system of the first electronic device (such as a chip or other hardware that is incompatible with the application component), then the cloud device can perform release control operations on the first electronic device and on target electronic devices with the same hardware system as the first electronic device.

[0200] Alternatively, if the quality problem is caused by both the software and hardware systems of the first electronic device, then the cloud device can perform release control operations on the first electronic device and on target electronic devices with the same software and hardware systems as the first electronic device.

[0201] Similarly, quality warnings based on the warning release rules can also be specifically targeted at target electronic devices with the same software and / or hardware systems. That is, the electronic device that has a quality problem is precisely notified to the publisher that it is a identified candidate electronic device. The principle is the same as the execution of the release control operation, so it will not be elaborated further.

[0202] In other words, release control rules and release warning rules can be classified and implemented independently at the software system and hardware system levels. Release control and release warnings can be carried out independently and without interference between different software system and hardware system combinations. In this way, precise release control can be carried out for the quality problems that arise.

[0203] Of course, it's understandable that if the quality issue occurring in the first electronic device is due to a problem with the published application component itself, then it's considered a common issue. Based on the actual need for cautious control, automatic control and quality warnings could be implemented for all target electronic devices even if other types of electronic devices do not exhibit quality issues. However, generally speaking, if the quality issue is common, other types of electronic devices will also typically experience quality problems. For example, if a second electronic device exhibits the same quality issue as the first, then automatic control and quality warnings for the same type of target electronic device will also be triggered. Therefore, whether to implement automatic control and quality warnings for all target electronic devices when a common issue occurs can be set based on the actual need for cautious control.

[0204] For example, Figure 13This diagram illustrates the principle of independent release, independent control, and early warning.

[0205] First, application components can be pushed to different types of electronic devices based on the published information. For example... Figure 13 As shown, application components can be pushed to electronic devices that include different hardware systems, such as... Figure 13 The chip and hardware clusters A, B, and C are shown.

[0206] Furthermore, besides differences in hardware systems, electronic devices with the same hardware system may run different software systems. Therefore, software systems can also be layered and released in a hierarchical manner. For example... Figure 13 As shown, under chip and hardware cluster A, software systems a, b, and c can be further distinguished. Similarly, under chip and hardware cluster B, software systems c, d, and e can be further distinguished. Under chip and hardware cluster C, software systems x, y, and z can be further distinguished.

[0207] Then, after the application components are released, when it is necessary to match the release warning rules and release control rules, because the rules in the rule base are based on different types of electronic devices, the cloud devices actually automatically match the release warning rules and release control rules based on different combinations of software and hardware.

[0208] like Figure 13 As shown, correspondingly, for electronic devices with different hardware and software combinations, the warning rules will include warning rule Aa, warning rule Ab, warning rule Ac, warning rule Bc, warning rule Bd, warning rule Be, warning rule Cx, warning rule Cy, and warning rule Cz. Similarly, the control rules will include control rule Aa, control rule Ab, control rule Ac, control rule Bc, control rule Bd, control rule Be, control rule Cx, control rule Cy, and control rule Cz.

[0209] When it is necessary to perform corresponding release control operations based on the matched release control rules to achieve automatic release management, release control operations can be performed separately for a specific type of electronic device. For example... Figure 13 As shown, taking the hit release control rule Aa as an example, since release control rule Aa corresponds to electronic device Aa equipped with chip and hardware cluster A and software system a, the release control operation based on release control rule Aa can be executed only on electronic device Aa, thereby achieving refined automatic control and early warning for different types of electronic devices.

[0210] In some embodiments, the release control rules can be empty, meaning that automatic control over the release is not required after a quality issue occurs. For example, for quality issues that are minor and insufficient to affect the normal operation of the target electronic device, it is acceptable to continue using the application component, and cloud devices do not require automatic control over the release of the application component.

[0211] However, the release warning rules in this application embodiment are generally not empty. That is, regardless of the severity of the quality problem, as long as the release of the application component causes a quality problem, the publisher needs to be notified through a quality warning. This facilitates the subsequent maintenance and updating of the rule base, and can also be used as historical data for the maintenance and updating of severity levels.

[0212] Another embodiment of this application provides a cloud device, including: one or more processors and a memory. The memory is coupled to the processor; the memory stores one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the cloud device implements the digital resource publishing method described in any of the above embodiments.

[0213] Another embodiment of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor in a cloud device, causes the cloud device to implement the digital resource publishing method described in any of the above embodiments.

[0214] This application also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps described in the above method embodiments.

[0215] This application also provides a chip system, such as... Figure 14 As shown, the chip system 1400 includes at least one processor 1401 and at least one interface circuit 1402. The processor 1401 and the interface circuit 1402 are interconnected via lines. For example, the interface circuit 1402 can be used to receive signals from other devices (e.g., a computer's memory). As another example, the interface circuit 1402 can be used to send signals to other devices (e.g., the processor 1401).

[0216] For example, interface circuit 1402 can read instructions stored in memory and send those instructions to processor 1401. When the instructions are executed by processor 1401, the computer can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

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

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

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

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

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

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

Claims

1. A method for publishing digital resources, characterized in that, The method includes: Acquire digital resources to be published and publishing information; the publishing information includes at least one publishing device type defined by the publisher; different publishing device types correspond to different software and hardware combinations, and the software systems and / or hardware systems corresponding to different software and hardware combinations are different, while the software and hardware systems corresponding to the same publishing device type are the same. Publish the digital resources to the target electronic devices corresponding to the published device type; The system receives quality data sent by multiple target electronic devices, wherein the quality data is quality data collected by the target electronic devices corresponding to the published digital resources; the quality data is classified based on the classification of the publishing device type to obtain quality data corresponding to different publishing device types; using preset quality problem indicators as a reference, the system performs quality measurements on the target electronic devices corresponding to different publishing device types based on the quality data corresponding to different publishing device types to determine whether the target electronic devices corresponding to the publishing device types have quality problems; wherein the quality problem indicators include any one or more of crashes, app crashes, functional errors, and memory overflows, and the quality problems correspond to the quality problem indicators; When a first electronic device with a quality problem is identified, matching release control rules and release warning rules are obtained from the rule base based on the release device type to which the first electronic device belongs and the severity level of the quality problem. Quality warnings are issued to candidate electronic devices based on the release warning rules, and release control is applied to the candidate electronic devices based on the release control rules; the candidate electronic devices include the first electronic device and target electronic devices of the same type as the first electronic device.

2. The method according to claim 1, characterized in that, The digital resources include application components, software systems, resource data, or large model data.

3. The method according to claim 1 or 2, characterized in that, If the quality problem of the first electronic device is caused by the software system of the first electronic device, the candidate electronic device includes the first electronic device and a target electronic device that includes the same software system as the first electronic device; If the quality problem of the first electronic device is caused by the hardware system of the first electronic device, the candidate electronic device includes the first electronic device and a target electronic device that includes the same hardware system as the first electronic device; If the quality problem of the first electronic device is caused by the software system and hardware system of the first electronic device, the candidate electronic device includes the first electronic device and a target electronic device that includes the same software system and hardware system as the first electronic device; If the quality problem of the first electronic device is a quality problem of the published digital resource itself, the candidate electronic device includes all of the target electronic devices.

4. The method according to any one of claims 1-3, characterized in that, The quality warning includes pushing warning information to the publishing device, the warning information being used to indicate that there are quality problems with the publication of the candidate electronic device.

5. The method according to claim 1, characterized in that, The release control of the candidate electronic devices based on the release control rules includes: The release control operation is determined according to the release control rules; The release control operation is performed on the candidate electronic device; the release control operation includes one or more of the following: removing the release resource, stopping the release, and rolling back the version.

6. The method according to claim 1, characterized in that, The rule base contains pre-set release control rules corresponding to different release device types. The release control rules include at least one release control rule and release early warning rule corresponding to a severity level. The step of retrieving matching release control rules and release warning rules from the rule base based on the release device type of the first electronic device and the severity level of the quality problem includes: The target rule is determined from the release control rules corresponding to the digital resource in the rule base, and the release device type corresponding to the target rule is the same as the release device type of the first electronic device; Match the corresponding severity level based on the quality problem and its description. In the target rules, the release control rules and release warning rules corresponding to the matching severity levels are used as the matching release control rules and release warning rules.

7. The method according to any one of claims 1-6, characterized in that, The quality data includes quality information, application component information, detailed software system information, and detailed hardware system information; The data classification based on the published device type includes: The quality data is categorized based on the detailed information of the software system and the detailed information of the hardware system.

8. The method according to claim 6, characterized in that, The method further includes: Acquire historical data, including historical public opinion data and historical quality data; Based on the historical quality data, historical quality issues and descriptions of those issues are determined. Based on the analysis of the historical public opinion data, the probability of public opinion occurrence corresponding to the historical quality issues is determined. Based on the quality problem description of the historical quality problem, determine the status label of the historical quality problem; Based on the probability of public opinion occurrence, the status label, the historical quality issues, and the corresponding quality issue descriptions, at least one severity level is determined.

9. A cloud device, characterized in that, include: One or more processors and a memory, the memory being coupled to the processor; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the cloud device causes the cloud device to perform the digital resource publishing method as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor of the cloud device, the cloud device performs the digital resource publishing method as described in any one of claims 1-8.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor in a cloud device, the cloud device performs the digital resource publishing method as described in any one of claims 1-8.

Images