CN114168115B

CN114168115B - Communication system, application downloading method and device

Info

Publication number: CN114168115B
Application number: CN202010949574.9A
Authority: CN
Inventors: 刘小强; 龚俊松
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2020-09-10
Filing date: 2020-09-10
Publication date: 2022-11-08
Anticipated expiration: 2040-09-10
Also published as: CN114168115A

Abstract

The application provides a communication system, an application downloading method and application downloading equipment. The communication system includes: a first device, a second device, and a third device. The first device is used for sending a development kit of a first application to the second device, the development kit is written by at least a first programming language and a second programming language which are different in programming language, the first programming language corresponds to a first device type, the second programming language corresponds to a second device type, and the second device type is different from the second device type. The second device is used for obtaining a first meta-sub-packet corresponding to the first device type and a second meta-sub-packet corresponding to the second device type based on the development kit. The third device is configured to send the first message to the second device. The second device is used for sending a second message to the third device when the device type of the third device is determined to be the first device type, and the second message is used for indicating the storage address of the first metasubtyping packet. Therefore, the requirements of downloading and installing the application by the devices of different device types are met.

Description

Communication system, application downloading method and device

Technical Field

The present application relates to the field of electronic technologies, and in particular, to a communication system, an application downloading method, and an application downloading device.

Background

A developer needs to upload an Android application written in a Java computer programming language to a Google market (Google play store) server, and the developer needs to package the Android application into an Android application package (apk) or an Android app bundle (aab) package. Further, the developer can upload the apk or aab package to the google market server to upload the development package of any application, so that the user side device supporting the Java computer programming language can download and install any application from the google market server.

Therefore, the above manner limits both the application and the user side device to support the Java computer programming language, which results in poor flexibility and experience of application development, and insufficient variety of devices of the user side device for downloading and installing the application.

Disclosure of Invention

The application downloading method and the application downloading device can develop any application through different programming languages, each type of programming language corresponds to at least one type of equipment, the requirements that user side equipment of different equipment types can download and install the application are favorably met, and the flexibility and the experience of application development are improved.

In a first aspect, the present application provides a communication system comprising: a first device, a second device, and a third device; the system comprises a first device and a second device, wherein the first device is used for sending a development kit of a first application to the second device, the development kit is written by at least a first programming language and a second programming language, the first programming language is different from the second programming language, the first programming language corresponds to a first device type, the second programming language corresponds to a second device type, and the second device type is different from the second device type; the second equipment is used for obtaining a first meta-sub packet corresponding to the first equipment type and a second meta-sub packet corresponding to the second equipment type based on the development kit; the third device is used for sending a first message to the second device, wherein the first message is used for requesting to download the first application, and the first message carries the device type of the third device; and the second device is used for sending a second message to the third device when the device type of the third device is determined to be the first device type, wherein the second message is used for indicating the storage address of the first metachild packet.

According to the communication system provided by the first aspect, any one application is developed by the first device through different types of programming languages, and each type of programming language is associated with one or more types of devices, so that the second device can provide cross-programming language/cross-platform applications for the third device, the requirements of downloading and installing the applications of the third devices of different device types are met, the programming requirements of developers through multiple programming languages are enriched, the flexibility and experience of application development are improved, the device types supported by the written applications do not need to be uploaded manually by the developers, and the labor time and cost are saved.

In one possible design, the second device includes: a first server, a second server and a third server; the first server is used for unpacking and dividing the development packet to obtain a first metaalized packet and a second metaalized packet; the first server is also used for storing the first metasubtyping package and the second metasubtyping package in the second server; the first server is further used for storing the configuration information of the first metazilization package, the second metazilization package and the configuration information in the third server, and the configuration information of the first metazilization package at least comprises the following components: the first metaverse package stores the address in the second server.

Therefore, the second device can be divided into a first server, a second server and a third server based on the functions realized by the second device, unpacking and splitting are realized by the first server, storage is realized by the second server, and address storage is realized by the third server, so that the servers are definite in division of labor, and memory expansion and later maintenance are facilitated.

In one possible design, the third device is specifically configured to send the first message to a third server; the third server is used for sending a second message to the third equipment when the equipment type of the third equipment is determined to be the first equipment type, wherein the second message carries the storage address of the first metasubtyping packet in the second server; and the third device is specifically used for downloading the first metalized package from the second server based on the storage address of the first metalized package in the second server.

Therefore, the third device can request the third server to query the storage address of the first metalized package, and obtain the first metalized package in the second server, so that the operation steps of the third device are defined.

In one possible design, the first or second componentized package includes: a first module and a second module set; the first module is a software module capable of supporting the main page display of the first application; the second module set comprises at least one second module, and each second module is a software module of other functions except for the main page display in the first application.

Therefore, each metasubtyping package can comprise a first module and at least one second module, the setting of the first module can ensure that a user number can browse a main page of the application, and the setting of the second module can enrich the application, so that the application can have other functions, developers can develop the flexibility of the other functions of the application, and the experience of the user in using the application can be improved.

In one possible design, when at least two second modules are included in the second set of modules, the first componentization package or the second componentization package further includes: a third module; the third module is a software module of a common function on which the at least two second modules depend.

The common functions depended by the at least two second modules are software modules with high compiling coupling degree in the at least two second modules. Thereby, it is advantageous to reduce the dependency between the at least two second modules and also to reduce the size of the at least two second modules.

In one possible design, the primary module further includes at least one of a language resource, a resolution resource, and an ABI resource corresponding to the primary module.

Thus, the main module can display a main page supporting the corresponding voice based on the voice resource. The main module may display a main page supporting a corresponding resolution based on the resolution resource. The master module may display a master page supporting the corresponding ABI based on the application binary interface ABI resources.

In one possible design, each second module further includes at least one of a language resource, a resolution resource, and an ABI resource corresponding to the second module.

Thus, each second module can display the function supporting the corresponding voice based on the voice resource. Each second module may display a function supporting a corresponding resolution based on the resolution resource. Each second module may display functionality that supports a corresponding ABI based on the application binary interface ABI resource.

In one possible design, the first componentization package or the second componentization package further includes: a fourth module; the fourth module includes at least one of a language resource, a resolution resource, and an application binary interface, ABI, resource in the primary module and each of the secondary modules. Thereby, the size of the main module and each of the second modules is reduced, and the dependency between the main module and each of the second modules is reduced.

In one possible design, the first programming language or the second programming language includes: at least one of Java computer programming language, C/C + + computer programming language, and JavaScript computer programming language. Therefore, developers can adopt various programming languages to develop applications, and the flexibility and the activity of the developers are improved.

In one possible design, the first device is a developer device, the second device is a server-side device, the third device is a user-side device, the first server is an application market server, the third server is a metazization intelligent platform HAG server, and the second server is a content delivery network CDN server.

In a second aspect, the application provides an application downloading method, which is applied to a second device, where the second device includes a first componentization package corresponding to a first device type and a second componentization package corresponding to a second device type, the first componentization package and the second componentization package are obtained based on an development package of a first application, the development package is compiled by using at least a first programming language and a second programming language, the first programming language is different from the second programming language, the first programming language is corresponding to the first device type, the second programming language is corresponding to the second device type, and the second device type is different from the second device type;

the method comprises the following steps: the second equipment receives a first message from the third equipment, wherein the first message is used for requesting to download a first application, and the first message carries the equipment type of the third equipment; and when determining that the device type of the third device is the first device type, the second device sends a second message to the third device, wherein the second message is used for indicating the storage address of the first metaization package, the storage address of the first metaization package is used for the third device to download the first metaization package, and the first application is installed based on the first metaization package.

According to the application downloading method provided by the second aspect, any one application is developed by the first device through different types of programming languages, and each type of programming language is associated with one or more device types, so that the second device can provide cross-programming language/cross-platform applications for the third device, the requirements of downloading and installing the applications of the third devices of different device types are met, the programming requirements of developers through multiple programming languages are enriched, the flexibility and experience of application development are improved, the developers do not need to manually upload device types supported by the written applications, and the labor time and cost are saved.

In one possible design, the method further includes: the second device receiving a development kit from the first device; the second device obtains a first componentization package and a second componentization package based on the development package.

In one possible design, the second device includes: a first server, a second server and a third server; the second device obtains a first componentization package and a second componentization package based on the development package, and the method comprises the following steps: the first server unpacks and divides the development packet to obtain a first metaquantization packet and a second metaquantization packet; the first server stores the first metasubtization package and the second metasubtization package in a second server; the first server stores the configuration information of the first meta-sub package, the second meta-sub package and the configuration information in a third server, wherein the configuration information of the first meta-sub package at least comprises: the first metaverse package stores the address in the second server.

Therefore, the second device can be divided into a first server, a second server and a third server based on the functions realized by the second device, the first server realizes unpacking and splitting, the second server realizes storage, and the third server realizes address storage, so that each server has clear division of labor, and is convenient for memory expansion and later maintenance.

In one possible design, the second device receives a first message from a third device, including: the third server receives a first message sent by the third equipment; when determining that the device type of the third device is the first device type, the second device sends a second message to the third device, where the second message includes: and when determining that the device type of the third device is the first device type, the third server sends a second message to the third device, wherein the second message carries a storage address of the first metaquantization packet in the second server, and the storage address of the first metaquantization packet in the second server is used for the third device to download the first metaquantization packet from the second server.

In one possible design, the first componentization package or the second componentization package comprises: a first module and a second module set; the first module is a software module capable of supporting the main page display of the first application; the second module set comprises at least one second module, and each second module is a software module of other functions except for the main page display in the first application.

The common function depended by the at least two second modules is a software module with high compiling coupling degree in the at least two second modules. Thereby, it is advantageous to reduce the dependency between the at least two second modules and also to reduce the size of the at least two second modules.

In one possible design, the master module further includes at least one of a language resource, a resolution resource, and an ABI resource corresponding to the master module.

Thus, the main module can display a main page supporting the corresponding voice based on the voice resource. The master module may display a master page supporting a corresponding resolution based on the resolution resource. The master module may display a master page supporting the corresponding ABI based on the application binary interface ABI resources.

Thus, each second module can display the function supporting the corresponding voice based on the voice resource. Each of the second modules may display a function supporting a corresponding resolution based on the resolution resource. Each second module may display functionality that supports a corresponding ABI based on the application binary interface ABI resource.

In one possible design, the first componentization package or the second componentization package further includes: a fourth module; the fourth module includes at least one of a language resource, a resolution resource, and an application binary interface, ABI, resource corresponding to the main module and each of the second modules. Thereby, the size of the main module and each of the second modules is reduced, and the dependency between the main module and each of the second modules is reduced.

In a third aspect, the present application provides a second device comprising: at least one memory and at least one processor; the memory is used for storing program instructions; the processor is adapted to invoke the program instructions in the memory to cause the second device to perform the second aspect and any one of the possible designs of the second aspect of the application download method.

In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, the computer program, when executed by a processor, causing a second device to implement the method for downloading an application in any one of the possible designs of the second aspect and the second aspect.

In a fifth aspect, the present application provides a computer program product comprising: and executing instructions, which are stored in a readable storage medium and are readable by at least one processor of the second device, wherein the at least one processor executes the executing instructions to enable the second device to implement the application downloading method in any one of the possible designs of the second aspect and the second aspect.

In a sixth aspect, the present application provides a chip, where the chip is connected to a memory, or a memory is integrated on the chip, and when a software program stored in the memory is executed, the application downloading method in any one of the possible designs of the second aspect and the second aspect is implemented.

Drawings

Fig. 1 is a schematic structural diagram of a user equipment according to an embodiment of the present application;

fig. 2 is a block diagram of a software structure of a ue according to an embodiment of the present application

FIG. 3 is a schematic diagram of an application downloading and installation method according to an embodiment of the present application;

fig. 4 is a schematic flowchart of an application development phase according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of an aab packet according to an embodiment of the present application;

FIG. 6 is a schematic diagram illustrating an application downloading and installation method according to an embodiment of the present application;

fig. 7 is a schematic flowchart of an application development phase according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an application package (App pack) according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an application package (App pack) according to an embodiment of the present application;

fig. 10 is a flowchart illustrating an application downloading method provided in the present application.

Detailed Description

In this application, "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a alone, A and B together, and B alone, wherein A and B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, at least one (one) of a alone, b alone, or c alone, may represent: a alone, b alone, c alone, a and b in combination, a and c in combination, b and c in combination, or a, b and c in combination, wherein a, b and c may be single or multiple. Furthermore, the terms "first" and "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.

The application installation method and the electronic device have the advantages that developers develop applications by adopting different programming languages, and each programming language is associated with one or more device types, so that server-side equipment can provide cross-programming language/cross-platform applications for user-side equipment, the requirements of downloading and installing the applications of the user-side equipment of different device types are met, the programming requirements of the developers by adopting multiple programming languages are enriched, the flexibility and the experience of application development are improved, the developers do not need to manually upload device types supported by the written applications, and the labor time and the cost are saved.

The user side device may be a mobile phone, a tablet computer, a wearable device, an in-vehicle device, an Augmented Reality (AR)/Virtual Reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a Personal Digital Assistant (PDA), a smart television, a smart screen, a high definition television, a 4K television, a smart speaker, a smart projector, or other electronic devices.

The electronic device related to the present application is described below with reference to fig. 1 by taking the electronic device as a mobile phone as an example.

Fig. 1 is a schematic structural diagram of a user equipment according to an embodiment of the present application. The electronic equipment mentioned in the application is user side equipment. As shown in fig. 1, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identification Module (SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It is to be understood that the illustrated structure is not intended to limit the electronic device 100. In other embodiments, electronic device 100 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processor (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), among others. The different processing units may be separate devices or may be integrated into one or more processors.

The controller may be, among other things, a neural center and a command center of the electronic device 100. The controller can generate an operation control signal according to the instruction operation code and the time sequence signal to finish the control of instruction fetching and instruction execution.

A memory may also be provided in processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The I2C interface is a bidirectional synchronous serial bus including a serial data line (SDA) and a Serial Clock Line (SCL). In some embodiments, processor 110 may include multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, a charger, a flash, a camera 193, etc. through different I2C bus interfaces, respectively. For example: the processor 110 may be coupled to the touch sensor 180K through an I2C interface, so that the processor 110 and the touch sensor 180K communicate through an I2C bus interface to implement a touch function of the electronic device 100.

The I2S interface may be used for audio communication. In some embodiments, processor 110 may include multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 through an I2S bus, enabling communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through the I2S interface, so as to implement a function of answering a call through a bluetooth headset.

The PCM interface may also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled by a PCM bus interface. In some embodiments, the audio module 170 may also transmit audio signals to the wireless communication module 160 through the PCM interface, so as to implement a function of answering a call through a bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus used for asynchronous communications. The bus may be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is generally used to connect the processor 110 and the wireless communication module 160. For example: the processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. In some embodiments, the audio module 170 may transmit the audio signal to the wireless communication module 160 through a UART interface, so as to realize the function of playing music through a bluetooth headset.

MIPI interfaces may be used to connect processor 110 with peripheral devices such as display screen 194, camera 193, and the like. The MIPI interface includes a Camera Serial Interface (CSI), a Display Serial Interface (DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the capture functionality of electronic device 100. Processor 110 and display screen 194 communicate via a DSI interface to implement display functions of electronic device 100.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal and may also be configured as a data signal. In some embodiments, a GPIO interface may be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, and the like. The GPIO interface may also be configured as an I2C interface, I2S interface, UART interface, MIPI interface, and the like.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transmit data between the electronic device 100 and a peripheral device. And the earphone can also be used for connecting an earphone and playing audio through the earphone. The interface may also be used to connect other electronic devices, such as AR devices and the like.

It should be understood that the interface connection relationship between the modules illustrated in the present application is only an exemplary illustration, and does not constitute a limitation on the structure of the electronic device 100. In other embodiments, the electronic device 100 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The charging management module 140 is configured to receive a charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive a wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be used to monitor parameters such as battery capacity, battery cycle count, battery state of health (leakage, impedance), etc. In other embodiments, the power management module 141 may be disposed in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be disposed in the same device.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The

antennas

1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution including 2G/3G/4G/5G wireless communication applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 150 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the demodulated low frequency baseband signal to a baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs a sound signal through an audio device (not limited to the speaker 170A, the receiver 170B, etc.) or displays an image or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional modules, independent of the processor 110.

The wireless communication module 160 may provide solutions for wireless communication applied to the electronic device 100, including Wireless Local Area Networks (WLANs) (e.g., wireless fidelity (Wi-Fi) networks), bluetooth (bluetooth, BT), global Navigation Satellite System (GNSS), frequency Modulation (FM), near Field Communication (NFC), infrared (IR), and the like. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, perform frequency modulation and amplification on the signal, and convert the signal into electromagnetic waves through the antenna 2 to radiate the electromagnetic waves.

In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150 and antenna 2 is coupled to wireless communication module 160 so that electronic device 100 can communicate with networks and other devices through wireless communication techniques. The wireless communication technology may include global system for mobile communications (GSM), general Packet Radio Service (GPRS), code division multiple access (code division multiple access, CDMA), wideband Code Division Multiple Access (WCDMA), time-division code division multiple access (time-division code division multiple access, TD-SCDMA), long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and/or IR technologies, etc. The GNSS may include a Global Positioning System (GPS), a global navigation satellite system (GLONASS), a beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and/or a Satellite Based Augmentation System (SBAS).

The electronic device 100 implements display functions via the GPU, the display screen 194, and the application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or alter display information.

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may be a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The electronic device 100 may implement a shooting function through the ISP, the camera 193, the video codec, the GPU, the display 194, the application processor, and the like.

The ISP is used to process the data fed back by the camera 193. For example, when a photo is taken, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converting into an image visible to naked eyes. The ISP can also carry out algorithm optimization on noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing element converts the optical signal into an electrical signal, which is then passed to the ISP where it is converted into a digital image signal. And the ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into image signal in standard RGB, YUV and other formats. In some embodiments, electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process digital image signals and other digital signals. For example, when the electronic device 100 selects a frequency bin, the digital signal processor is used to perform fourier transform or the like on the frequency bin energy.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, and the like.

The NPU is a neural-network (NN) computing processor, which processes input information quickly by referring to a biological neural network structure, for example, by referring to a transfer mode between neurons of a human brain, and can also learn by itself continuously. Applications such as intelligent recognition of the electronic device 100 can be implemented by the NPU, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to extend the storage capability of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music, video, etc. are saved in an external memory card.

The internal memory 121 may be used to store computer-executable program code, which includes instructions. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. The storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The storage data area may store data (such as audio data, phone book, etc.) created during use of the electronic device 100, and the like. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like.

The electronic device 100 may implement audio functions via the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D, and the application processor. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into analog audio signals for output, and also used to convert analog audio inputs into digital audio signals. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or some functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also called a "horn", is used to convert the audio electrical signal into an acoustic signal. The electronic apparatus 100 can listen to music through the speaker 170A or listen to a handsfree call.

The receiver 170B, also called "earpiece", is used to convert the electrical audio signal into an acoustic signal. When the electronic apparatus 100 receives a call or voice information, it can receive voice by placing the receiver 170B close to the ear of the person.

The microphone 170C, also referred to as a "microphone," is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can input a voice signal to the microphone 170C by speaking near the microphone 170C through the mouth. The electronic device 100 may be provided with at least one microphone 170C. In other embodiments, the electronic device 100 may be provided with two microphones 170C to achieve a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 100 may further include three, four or more microphones 170C to collect sound signals, reduce noise, identify sound sources, and perform directional recording.

The earphone interface 170D is used to connect a wired earphone. The headset interface 170D may be the USB interface 130, or may be a 3.5mm open mobile electronic device platform (OMTP) standard interface, a cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

The pressure sensor 180A is used for sensing a pressure signal, and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194. The pressure sensor 180A can be of a wide variety, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, and the like. The capacitive pressure sensor may be a sensor comprising at least two parallel plates having an electrically conductive material. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the strength of the pressure from the change in capacitance. When a touch operation is applied to the display screen 194, the electronic apparatus 100 detects the intensity of the touch operation according to the pressure sensor 180A. The electronic apparatus 100 may also calculate the touched position from the detection signal of the pressure sensor 180A. In some embodiments, the touch operations that are applied to the same touch position but have different touch operation intensities may correspond to different operation instructions. For example: and when the touch operation with the touch operation intensity smaller than the first pressure threshold value acts on the short message application icon, executing an instruction for viewing the short message. And when the touch operation with the touch operation intensity larger than or equal to the first pressure threshold value acts on the short message application icon, executing an instruction of newly building the short message.

The gyro sensor 180B may be used to determine the motion attitude of the electronic device 100. In some embodiments, the angular velocity of electronic device 100 about three axes (i.e., x, y, and z axes) may be determined by gyroscope sensor 180B. The gyro sensor 180B may be used for photographing anti-shake. Illustratively, when the shutter is pressed, the gyro sensor 180B detects a shake angle of the electronic device 100, calculates a distance to be compensated for the lens module according to the shake angle, and allows the lens to counteract the shake of the electronic device 100 through a reverse movement, thereby achieving anti-shake. The gyroscope sensor 180B may also be used for navigation, somatosensory gaming scenes.

The air pressure sensor 180C is used to measure air pressure. In some embodiments, electronic device 100 calculates altitude, aiding in positioning and navigation, from barometric pressure values measured by barometric pressure sensor 180C.

The magnetic sensor 180D includes a hall sensor. The electronic device 100 may detect the opening and closing of the flip holster using the magnetic sensor 180D. In some embodiments, when the electronic device 100 is a flip phone, the electronic device 100 may detect the opening and closing of the flip according to the magnetic sensor 180D. And then according to the opening and closing state of the leather sheath or the opening and closing state of the flip cover, the automatic unlocking of the flip cover is set.

The acceleration sensor 180E may detect the magnitude of acceleration of the electronic device 100 in various directions (typically three axes). The magnitude and direction of gravity can be detected when the electronic device 100 is stationary. The method can also be used for recognizing the posture of the electronic equipment, and is applied to horizontal and vertical screen switching, pedometers and other applications.

A distance sensor 180F for measuring a distance. The electronic device 100 may measure the distance by infrared or laser. In some embodiments, taking a picture of a scene, electronic device 100 may utilize range sensor 180F to range for fast focus.

The proximity light sensor 180G may include, for example, a Light Emitting Diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The electronic apparatus 100 emits infrared light to the outside through the light emitting diode. The electronic device 100 detects infrared reflected light from nearby objects using a photodiode. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 100. When insufficient reflected light is detected, the electronic device 100 may determine that there are no objects near the electronic device 100. The electronic device 100 can utilize the proximity light sensor 180G to detect that the user holds the electronic device 100 close to the ear for talking, so as to automatically turn off the screen to achieve the purpose of saving power. The proximity light sensor 180G may also be used in a holster mode, a pocket mode automatically unlocks and locks the screen.

The ambient light sensor 180L is used to sense the ambient light level. Electronic device 100 may adaptively adjust the brightness of display screen 194 based on the perceived ambient light level. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking a picture. The ambient light sensor 180L may also cooperate with the proximity light sensor 180G to detect whether the electronic device 100 is in a pocket to prevent accidental touches.

The fingerprint sensor 180H is used to collect a fingerprint. The electronic device 100 can utilize the collected fingerprint characteristics to unlock the fingerprint, access the application lock, photograph the fingerprint, answer an incoming call with the fingerprint, and so on.

The temperature sensor 180J is used to detect temperature. In some embodiments, electronic device 100 implements a temperature processing strategy using the temperature detected by temperature sensor 180J. For example, when the temperature reported by the temperature sensor 180J exceeds a threshold, the electronic device 100 performs a reduction in performance of a processor located near the temperature sensor 180J, so as to reduce power consumption and implement thermal protection. In other embodiments, the electronic device 100 heats the battery 142 when the temperature is below another threshold to avoid the low temperature causing the electronic device 100 to shut down abnormally. In other embodiments, when the temperature is lower than a further threshold, the electronic device 100 performs a boost on the output voltage of the battery 142 to avoid abnormal shutdown due to low temperature.

The touch sensor 180K is also referred to as a "touch panel". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is used to detect a touch operation acting thereon or nearby. The touch sensor can communicate the detected touch operation to the application processor to determine the touch event type. Visual output associated with the touch operation may be provided through the display screen 194. In other embodiments, the touch sensor 180K may be disposed on a surface of the electronic device 100, different from the position of the display screen 194.

The bone conduction sensor 180M can acquire a vibration signal. In some embodiments, the bone conduction sensor 180M may acquire a vibration signal of the human vocal part vibrating the bone mass. The bone conduction sensor 180M may also contact the human body pulse to receive the blood pressure pulsation signal. In some embodiments, bone conduction sensor 180M may also be provided in a headset, integrated into a bone conduction headset. The audio module 170 may analyze a voice signal based on the vibration signal of the bone block vibrated by the sound part obtained by the bone conduction sensor 180M, so as to implement a voice function. The application processor can analyze heart rate information based on the blood pressure beating signal acquired by the bone conduction sensor 180M, so that the heart rate detection function is realized.

The keys 190 include a power-on key, a volume key, and the like. The keys 190 may be mechanical keys. Or may be touch keys. The electronic apparatus 100 may receive a key input, and generate a key signal input related to user setting and function control of the electronic apparatus 100.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration cues, as well as for touch vibration feedback. For example, touch operations applied to different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects. The motor 191 may also respond to different vibration feedback effects for touch operations applied to different areas of the display screen 194. Different application scenes (such as time reminding, receiving information, alarm clock, game and the like) can also correspond to different vibration feedback effects. The touch vibration feedback effect may also support customization.

Indicator 192 may be an indicator light that may be used to indicate a state of charge, a change in charge, or a message, missed call, notification, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card can be attached to and detached from the electronic device 100 by being inserted into the SIM card interface 195 or being pulled out of the SIM card interface 195. The electronic device 100 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 195 may support a Nano SIM card, a Micro SIM card, a SIM card, etc. The same SIM card interface 195 can be inserted with multiple cards at the same time. The types of the plurality of cards may be the same or different. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 may also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to implement functions such as communication and data communication. In some embodiments, the electronic device 100 employs esims, namely: an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

The software system of the electronic device 100 may employ a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The application takes an Android system with a layered architecture as an example to exemplarily illustrate a software structure of the electronic device 100. The application does not limit the type of the operating system of the electronic device. For example, an Android system, a Linux system, a Windows system, an iOS system, a hong meng operating system (hong meng OS), and the like.

Fig. 2 is a block diagram of a software structure of a user side device according to an embodiment of the present application. As shown in fig. 2, the layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, from top to bottom, an application layer (APP), an application framework layer (APP framework), an Android runtime (Android runtime) and system libraries (libraries), and a kernel layer (kernel).

The application layer may include a series of application packages.

As shown in fig. 2, the application package may include Applications (APPs) such as camera, gallery, calendar, call, map, navigation, WLAN, bluetooth, music, video, game, chat, shopping, travel, instant messaging (e.g., short message), smart home, device control, etc.

The smart home application can be used for controlling or managing home equipment with a networking function. For example, household devices may include electric lights, televisions, and air conditioners. For another example, the household equipment may further include a security door lock, a sound box, a floor sweeping robot, a socket, a body fat scale, a table lamp, an air purifier, a refrigerator, a washing machine, a water heater, a microwave oven, an electric cooker, a curtain, a fan, a television, a set-top box, a door and window, and the like.

In addition, the application package may further include: main screen (i.e. desktop), minus one screen, control center, notification center, etc.

The negative screen, which may be also referred to as a "-1 screen," refers to a User Interface (UI) that slides a screen rightward on a main screen of the electronic device until the screen slides to the leftmost screen. For example, minus one screen can be used to place some shortcut service functions and notification messages, such as global search, shortcut entries (pay codes, weChat, etc.) of a certain page of an application, instant messages and reminders (express messages, expense messages, commute traffic, taxi trip messages, schedule messages, etc.), dynamic concerns (football stands, basketball stands, stock information, etc.), and the like. The control center is an upward sliding message notification bar of the electronic equipment, namely a user interface displayed by the electronic equipment when a user starts to perform an upward sliding operation at the bottom of the electronic equipment. The notification center is a pull-down message notification bar of the electronic device, namely a user interface displayed by the electronic device when a user starts to operate downwards at the top of the electronic device.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 2, the application framework layers may include a windows manager, an activity manager, a windows manager, a content provider, a view system, a telephony manager, an explorer, a notification manager, and the like.

The window manager is used for managing window programs, such as managing window states, attributes, view (view) addition, deletion, update, window order, message collection and processing, and the like. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like. And, the window manager is the entry for outside access windows.

The content provider is used to deposit and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

The phone manager is used to provide communication functions of the electronic device 100. Such as management of call status (including on, off, etc.).

A resource manager (resource manager) provides various resources for an application, such as a localized string, an icon, a picture, a layout file (layout xml) of a user interface, a video file, a font, a color, an Identity Document (ID) of a user interface module (UI component), and the like. And the resource manager is used for uniformly managing the resources.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a brief dwell, and does not require user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scrollbar text in a status bar at the top of the system, such as a notification of a running application in the background, or a notification that appears on the screen in the form of a dialog window. For example, prompting text information in the status bar, sounding a prompt tone, vibrating the electronic device, flashing an indicator light, etc.

The android runtime comprises a core library and a virtual machine. And the Android runtime is responsible for scheduling and managing the Android system.

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

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application layer and the application framework layer as binary files. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), media libraries (media libraries), three-dimensional graphics processing libraries (e.g., openGLES), 2D graphics engines (e.g., SGL), and the like.

The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. The media library may support a variety of audio-video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

The following describes exemplary software and hardware workflow of the electronic device 100 with a scenario of playing sound using a smart speaker.

When the touch sensor 180K receives a touch operation, a corresponding hardware interrupt is issued to the kernel layer. The kernel layer processes the touch operation into an original input event (including touch coordinates, timestamp of the touch operation, and the like). The raw input events are stored at the kernel layer. And the application program framework layer acquires the original input event from the kernel layer and identifies the control corresponding to the input event. Taking the touch operation as a touch clicking operation, and taking the control corresponding to the clicking operation as the control of the smart sound box icon as an example, the smart sound box application calls the interface of the application frame layer, starts the smart sound box application, and then starts the audio driver by calling the kernel layer, and converts the audio electric signal into a sound signal through the speaker 170A.

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

Based on the foregoing description, the following embodiments of the present application will take an electronic device with a structure shown in fig. 1 and fig. 2 as an example, and will explain the method provided by the present application in detail with reference to the drawings and application scenarios.

Referring to fig. 3, fig. 3 is a schematic diagram illustrating an application downloading and installing method according to an embodiment of the present application. As shown in fig. 3, in the implementation process of application installation, two stages may be included, an application development and upload stage and an application installation stage, and the process mainly involves interaction between the developer device 11, the server-side device 12 and the user-side device 13.

The server-side device 12 may include a server a121 and a server B122. The server a121 is configured to receive the development kit of the application, and split the development kit of the application into a plurality of modules through the unpacking tool. Server a121 may be exemplified by an application marketplace server, such as a Google market (Google play store) server. The server B122 is used for storing a plurality of modules split by the development kit of the application. The server B122 may be exemplified by a Content Delivery Network (CDN).

Take server a121 as google market server for example. With continued reference to fig. 3, the application installation method of the present application may include the following steps:

1. application development and upload phase (application development phase and application upload phase)

Step S11, the developer develops an application (e.g., aab package) through the developer device 11, corresponding to the application development phase.

Step S12, the developer device 11 uploads an application (such as an aab packet) to the server a121, corresponding to the application uploading stage.

It can be understood that a developer needs to upload an Android application written in Java computer programming language to a Google market (Google play store) server, and the developer needs to package an Android application into an Android application package (apk) or an Android app bundle (aab) package. Further, after the two conditions are met, the application development kit can be uploaded to the google market server.

Therefore, the developer develops an Android application in a Java computer programming language, and packages the Android application into an Android application package (apk) or an Android app bundle (aab) package through the developer device 11. Therefore, the developer uploads the apk corresponding to the application or the aab package corresponding to the application to the server a121 through the developer device 11, and the uploading process of the development package of the application is realized.

The aab is a dynamic packaging and dynamic componentization technology promoted by Google, is a racking format of Android application, and can greatly reduce the application volume. In addition, the present application does not limit parameters such as the type of application. Each application can be developed according to the foregoing process. For ease of illustration, one application is illustrated in fig. 3-5.

In the following, taking an example of generating an aab packet by an application, a specific implementation process in the application development stage is described with reference to fig. 4.

Referring to fig. 4, fig. 4 is a schematic flowchart illustrating an application development phase according to an embodiment of the present disclosure. As shown in fig. 4, the application development phase in step S11 may include: a development state phase and a compilation and packaging phase.

In the development state, a developer may need to write Java code, and prepare resources (res/assets for short) such as pictures, videos, and texts and a configuration file (manifest for short, i.e., android manifest. Wherein, java code dependent libraries include: JAR (Java archive) packages and so libraries.

In the compiling and packaging stage, the developer device 11 may first compile the Java code into an executable file as a JAR package, and then convert the JAR package and the JAR package on which the Java code depends into a Dex file by using a JAR to Dex tool in the developer device 11, and use the Dex file as an application package (Dex file) in an application (aab package). The developer device 11 may compile and package the resource (res/assets), to obtain the resource (res/assets, file resource (resources)/native resource file (assets) in the application (aab package). The developer device 11 can take the Java code-dependent so library as a three-party library lib (so library) in the application (aab package) without converting the Java code-dependent so library. The developer apparatus 11 can use the configuration file (manifest) as the configuration file (manifest) in the application (aab package) without converting the configuration file (manifest).

In summary, the developer can get an application (aab package) through the developer device 11.

Wherein, the format of the aab packet is as follows:

wherein, the format specification of the aab packet is as follows:

base/feature/: each top level directory represents a different module of the application. The basic module of the application is always contained in the base directory, and the dynamic characteristic module of the application is contained in the feature directory.

BUNDLE-METADATA/: this directory contains metadata files containing information useful to the tools in the developer device 11 and/or the server a 121. This metadata file may contain a complete list of the prosguard mappings and the DEX files of the application.

* Pb: these files provide metadata that helps the developer explain to the server a121 the contents of the various modules in the application (i.e., the baseboard module and the dynamic property module). For example, bundleconfig.pb provides information about bundles themselves, native.pb and resources.pb specify the code and resources in each module.

manifest/: the aab package stores the android manifest. Xml configuration file for each module in this separate directory.

dex/: the aab package stores the Dex file for each module in this separate directory.

res/, lib/and assets/: these directories are identical to those in a typical apk. When the developer uploads the aab package to server a121, server a121 will examine these directories and package only files that meet the configuration requirements of the target device.

root/: the files stored by the directory are then relocated to the root directory of any module containing the module in which the directory resides. For example, the base/root/directory of the aab package may contain a Java-based resource that the application loads using the function class. These files are then relocated to the base module of the application and to the root directory of each multi-module generated by server a 121. The path in this directory is also preserved.

Step S13, the server a121 splits the aab packet, and stores the split apks in the server B122, corresponding to the application uploading phase.

The server a121 splits an aab package (i.e., an application (aab package) 10') in a resource dimension, an Application Binary Interface (ABI) dimension, and a Language (Language) dimension using a tool such as BundleTool according to functional characteristics, and assembles the applications (i.e., the applications) of the application as needed. The ABI dimension may be understood as a system architecture dimension, such as the number and type of bits of a Central Processing Unit (CPU), the type of an operating system of a device, and the like.

Moreover, the server a121 does not split the aab packet based on the device type of the user side device 13, so that the apps are not divided according to the device type of the user side device 13. Further, an appk of an application may generally include two parts. The first part includes the basic modules that any application must rely on to implement any one of the functions. The second part comprises a characteristic module corresponding to any application realizing any function.

Furthermore, a device of any one device type must download and install the first portion when downloading and installing any one application. The device of any device type does not need to download and install the second part when downloading and installing any application, and only needs to download the second part when realizing a certain function of the application. In addition, the second part can be generally divided according to the device type of the user-side device 13, and is specifically set according to the requirement of a developer.

In the application uploading stage, the server a121 splits the application (aab package) 10 'to obtain the applications (apks) 20'. One specific implementation of the applications (apps) 20' is described below in conjunction with FIG. 5.

Referring to fig. 5, fig. 5 is a schematic diagram illustrating an aab packet according to an embodiment of the present disclosure. As shown in FIG. 5, the applications (apks) 20 ' include a module 21 ' and a module 22 '.

Among them, the module 21' is a basic module, corresponding to the first portion, which each device needs to download and install when each device downloads and installs any one type of application. In some embodiments, the module 21' may include: a base module 1 (base-master.apk), a language base module 1 (base-am.apk), a language base module 2 (base-zh.apk), a resolution base module (base-mdpi.apk), a resolution base module 2 (base-hdpi.apk), an ABI base module 1 (base-armeabi.apk), and an ABI base module 2 (base-x 86.apk), and the like.

Each device needs to download and comply with base-master.

Each device can select one or more modules from the language basic modules such as the language basic module 1 (base-am.apk) and the language basic module 2 (base-zh.apk) to download and install based on the language supported by the device. Additionally, the language base modules include, but are not limited to, a language base module 1 (base-am. Apk) and a language base module 2 (base-zh. Apk).

Each device can select one or more modules from a base resolution module (base-mdpi.apk), a base resolution module 2 (base-hdpi.apk) and other base resolution modules to download and install based on the resolution supported by the device. In addition, the resolution basic block includes, but is not limited to, a resolution basic block (base-mdpi.apk) and a resolution basic block 2 (base-hdpi.apk).

Each device can select one or more modules from ABI basic modules such as an ABI basic module 1 (base-armeabi. Apk) and an ABI basic module 2 to download and install based on the ABI supported by the device. In addition, the resolution basic block includes, but is not limited to, an ABI basic block 1 (base-armeabi. Apk) and an ABI basic block 2.

Wherein the module 22' is a module provided for realizing one or more functions in an application of the apparatus of each apparatus type for the apparatuses of different apparatus types, corresponding to the second portion. In the module 22', a device of one device type needs to download and install a module corresponding to the device type to be able to implement the function in the application corresponding to the module. Also, in the module 22', the downloadable and installable modules of devices of different device types may be the same or different, selected based on the written configuration of the developer.

In some embodiments, the developer may separate the user-side device 13 into three device types, including a first device type, a second device type, and a third device type. The first device type device comprises a mobile phone and a tablet computer. The second device type of device comprises a television. The devices of the third device type comprise wearable devices.

It should be noted that the present application is not limited to the manner of dividing the user-side device 13 into three device types, and the device corresponding to each device type is also not limited to the above devices.

Based on the foregoing description, the module 22' may include: module 221 ', module 222 ', and module 223 '.

Among them, the module 221' is a module set based on the apparatus of the first apparatus type. Further, when the device of the first device type needs to implement a function in an application corresponding to the module 221 ', the device of the first device type needs to download and install the module 221'.

In some embodiments, the module 221' may comprise: a motion-Feature module 1 (Feature-master.apk), a language-Feature module 11 (Feature-am.apk), a language-Feature module 12 (Feature-zh.apk), a resolution-Feature module 11 (Feature-mdpi.apk), a resolution-Feature module 12 (Feature-hdpi.apk), an ABI-Feature module 11 (Feature-armeabi.apk), and an ABI-Feature module 12 (Feature-x 86.apk).

The devices corresponding to the first device type all need to download and install the dynamic-property module 1 (Feature-master.

The device corresponding to the first device type may select one or more modules from language characteristics modules such as the language characteristics module 11 (Feature-am.apk) and the language characteristics module 12 (Feature-zh.apk) based on the language supported by the function in the application corresponding to the implementation module 221', and download and install the selected modules. In addition, the language characteristics module includes, but is not limited to, a language characteristics module 11 (Feature-am.apk) and a language characteristics module 12 (Feature-zh.apk).

The device corresponding to the first device type may select one or more modules from among resolution characteristic modules such as the resolution-characteristic module 11 (Feature-mdpi.apk) and the resolution-characteristic module 12 (Feature-hdpi.apk) for downloading and installing, based on the resolution supported by the function in the application corresponding to the implementation module 221'. In addition, the resolution characteristic block includes, but is not limited to, a resolution characteristic block 11 (Feature-mdpi.apk) and a resolution characteristic block 12 (Feature-hdpi.apk).

The device corresponding to the first device type may select one or more modules from ABI characteristic modules such as the ABI characteristic module 11 (Feature-armabi.apk) and the ABI characteristic module 12 (Feature-x 86.apk) based on ABI supported by the application that implements the module 221'. In addition, the ABI characteristic block includes, but is not limited to, an ABI characteristic block 11 (Feature-armeabi.apk) and an ABI characteristic block 12 (Feature-x 86.apk).

Among them, the module 222' is a module set based on the apparatus of the second apparatus type. Further, when a device of the second device type needs to implement a function in an application corresponding to the module 222 ', the device of the second device type needs to download and install the module 222'.

In some embodiments, the module 222' may include: a dynamic characteristics block 2 (Feature _ tv-master.apk), a language characteristics block 21 (Feature _ tv-am.apk), a language characteristics block 12 (Feature _ tv-zh.apk), a resolution characteristics block 21 (Feature _ tv-mdpi.apk), a resolution characteristics block 22 (Feature _ tv-hdpi.apk), an ABI characteristics block 21 (Feature _ tv-armeabi.apk), an ABI characteristics block 22 (Feature _ tv-xmetabi.apk), and the like.

The devices corresponding to the second device type all need to download and install the dynamic characteristics module 2 (Feature _ tv-master.

The device corresponding to the second device type may select one or more modules from the language characteristics modules such as the language characteristics module 21 (Feature _ tv-am.apk) and the language characteristics module 22 (Feature _ tv-zh.apk) to download and install, based on the language supported by the function in the application corresponding to the implementation module 222'. In addition, the linguistic characteristics module includes, but is not limited to, a linguistic characteristics module 21 (Feature _ tv-am.apk) and a linguistic characteristics module 22 (Feature _ tv-zh.apk).

The device corresponding to the second device type may select one or more modules from the resolution characteristics modules such as the resolution characteristics module 21 (Feature _ tv-mdpi.apk) and the resolution characteristics module 22 (Feature _ tv-hdpi.apk) for downloading and installing, based on the resolution supported by the function in the application corresponding to the implementation module 222'. In addition, the resolution characteristic block includes, but is not limited to, a resolution characteristic block 21 (Feature _ tv-mdpi.apk) and a resolution characteristic block 22 (Feature _ tv-hdpi.apk).

The device corresponding to the second device type may select one or more modules from ABI characteristic modules such as the ABI characteristic module 21 (Feature _ tv-armeabi.apk) and the ABI characteristic module 22 (Feature _ tv-x86. Apk) for downloading and installing, based on the ABI supported by the function in the application corresponding to the implementation module 222'. In addition, the ABI characteristic block includes, but is not limited to, an ABI characteristic block 21 (Feature _ tv-armeabi.apk) and an ABI characteristic block 22 (Feature _ tv-x 86.apk).

Among them, the module 223' is a module set based on the apparatus of the third apparatus type. Further, when the apparatus of the third apparatus type needs to implement a function in an application corresponding to the module 223 ', the apparatus of the third apparatus type needs to download and install the module 223'.

The module 223' may include: a dynamic property module 3 (Feature _ watch-master.apk), a language property module 31 (Feature _ watch-am.apk), a language property module 32 (Feature _ watch-zh.apk), a resolution property module 31 (Feature _ watch-mdpi.apk), a resolution property module 32 (Feature _ watch-hdpi.apk), an ABI property module 31 (Feature _ watch-armeabi.apk), an ABI property module 32 (Feature _ watch-x86.apk), and the like.

The devices corresponding to the third device type all need to be downloaded and follow the dynamic property module 3 (Feature _ watch-master.apk) when the functions in the application corresponding to the module 223' need to be realized.

The device corresponding to the third device type may select one or more modules from the language characteristics modules such as the language characteristics module 31 (Feature _ watch-am.apk) and the language characteristics module 32 (Feature _ watch-zh.apk) based on the language supported by the function in the application corresponding to the implementation module 223', and download and install the selected modules. In addition, the language property module includes, but is not limited to, a language property module 31 (Feature _ watch-am.apk) and a language property module 32 (Feature _ watch-zh.apk).

The device corresponding to the third device type may select one or more modules from resolution characteristics modules such as the resolution characteristics module 31 (Feature _ watch-mdpi. Apk) and the resolution characteristics module 32 (Feature _ watch-hdpi. Apk) to download and install, based on the resolution supported by the function in the application corresponding to the implementation module 223'. In addition, the resolution characteristic block includes, but is not limited to, a resolution characteristic block 31 (Feature _ watch-mdpi.apk) and a resolution characteristic block 32 (Feature _ watch-hdpi.apk).

The device corresponding to the third device type may select one or more modules from ABI characteristics modules such as the ABI characteristics module 31 (Feature _ watch-area.apk) and the ABI characteristics module 32 (Feature _ watch-x 86.apk) based on ABI supported by the application corresponding to the implementation module 321'. In addition, the ABI property block includes, but is not limited to, an ABI property block 31 (Feature _ watch-armeabi.apk) and an ABI property block 32 (Feature _ watch-x 86.apk).

It should be noted that the module 22 'is not limited to include the module 221', the module 222 ', and the module 223'. And the functions of the module 221 ', the module 222 ' and the module 223 ' may be the same or different, which is not limited in this application.

2. Application installation phase

Step S14, the user-side device 13 requests and downloads any application from the server-side device 12, corresponding to the application installation phase.

The user side device 13 sends a request message to the server side device 12, where the request message is used to request any application to be downloaded, and the request message at least includes an identifier of the user side device 13 and an identifier of the application.

The specific implementation manner of the request message is not limited in the present application. The identification of the user-side device 13 is used to indicate the device type, language, ABI and resolution of the user-side device 13. The identification of the application is used to indicate the application requested by the user-side device 13.

The server-side device 12 acquires the apk of the application based on the request message, and sends a request response to the user-side device 13, where the request response includes the apk of the application.

The present application does not limit the specific implementation manner of the request response. The applied apk comprises at least a module 21'.

Further, the user-side device 13 can download and install the application based on the apk of the application.

In summary, fig. 3 shows the implementation process of application from development, upload to installation. However, currently, the developer device 11 writes an application in the Java computer programming language, so that the user-side device 13 needs to support the application in the Java computer programming language, and can download and install the apk of the application from the server-side device 12, which causes limitation to the application downloaded and installed by the user-side device 13. For a device with a small memory, such as a wearable device, an application written for the device by adopting a Java programming language usually does not have a corresponding Java virtual machine, so that a code cannot run, and the limitation of the device is caused. In addition, when the developer device 11 uploads the aab package of the application to the server a121 in the server-side device 12, the developer needs to check the device type supported by the aab package of the application, which increases labor time and cost.

Referring to fig. 6, fig. 6 is a schematic diagram illustrating an application downloading and installing method according to an embodiment of the present application. As shown in fig. 6, in the implementation process of application installation, two phases may be included, an application development and upload phase and an application installation phase, and the process mainly involves interaction between the developer device 21, the server-side device 22 and the user-side device 23.

The server-side device 22 may include a server C221, a server D222, and a server E223. The server C221 is configured to receive a development kit of an application and divide the development kit of the application into a plurality of modules. Server C221 may be illustrated by an application marketplace server, such as the huanshi marketplace server. The server D222 is used for an index table of the divided modules, and the server D222 may be exemplified by a server such as a HUAWEI intelligence platform (HAG). The server E223 is used for storing a plurality of modules after the development kit of the application is divided. The server E223 may be exemplified by a Content Delivery Network (CDN).

Take server C221 as a marketplace server for example. With continued reference to fig. 6, the application installation method of the present application may include the following steps:

In step S21, the developer develops an application (e.g., a hap package) through the developer device 21, corresponding to an application development phase.

It will be appreciated that the developer device 21 is capable of uploading to the marketplace server a development kit for an application written in any one of a number of programming languages. Also, a developer develops an application, and needs to generate a meta-child package (hash package) from the application through the developer device 21, and package one or more hash packages into an application package (App Pack, abbreviated as App).

Next, taking an example of generating an application package by an application, a specific implementation process of the application development phase is described with reference to fig. 7. In fig. 7, the applied programming language is illustrated by using three examples, namely Java computer programming language, C/C + + computer programming language, and JavaScript (JS for short) computer programming language. The application does not limit the parameters such as the type of application. Each application can be developed according to the foregoing process. For ease of illustration, one application is illustrated in fig. 6-9. An application herein may correspond to a device of one device type, or may correspond to devices of multiple device types.

Referring to fig. 7, fig. 7 is a schematic flowchart illustrating an application development phase according to an embodiment of the present disclosure. As shown in fig. 7, the application development phase in step S21 may include: a development state phase and a compilation and packaging phase.

1. The hap package 1 formed using the Java computer programming language is formed as follows:

in the development state, the developer may need to write Java code, prepare resources (resource for short) such as pictures, videos, and texts, and set a configuration file (config. Json) through the developer device 21. Wherein, java code dependent libraries include: so library and JAR package. The resource (resource) may support multiple languages, may support multiple resolutions, may be accessed through a resource ID, and may support a raw image file (rawfile). Json includes at least: supported device types, name of the hap packet, type of the hap packet, whether to install actively, and the like.

In the compiling and packaging stage, the developer device 21 may first compile the Java code into an executable file as a JAR package, and then convert the JAR package into the so library 1 through a JAR translation so tool (for example, warship compiler) in the developer device 21. Thus, the developer device 21 can take the so library 1 as the meta-capability Ability (so library) in the application (hap package 1). The developer device 21 does not need to convert the so library that the Java code depends on, and a JAR to so tool (such as a warship compiler) in the developer device 21 can convert the JAR package that the Java code depends on into the so library 2. Thus, the developer device 21 can combine the so library and the so library 2 on which the Java code depends, resulting in the three-way library libs (so library) in the application (hap package 1). The developer device 21 may compile and package the resource (resource) to obtain the resource (resource) in the application (hap package 1). The developer device 21 can use the configuration file (config.json) as the configuration file (config.json) in the application (hap package 1) without converting the configuration file (config.json).

Further, the developer can obtain one hap package 1 in the Java computer programming language through the developer device 21.

2. The hap package 2 formed by adopting the C/C + + computer programming language is formed as follows:

in the development state, the developer may need to write C/C + + code, prepare resources (resource for short) such as pictures, videos, and texts, and set a configuration file (config. Json) through the developer device 21. Wherein, the library that C/C + + code depends on includes: so library.

In the compile-and-package phase, the developer device 21 may compile the C/C + + code into an executable file as the so library 3, and then use the so library 3 as the meta-capability property (so library) in the application (hap package 2). The developer device 21 can use the so library as a three-way library libs (so library) in the application (hap package 2) without converting the so library on which the C/C + + code depends. The developer device 21 may compile and package the resource (resource) to obtain the resource (resource) in the application (hap package 2). The developer device 21 may use the configuration file (config.json) as the configuration file (config.json) in the application (hap package 2) without converting the configuration file (config.json).

Further, the developer can obtain one hap package 2 using the C/C + + computer programming language through the developer apparatus 21.

3. The hap package 3 formed by adopting the JS computer programming language is formed as follows:

in the development state, the developer may need to write JS code, prepare resources (resource for short) such as pictures, videos, and texts, and set a configuration file (config. Json) through the developer device 21. Wherein, the library that JS code relies on includes: so library.

In the compile-and-package phase, the developer device 21 may first compile JS code into executable code and use the executable code as meta-capability Ability (JS file) in the application (hap package 3). The developer device 21 can use the so library as a libs (so library) of a three-party library in the application (hap package 3) without converting the so library on which the JS code depends. The developer device 21 may compile and package the resource (resource) to obtain the resource (resource) in the application (hap package 3). The developer device 21 may use the configuration file (config.json) as the configuration file (config.json) in the application (hap package 3) without converting the configuration file (config.json).

Further, the developer can obtain one hap package 3 in the JS computer programming language through the developer device 21.

It should be noted that the

hap packets

1, 2, and 3 may implement a hap packet with the same function for devices of different device types, and also implement a hap packet corresponding to each function for a device of the same device type, which is not limited in this application.

In summary, the developer device 21 may obtain a plurality of hap packets based on the programming language adopted by the devices of different device types, and package the plurality of hap packets into an application packet (App pack, abbreviated as App), where one application packet corresponds to one or more device types of applications. And, the developer apparatus 21 may write the attribute information of each hap packet into the description file (pack.

Among them, a plurality of hap packets in an application packet (App pack, abbreviated as App) may be divided into one or more groups of hap packets. Each group of hap packages may correspond to one or more device types of devices, and the programming languages corresponding to the individual hap packages in each group of hap packages are the same. In addition, the different groups of hap packages may be the same or different in their respective programming languages. The respective device types of the different groups of the hap packets may be the same or different, i.e., a group of the hap packets may correspond to devices of one or more device types.

In some embodiments, the type of each group of hap packets may generally include two.

The first type of hap package is a deployment package (abbreviated as entry. Hap) that contains the entry, abilty, of an application, usually only one, consisting of code, a three-way library, resources, and configuration files. The code may be one or more abilitys, and common codes (common codes) that depend thereon. The three-party library may employ a so library, which is different from common codes in that the so library is capable of independent compilation and passive code. Also, the first type of hap package can support installation-free, typically automatic installation as the application is first installed. In addition, the entry property of the application is usually the property corresponding to the first page/main page of the application.

A second type of hap package is a deployment package (abbreviated as feature. Hap) of other code or resources of an application, and may be multiple, consisting of code, a three-party library, resources, and configuration files. The code may be one or more abilitys and common codes (common codes), may only include a three-party library, or may not include any code but only include a resource, which is not limited in the present application. The resource may be a resource on which a code in the group of the hap packets depends, or a resource used by another hap packet, or both of the foregoing resources, which is not limited in this application. Moreover, the second type of hap packet containing the property can support installation-free and is usually automatically installed along with the first installation of the application, and the second type of hap packet not containing the property needs to be downloaded and installed through an Application Programming Interface (API) of the electronic device and is usually not automatically installed along with the first installation of the application. In addition, the other code or resource of the application is a code or resource other than the entry activity of the application, such as the activity corresponding to other pages of the application other than the main page.

In addition, the developer device 21 can pack a plurality of properties with high compiling coupling degrees into the same hap packet, so as to reduce the dependency among the plurality of hap packets. And a plurality of hap packages depend on common public codes, and each hap package needs to contain a so library into which the public codes are compiled, so that the dependency among the plurality of hap packages is reduced. And a plurality of the hap packets depend on common resources, and each hap packet needs to contain the resources, so that the dependency among the plurality of the hap packets is reduced.

In addition, the developer device 21 can place and deploy common public code, three-party libraries and resources that support the common public code into an independent feature.

A specific implementation of the application package (App pack) 10 is described below in conjunction with fig. 8-9.

Referring to fig. 8-9, fig. 8-9 are schematic diagrams illustrating an application package (App pack) according to an embodiment of the present application. As shown in fig. 8-9, an application package (App pack) 10 may include three sets of hap packages and a description file (pack. The device types corresponding to each group of the hap packets are different, the description file (pack. Info) records attribute information of each of the three groups of the hap packets, and the attribute information of each of the hap packets at least may include: the device type supported by the hap packet, the packet name of the hap packet, the type of the hap packet, whether to actively install and the like.

For convenience of explanation, the description file (pack. Info) explains the attribute information of three hap packets, namely, the hap packet a, the hap packet B, and the hap packet C, by using the following codes:

in some embodiments, the device type corresponding to the first group of hash packets is the first device type. The device type corresponding to the second group of the hap packets is the second device type. The device type corresponding to the third group of the hap packets is a third device type. In some embodiments, the devices of the first device type include cell phones, tablet computers, televisions, and notebook computers. Devices of a second device type include Internet of Things (IoT) devices, among other types of devices. The device of the third device type comprises a wearable device.

It should be noted that the present application is not limited to the manner of dividing the user-side device 23 into three device types, and the devices of each device type are not limited to the above devices.

The first set of hash packets may include: main module 1 (entry. Hap), dynamic characteristics module 11 (feature. Hap), and dynamic characteristics module 12 (feature. Hap).

The main module 1 (entry. Hap) is a deployment package of an entry property of an application, and may be composed of the property and a public code (illustrated by using a meta-capability property in fig. 9), a three-party library, a resource, a configuration file, and the like. The dynamic characteristics module 11 (feature.hap) and the dynamic characteristics module 12 (feature.hap) are deployment packages of other codes or resources of the application, and may be composed of Ability and public codes, a three-party library, resources, and configuration files (not shown in fig. 9). The dynamic characteristics block 11 (feature.hap) and the dynamic characteristics block 12 (feature.hap) correspond to different functions of one application, respectively. The first group of hash packets may include any one of the dynamic characteristics block 11 (feature.hash) and the dynamic characteristics block 12 (feature.hash), and may also include the dynamic characteristics block 11 (feature.hash) and the dynamic characteristics block 12 (feature.hash), which is not limited in this application.

In addition, the first group of the hap packets may further include: the commonality block 1 (feature. Common. Hap) may consist of a common three-party library and configuration file, etc. (not shown in fig. 9). The commonality block 1 (feature.hap) contains a so library compiled from common code common to the motion characteristics block 11 (feature.hap) and the motion characteristics block 12 (feature.hap). If the first group of hat packets contains either one of the motion characteristics block 11 (motion. Hat) and the motion characteristics block 12 (motion. Hat), the first group of hat packets does not contain the commonality block 1 (motion.

The main module 1 (entry. Hap) may further include a language resource supported by a deployment package of the portal accessibility of the application, the dynamic characteristics module 11 (feature. Hap) may further include a language resource supported by a deployment package of other codes or resources of the application, and the dynamic characteristics module 12 (feature. Hap) may further include a language resource supported by a deployment package of other codes or resources of the application.

It should be noted that the language resource is usually obtained from resource (resource) of the hap package.

In addition, the first group of the hap packets may further include: the language property module 1 (Feature _ language. Hap) may be composed of a voice resource, a configuration file, and the like (not shown in fig. 9). The language property block 1 (Feature _ language.hap) is all language resources supported by the main block 1 (entry. Hap), the dynamic property block 11 (Feature. Hap), and the dynamic property block 12 (Feature. Hap). Thus, the dependency between the main module 1 (entry. Hap), the dynamic characteristics block 11 (feature. Hap), and the dynamic characteristics block 12 (feature. Hap) is reduced.

The main module 1 (entry.hap) may further include a so library corresponding to ABI supported by the deployment package of the portal identity of the application, the dynamic characteristics module 11 (feature.hap) may further include a so library corresponding to ABI supported by the deployment package of other codes or resources of the application, and the dynamic characteristics module 12 (feature.hap) may further include a so library corresponding to ABI supported by the deployment package of other codes or resources of the application.

It should be noted that the so library corresponding to the ABI is usually obtained from the libs (so library) of the tripartite library of the hap package.

In addition, the first group of the hap packets may further include: the ABI property block 1 (Feature _ ABI. Hap) may be composed of a so library and a configuration file corresponding to ABI (not shown in fig. 9). The ABI characteristics block 1 (Feature _ abi.hap) is a so library corresponding to all ABIs supported by the main block 1 (entry.hap), the dynamic characteristics block 11 (feature.hap), and the dynamic characteristics block 12 (feature.hap). Thus, the dependency between the main module 1 (entry. Hap), the dynamic characteristics module 11 (feature. Hap), and the dynamic characteristics module 12 (feature. Hap) is reduced.

The main module 1 (entry.hap) may further include resolution resources supported by a deployment package of the portal activity of the application, the dynamic characteristics module 11 (feature.hap) may further include resolution resources supported by a deployment package of other codes or resources of the application, and the dynamic characteristics module 12 (feature.hap) may further include resolution resources supported by a deployment package of other codes or resources of the application.

It should be noted that the resolution resource is usually obtained from the resource (resource) of the hap packet.

In addition, the first group of the hap packets may further include: the resolution characteristics block 1 (Feature _ abi. Hap) may be composed of resolution resources, configuration files, and the like (not shown in fig. 9). The ABI characteristics block 1 (Feature _ abi.hap) is a resource of all resolutions supported by the main block 1 (entry.hap), the dynamic characteristics block 11 (feature.hap), and the dynamic characteristics block 12 (feature.hap). Thus, the dependency between the main module 1 (entry. Hap), the dynamic characteristics module 11 (feature. Hap), and the dynamic characteristics module 12 (feature. Hap) is reduced.

The second set of hap packets may include: main module 2 (Entry _ iot.hap), dynamic characteristics module 21 (Feature _ iot.hap), and dynamic characteristics module 22 (Feature _ iot.hap).

The main module 2 (Entry _ iot. Hap) is a deployment package of the Entry flexibility of the application, and may be composed of flexibility and public code (illustrated by meta-capability flexibility in fig. 9), a three-party library, resources, and configuration files. The dynamic characteristics module 21 (Feature _ iot.hap) and the dynamic characteristics module 22 (Feature _ iot.hap) are deployment packages of other codes or resources of the application, and may be composed of abstract and public codes, a three-party library, resources, configuration files, and the like (not illustrated in fig. 9). The dynamic characteristics block 21 (Feature _ iot.hap) and the dynamic characteristics block 22 (Feature _ iot.hap) correspond to different functions of an application, respectively. The second group of hash packets may include any one of the dynamic characteristics block 21 (Feature _ iot.hash) and the dynamic characteristics block 22 (Feature _ iot.hash), and may also include the dynamic characteristics block 21 (Feature _ iot.hash) and the dynamic characteristics block 22 (Feature _ iot.hash), which is not limited in this application.

In addition, the second group of hap packets may further include: the commonality block 2 (feature. Commonliibs _ iot. Hap) may consist of a common three-party library and configuration files, etc. (not shown in fig. 9). The commonality block 2 (Feature _ commonlibs _ iot.hap) contains a so library into which common code common to the motion characteristics block 21 (Feature _ iot.hap) and the motion characteristics block 22 (Feature _ iot.hap) is compiled. If the second group of hap packets contains any of the dynamic characteristics block 21 (Feature _ iot.hap) and the dynamic characteristics block 22 (Feature _ iot.hap), the second group of hap packets does not contain the commonality block 2 (Feature.

The main module 2 (Entry _ iot.hap) may further include a language resource supported by a deployment package of the portal accessibility of the application, the dynamic characteristics module 21 (Feature _ iot.hap) may further include a language resource supported by a deployment package of other codes or resources of the application, and the dynamic characteristics module 22 (Feature _ iot.hap) may further include a language resource library supported by a deployment package of other codes or resources of the application.

In addition, the second group of the hap packets may further include: the language property module 2 (Feature _ language _ iot. Hap) may be composed of a voice resource, a configuration file, and the like (not shown in fig. 9). The language property block 2 (Feature _ language _ iot.hop) is all language resources supported by the main block 2 (Entry _ iot.hop), the dynamic property block 21 (Feature _ iot.hop) and the dynamic property block 22 (Feature _ iot.hop). Thus, the dependency between the main module 2 (Entry _ iot.hap), the dynamic characteristics module 21 (Feature _ iot.hap), and the dynamic characteristics module 22 (Feature _ iot.hap) is reduced.

The main module 2 (Entry _ iot.hop) may further include a so library corresponding to the ABI supported by the deployment package of the application Entry Ability, the dynamic characteristics module 21 (Feature _ iot.hop) may further include a so library corresponding to the ABI supported by the deployment package of the other codes or resources of the application, and the dynamic characteristics module 22 (Feature _ iot.hop) may further include a so library corresponding to the ABI supported by the deployment package of the other codes or resources of the application.

In addition, the second group of the hap packets may further include: the ABI property block 2 (Feature _ ABI _ iot. Hap) may be composed of a so library and a configuration file corresponding to the ABI (not shown in fig. 9). ABI characteristic block 2 (Feature _ ABI _ iot.hop) is a so library corresponding to all ABIs supported by main block 2 (Entry _ iot.hop), dynamic characteristic block 21 (Feature _ iot.hop) and dynamic characteristic block 22 (Feature _ iot.hop). Thus, the dependency between the main module 2 (Entry _ iot.hap), the dynamic characteristics module 21 (Feature _ iot.hap), and the dynamic characteristics module 22 (Feature _ iot.hap) is reduced.

The main module 2 (Entry _ iot.hop) may further include resolution resources supported by the deployment package of the Entry activity of the application, the dynamic characteristics module 21 (Feature _ iot.hop) may further include resolution resources supported by the deployment package of other codes or resources of the application, and the dynamic characteristics module 22 (Feature _ iot.hop) may further include resolution resources supported by the deployment package of other codes or resources of the application.

In addition, the second group of the hap packets may further include: the resolution characteristics module 2 (Feature _ abi _ iot. Hap) may be composed of resolution resources, configuration files, and the like (not shown in fig. 9). The ABI characteristics block 2 (Feature _ ABI _ iot.hap) is a resource of all resolutions supported by the main block 2 (Entry _ iot.hap), the dynamic characteristics block 21 (Feature _ iot.hap), and the dynamic characteristics block 22 (Feature _ iot.hap). Thus, the dependency between the main module 2 (Entry _ iot.hap), the dynamic characteristics module 21 (Feature _ iot.hap), and the dynamic characteristics module 22 (Feature _ iot.hap) is reduced.

The third set of hash packets may include: main module 3 (Entry _ watch.hap), dynamic characteristics module 31 (Feature _ watch.hap), and dynamic characteristics module 32 (Feature _ watch.hap).

The main module 3 (Entry _ watch. Hap) is a deployment package of the Entry activity of the application, and may be composed of the activity and a public code (illustrated in fig. 9 by using meta-capability activity), a three-way library, a resource, a configuration file, and the like. The dynamic property module 31 (Feature _ watch.hap) and the dynamic property module 32 (Feature _ watch.hap) are deployment packages of other codes or resources of the application, and may be composed of abstract and public codes, a three-party library, resources, configuration files, and the like (not shown in fig. 9). The dynamic characteristics block 31 (Feature _ watch.hap) and the dynamic characteristics block 32 (Feature _ watch.hap) correspond to different functions of one application, respectively. The third group of hash packets may include any one of the dynamic characteristics block 31 (Feature _ watch.hash) and the dynamic characteristics block 32 (Feature _ watch.hash), and may also include the dynamic characteristics block 31 (Feature _ watch.hash) and the dynamic characteristics block 32 (Feature _ watch.hash), which is not limited in this application.

In addition, the third group of hap packets may further include: common libs _ watch. Hap, may be composed of a common three-party library and configuration files, etc. (not shown in fig. 9). The commonality block 3 (Feature _ communiibs _ watch. Hap) contains a so library into which common code common to the motion characteristics block 31 (Feature _ watch. Hap) and the motion characteristics block 32 (Feature _ watch. Hap) is compiled. If the third group of hap packets contains either one of the motion characteristics block 31 (motion _ watch. Hap) and the motion characteristics block 32 (motion _ watch. Hap), the third group of hap packets does not contain the common block 3 (motion.

The main module 3 (Entry _ watch.hap) may further include a language resource supported by the deployment package of the Entry activity of the application, the dynamic property module 31 (Feature _ watch.hap) may further include a language resource supported by the deployment package of other codes or resources of the application, and the dynamic property module 32 (Feature _ watch.hap) may further include a language resource supported by the deployment package of other codes or resources of the application.

In addition, the third group of hap packets may further include: the language property module 3 (Feature _ language _ watch. Hap) may be composed of a voice resource, a configuration file, and the like (not shown in fig. 9). The language property block 3 (Feature _ language _ watch.hap) is all language resources supported by the main block 3 (Entry _ watch.hap), the dynamic property block 31 (Feature _ watch.hap), and the dynamic property block 32 (Feature _ watch.hap). Thus, the dependency between the master module 3 (Entry _ watch.hap), the dynamic characteristics module 31 (Feature _ watch.hap), and the dynamic characteristics module 32 (Feature _ watch.hap) is reduced.

The main module 3 (Entry _ watch.hap) may further include a so library corresponding to the ABI supported by the deployment package of the Entry identity of the application, the dynamic property module 31 (Feature _ watch.hap) may further include a so library corresponding to the ABI supported by the deployment package of the other codes or resources of the application, and the dynamic property module 32 (Feature _ watch.hap) may further include a so library corresponding to the ABI supported by the deployment package of the other codes or resources of the application.

In addition, the third group of the hap packets may further include: the ABI property module 3 (Feature _ ABI _ watch. Hap) may be composed of a so library and a configuration file corresponding to ABI (not shown in fig. 9). ABI property block 3 (Feature _ ABI _ watch.hap) is a so library corresponding to all ABIs supported by main block 3 (Entry _ watch.hap), dynamic property block 31 (Feature _ watch.hap), and dynamic property block 32 (Feature _ watch.hap). Thus, the dependency between the master module 3 (Entry _ watch.hap), the dynamic characteristics module 31 (Feature _ watch.hap), and the dynamic characteristics module 32 (Feature _ watch.hap) is reduced.

The main module 3 (Entry _ watch.hap) may further include a resolution resource supported by a deployment package of an Entry property of the application, the dynamic property module 31 (Feature _ watch.hap) may further include a resolution resource supported by a deployment package of other codes or resources of the application, and the dynamic property module 32 (Feature _ watch.hap) may further include a resolution resource supported by a deployment package of other codes or resources of the application.

In addition, the third group of hap packets may further include: the resolution characteristics block 3 (Feature _ abi _ watch. Hap) may be composed of a resolution resource, a configuration file, and the like (not illustrated in fig. 9). ABI property block 3 (Feature _ ABI _ watch.hap) is a so bank corresponding to all resolutions supported by main block 3 (Entry _ watch.hap), dynamic property block 31 (Feature _ watch.hap), and dynamic property block 32 (Feature _ watch.hap). Thus, the dependency between the master module 3 (Entry _ watch.hap), the dynamic characteristics module 31 (Feature _ watch.hap), and the dynamic characteristics module 32 (Feature _ watch.hap) is reduced.

It should be noted that the first group of the hap packets, the second group of the hap packets, and the third group of the hap packets in an application may correspond to one device type, and may also correspond to different device types. And the programming language of each of the first group of the hap packages is the same, the programming language of each of the second group of the hap packages is the same, and the programming language of each of the third group of the hap packages is the same. The respective programming languages of the first, second, and third groups of hap packages may be the same or different.

In addition, in addition to the above-mentioned form in which the first, second, and third groups of hap packets store hap packets, the developer device 21 may store a plurality of hap packets of the application package (App pack) 10 not by device type, but only by satisfying that the hap packets of the same device type use the same programming language.

Step S22, the developer device 21 uploads an application package (App pack) to the server C221, corresponding to the application upload phase.

The developer device 21 shelves the application in the form of an application package (App pack) into the server C221.

Step S231, the server C221 divides the application package (App package) based on the configuration file (pack. Info), and deploys the divided hap package (i.e., the application package (haps) 20) to the server E223, which corresponds to the application uploading phase.

Step S232, the server C221 stores the index list of the divided hap packets in the server D222, corresponding to the application uploading stage.

Since the developer device 21 has classified the hap packets according to the device types, the server C221 can unpack and divide the application packet (App packet) based on the device type of the user side device 23 in the configuration file (pack. Info), without performing a complicated unpacking process on the application packet (App packet).

In one aspect, server C221 may deploy each set of hap packets corresponding to the device type in server E223, such that server E223 stores each set of hap packets.

On the other hand, the server C221 may establish an index list of the divided hap packets in the server D222, so that the server D222 stores the index list of the divided hap packets.

The index list of the divided hap packets may store configuration information of each hap packet, where the configuration information of each hap packet at least includes: the packet name of each hap packet is associated with the address where the hap packet is stored in server E223. Thereby, the user-side device 23 is enabled to quickly determine the download address of the hap packet.

In the following, with continued reference to fig. 8, a specific implementation of the application packages (haps) 20 is described.

As shown in fig. 8, the application packets (haps) 20 may include three groups of hap packets.

The device type corresponding to the first group of the hash packets 21 is the first device type.

Wherein, the first group of the hash packets 21 may include: main module 1 (entry. Hap), motion characteristics module 11 (feature. Hap), and motion characteristics module 12 (feature. Hap).

In addition, the first group of hap packets 21 may further include: a commonality block 1 (Feature. Commonlibss. Hap), a language Feature block 1 (Feature _ language. Hap), an ABI Feature block 1 (Feature _ ABI. Hap), and a resolution Feature block 1 (Feature _ ABI. Hap).

The device type corresponding to the second group of hash packets 22 is the second device type.

Wherein the second group of hap packets 22 may comprise: main module 2 (Entry _ iot.hap), dynamic characteristics module 21 (Feature _ iot.hap), and dynamic characteristics module 22 (Feature _ iot.hap).

In addition, the second group of hap packets 22 may further include: a commonality block 2 (Feature _ commonalibs _ iot.hap), a language Feature block 2 (Feature _ language _ iot.hap), an ABI Feature block 2 (Feature _ ABI _ iot.hap), and a resolution Feature block 2 (Feature _ ABI _ iot.hap).

The device type corresponding to the third group of the hash packet 23 is a third device type.

Wherein, the third group of the hap packet 23 may include: main module 3 (Entry _ watch.hap), dynamic characteristics module 31 (Feature _ watch.hap), and dynamic characteristics module 32 (Feature _ watch.hap).

In addition, the third group of the hap packet 23 may further include: a commonality block 3 (Feature _ common _ watch.hap), a language property block 3 (Feature _ language _ watch.hap), an ABI property block 3 (Feature _ ABI _ watch.hap), and a resolution property block 3 (Feature _ ABI _ watch.hap).

It should be noted that, for each of the first group of the hash packets 21, the second group of the hash packets 22, and the third group of the hash packets 23, the hash packet may refer to the foregoing description, and is not described herein again.

2. Application installation phase

Step S241, the user-side device 23 sends an inquiry request to the server D222, where the inquiry request at least includes the identifier of the user-side device 23 and the identifier of the application, and corresponds to the application installation phase.

The query request is used for querying a download address of a hap package corresponding to any application, and the specific implementation manner of the query request is not limited in the present application. The identification of the user-side device 23 is used to indicate the device type, language, ABI, and resolution of the user-side device 23. The identification of the application is used to indicate the application requested by the user-side device 23.

Step S242, the server D222 sends an inquiry response to the user-side device 23, where the inquiry response carries the download address of the hap packet corresponding to the application.

The query response is used for indicating the download address of the hap packet corresponding to the application, and the specific implementation manner of the query response is not limited in the application.

In step S243, the user-side device 23 downloads the application from the server E223 based on the download address of the hap package corresponding to the application, corresponding to the application installation phase.

Further, the user-side device 23 can download and install the application based on the hap package of the application.

In summary, fig. 6 shows an implementation process of application development, uploading to installation, which not only meets the programming requirements that a developer can adopt different programming languages, but also can adapt to devices of different device types, so that the requirement of application installation in cross-programming language/cross-platform is met, and the developer does not need to manually upload device types supported by a written application, thereby saving labor time and cost.

Based on some of the foregoing embodiments, the communication system provided by the present application is described below.

Illustratively, the present application provides a communication system. The communication system of the present application may include: a first device, a second device, and a third device; the system comprises a first device and a second device, wherein the first device is used for sending a development kit of a first application to the second device, the development kit is written by at least a first programming language and a second programming language, the first programming language is different from the second programming language, the first programming language corresponds to a first device type, the second programming language corresponds to a second device type, and the second device type is different from the second device type; the second device is used for obtaining a first metasubtyping package corresponding to the first device type and a second metasubtyping package corresponding to the second device type based on the development kit; the third device is used for sending a first message to the second device, wherein the first message is used for requesting to download the first application, and the first message carries the device type of the third device; and the second device is used for sending a second message to the third device when the device type of the third device is determined to be the first device type, wherein the second message is used for indicating the storage address of the first metasubtyping packet.

For the communication system, reference may be made to the descriptions of the developer device 21, the server-side device 22, and the user-side device 23 in fig. 6 to 9, the first device may refer to the description of the developer device 21 in fig. 6 to 9, the second device may refer to the description of the server-side device 22 in fig. 6 to 9, the third device may refer to the description of the user-side device 23 in fig. 6 to 9, the development package of the first application may refer to the description of the application package (App Pack) in fig. 6 to 9, the description of the first meta-sub-package and the meta-sub-package may refer to the description of the first group of hap packages 21 or the second group of haps packages 22 or the third group of haps packages 23 in the application package (haps) 20 in fig. 6 to 9, the specific implementation process of the third device sending the first message to the second device may refer to the description of step 241 in fig. 6 to fig. 9, and the specific implementation process of the step 242 may be referred to this fig. 6-fig. 9. In addition, the present application does not limit the specific implementation manner of the first message and the second message.

In some embodiments, the first programming language or the second programming language comprises: at least one of Java computer programming language, C/C + + computer programming language, and JavaScript computer programming language. Therefore, developers can adopt various programming languages to develop applications, and the flexibility and the activity of the developers are improved.

In some embodiments, the first device is a developer device, the second device is a server-side device, and the third device is a user-side device.

In the application, any one application is developed by the first device through different programming languages, and each programming language is associated with one or more device types, so that the second device can provide cross-programming language/cross-platform applications for the third device, the requirements of downloading and installing the applications of the third devices of different device types are met, the programming requirements of developers through multiple programming languages are enriched, the flexibility and experience of application development are improved, the developers do not need to manually upload device types supported by the written applications, and the labor time and cost are saved.

In some embodiments, the second device comprises: a first server, a second server and a third server; the first server is used for unpacking and dividing the development packet to obtain a first metaalized packet and a second metaalized packet; the first server is also used for storing the first metasubtyping package and the second metasubtyping package in the second server; the first server is further used for storing the configuration information of the first metasubtyping package, the second metasubtyping package and the configuration information in the third server, and the configuration information of the first metasubtyping package at least comprises: the first metaverse package stores the address in the second server.

The specific implementation process of unpacking and dividing the development packet by the first server to obtain the first unitary sub packet and the second unitary sub packet and storing the first unitary sub packet and the second unitary sub packet in the second server may refer to the description of step 231 in fig. 6 to 9, the specific implementation process of storing the configuration information of the first unitary sub packet and the second unitary sub packet and the configuration information in the third server may refer to the description of step 232 in fig. 6 to 9, and the configuration information of the first unitary sub packet and the configuration information and the second unitary sub packet and the configuration information may refer to the description in fig. 6 to 9, which is not described herein again.

In some embodiments, the first server may be server C221 shown in fig. 6-9, such as an application marketplace server, the third server may be server D222 shown in fig. 6-9, such as a meta-intelligent platform HAG server, and the second server may be server E223 shown in fig. 6-9, such as a content delivery network CDN server.

In some embodiments, the third device is specifically configured to send the first message to a third server; the third server is used for sending a second message to the third equipment when the equipment type of the third equipment is determined to be the first equipment type, wherein the second message carries the storage address of the first metasubtyping packet in the second server; the third device is specifically configured to download the first metalized package from the second server based on a storage address of the first metalized package in the second server.

The specific implementation process of the third device sending the first message to the third server may refer to the description of step 241 in fig. 6-9, where the specific implementation process of the third server sending the second message to the third device when determining that the device type of the third device is the first device type may refer to the description of step 242 in fig. 6-9, and the description of step 243 in fig. 6-9 may be referred to when the third device downloads the first metaization package from the second server based on the storage address of the first metaization package in the second server, which is not described herein again.

In some embodiments, the first componentization package or the second componentization package comprises: a first module and a second module set; the first module is a software module capable of supporting the main page display of the first application; the second module set comprises at least one second module, and each second module is a software module of other functions except for the main page display in the first application.

The specific implementation process of the first module may refer to the description of the main module 1 in the first group of the hap packets 21 or the main module 2 in the second group of the hap packets 22 or the main module 3 in the third group of the hap packets 23 in fig. 6 to 9, and the specific implementation process of the second module set may refer to the description of the dynamic characteristic module 11 and the dynamic characteristic module 12 in the first group of the hap packets 21 or the dynamic characteristic module 21 and the dynamic characteristic module 22 in the second group of the hap packets 22 or the dynamic characteristic module 31 and the dynamic characteristic module 32 in the third group of the hap packets 23 in fig. 6 to 9, which is not described herein again.

Therefore, each meta-sub package can comprise a first module and at least one second module, the setting of the first module can ensure that the user number can browse the main page of the application, and the setting of the second module can enrich the application, so that the application can have other functions, the flexibility of developing other functions of the application by a developer is facilitated, and the experience of the user using the application is also facilitated to be improved.

In some embodiments, when at least two second modules are included in the second set of modules, the first componentization package or the second componentization package further includes: a third module; the third module is a software module of a common function on which the at least two second modules depend.

The specific implementation process of the third module may refer to the description of the common module 1 in the first group of the hap packets 21, the common module 2 in the second group of the hap packets 22, or the common module 3 in the third group of the hap packets 23 shown in fig. 6 to 9, which is not described herein again.

The common functions depended by the at least two second modules are software modules with high compiling coupling degree in the at least two second modules. Thereby, it is facilitated to reduce the dependency between the at least two second modules and also to reduce the size of the at least two second modules.

In some embodiments, the master module further includes at least one of a language resource, a resolution resource, and an application binary interface, ABI, resource corresponding to the master module.

In some embodiments, each second module further comprises at least one of a language resource, a resolution resource, and an application binary interface, ABI, resource to which the second module corresponds.

In some embodiments, the first componentization package or the second componentization package further comprises: a fourth module; the fourth module includes at least one of a language resource, a resolution resource, and an application binary interface, ABI, resource corresponding to the main module and each of the second modules. Thereby, the size of the main module and each of the second modules is reduced, and the dependency between the main module and each of the second modules is reduced.

The specific implementation process of the fourth module may refer to the description of the language characteristic module 1 and the ABI characteristic module 1 and the resolution characteristic module 1 in the first group of the hap package 21 or the language characteristic module 2 and the ABI characteristic module 2 and the resolution characteristic module 2 in the second group of the hap package 22 or the language characteristic module 3 and the ABI characteristic module 3 and the resolution characteristic module 3 in the third group of the hap package 23 shown in fig. 6 to 9, which is not described herein again.

Based on some of the foregoing embodiments, the application downloading method provided by the present application is described below.

Illustratively, the present application provides an application download method.

Referring to fig. 10, fig. 10 is a flowchart illustrating an application downloading method according to the present application. The execution subject of the application downloading method of the present application is the second device, which is the server-side device 22 mentioned in fig. 6 to 9. The second device comprises a first metaquantization package corresponding to the first device type and a second metaquantization package corresponding to the second device type, the first metaquantization package and the second metaquantization package are obtained based on an development kit of a first application, the development kit is written by at least a first programming language and a second programming language, the first programming language is different from the second programming language, the first programming language corresponds to the first device type, the second programming language corresponds to the second device type, and the second device type is different from the second device type.

As shown in fig. 10, the application downloading method of the present application may include:

s101, the second device receives a first message from the third device, wherein the first message is used for requesting to download a first application, and the first message carries the device type of the third device.

S102, when the device type of the third device is determined to be the first device type, the second device sends a second message to the third device, the second message is used for indicating a storage address of the first metaization package, the storage address of the first metaization package is used for the third device to download the first metaization package, and the first application is installed based on the first metaization package.

The second device may refer to the description of the server-side device 22 in fig. 6 to fig. 9, the third device may refer to the description of the user-side device 23 in fig. 6 to fig. 9, the development package of the first application may refer to the description of the application package (App Pack) in fig. 6 to fig. 9, the first unitary sub-package and the binary sub-package may refer to the description of the first group of hap packages 21, the second group of hap packages 22, or the third group of hap packages 23 in the application package (haps) 20 in fig. 6 to fig. 9, the specific implementation process of the third device sending the first message to the second device may refer to the description of step 241 in fig. 6 to fig. 9, and the specific implementation process of the second device sending the second message to the third device when determining that the device type of the third device is the second device type may refer to the description of step 242 in fig. 6 to fig. 9, which is not described herein. In addition, the present application does not limit the specific implementation manner of the first message and the second message.

In some embodiments, the second device is a server-side device and the third device is a user-side device.

In some embodiments the method further comprises: the second device receiving the development kit from the first device; the second device obtains a first componentization package and a second componentization package based on the development package.

The first device may refer to the description of the developer device 21 shown in fig. 6 to fig. 9, the specific implementation process of the second device receiving the development kit from the first device may refer to the description of step 22 in fig. 6 to fig. 9, and the specific implementation process of the second device obtaining the first componentization package and the second componentization package based on the development kit may refer to the description of step 231 in fig. 6 to fig. 9, which is not described herein again. In some embodiments, the first device is a developer device.

In some embodiments the second device comprises: a first server, a second server and a third server; the second device obtains a first componentization package and a second componentization package based on the development package, and the method comprises the following steps: the first server unpacks and divides the development packet to obtain a first componentization packet and a second componentization packet; the first server stores the first metasubtization package and the second metasubtization package in a second server; the first server stores the configuration information of the first metaalization packet, the second metaalization packet and the configuration information in a third server, wherein the configuration information of the first metaalization packet at least comprises the following components: the first metaverse package stores the address in the second server.

In some embodiments, the first server may be server C221 of fig. 6-9, such as an application marketplace server, the third server may be server D222 of fig. 6-9, such as a meta-intelligent platform HAG server, and the second server may be server E223 of fig. 6-9, such as a content delivery network CDN server.

In some embodiments the second device receives a first message from a third device, comprising: the third server receives a first message sent by the third equipment; when the second device determines that the device type of the third device is the first device type, sending a second message to the third device, where the second message includes: and when determining that the device type of the third device is the first device type, the third server sends a second message to the third device, wherein the second message carries a storage address of the first metaquantization packet in the second server, and the storage address of the first metaquantization packet in the second server is used for the third device to download the first metaquantization packet from the second server.

Therefore, the third device can request the third server to inquire the storage address of the first metapacket, and obtain the first metapacket in the second server, so that the operation steps of the third device are defined.

In some embodiments, the first or second componentized package comprises: a first module and a second module set; the first module is a software module which can support the display of a main page of a first application; the second module set comprises at least one second module, and each second module is a software module of other functions except for the main page display in the first application.

The specific implementation process of the first module may refer to the description of the master module 1 in the first group of hap packets 21 or the master module 2 in the second group of hap packets 22 or the master module 3 in the third group of hap packets 23 shown in fig. 6 to 9, and the specific implementation process of the second module set may refer to the description of the dynamic characteristic module 11 and the dynamic characteristic module 12 in the first group of hap packets 21 or the dynamic characteristic module 21 and the dynamic characteristic module 22 in the second group of hap packets 22 or the dynamic characteristic module 31 and the dynamic characteristic module 32 in the third group of hap packets 23 shown in fig. 6 to 9, which is not described herein again.

Thus, the main module can display a main page supporting the corresponding voice based on the voice resource. The main module may display a main page supporting a corresponding resolution based on the resolution resource. The master module may display a master page supporting the corresponding ABI based on the application binary interface ABI resource.

Thus, each second module can display a function supporting a corresponding voice based on the voice resource. Each of the second modules may display a function supporting a corresponding resolution based on the resolution resource. Each second module may display functionality that supports a corresponding ABI based on the application binary interface ABI resource.

Illustratively, the present application provides a second device comprising: at least one memory and at least one processor; the memory is used for storing program instructions; the processor is configured to invoke the program instructions in the memory to cause the second device to perform the application download method of the previous embodiment.

Exemplarily, the present application provides a computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, causes a second device to implement the application downloading method of the foregoing embodiment.

Illustratively, the present application provides a computer program product comprising: and executing the instructions, wherein the executing instructions are stored in a readable storage medium, and the at least one processor of the second device can read the executing instructions from the readable storage medium, and the executing instructions executed by the at least one processor cause the second device to implement the application downloading method of the foregoing embodiment.

Illustratively, the present application provides a chip, which is connected to a memory, or has a memory integrated thereon, and when a software program stored in the memory is executed, the application downloading method of the foregoing embodiments is implemented.

In the above-described embodiments, all or part of the functions may be implemented by software, hardware, or a combination of software and hardware. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that includes one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims

1. A communication system, comprising: a first device, a second device, and a third device;

the first device is configured to send a development kit of a first application to the second device, where the development kit is written in at least a first programming language and a second programming language, the first programming language is different from the second programming language, the first programming language corresponds to a first device type, the second programming language corresponds to a second device type, and the second device type is different from the first device type;

the second device is configured to obtain, based on the development kit, a first componentization packet corresponding to the first device type and a second componentization packet corresponding to the second device type;

the third device is configured to send a first message to the second device, where the first message is used to request downloading of the first application, and the first message carries a device type of the third device;

the second device is configured to send a second message to the third device when it is determined that the device type of the third device is the first device type, where the second message is used to indicate a storage address of the first metaquantization package, the first device is a developer device, the second device is a server-side device, and the third device is a user-side device.

2. The communication system according to claim 1, wherein the second device comprises: a first server, a second server and a third server;

the first server is used for unpacking and dividing the development package to obtain the first meta-sub-package and the second meta-sub-package;

the first server is further used for storing the first metasubtyping package and the second metasubtyping package in the second server;

the first server is further configured to store the configuration information of the first meta-sub package and the second meta-sub package and the configuration information in the third server, where the configuration information of the first meta-sub package at least includes: the first meta-sub package is a storage address in the second server, the first server is an application market server, the third server is a meta-sub intelligent platform HAG server, and the second server is a Content Delivery Network (CDN) server.

3. The communication system of claim 2,

the third device is specifically configured to send the first message to the third server;

the third server is configured to send the second message to the third device when it is determined that the device type of the third device is the first device type, where the second message carries a storage address of the first meta-packet in the second server;

the third device is specifically configured to download the first metaversed package from the second server based on a storage address of the first metaversed package in the second server.

4. The communication system of claim 3, wherein the first or second componentization packet comprises: a first module and a second module set;

the first module is a software module capable of supporting the display of a main page of the first application; the second module set comprises at least one second module, and each second module is a software module of other functions except for the main page display in the first application.

5. The communication system according to claim 4, wherein when at least two second modules are included in the second module set, the first componentization packet or the second componentization packet further comprises: a third module;

the third module is a software module of a common function on which the at least two second modules depend.

6. The communication system of claim 5, wherein the first module further comprises at least one of a language resource, a resolution resource, and an Application Binary Interface (ABI) resource corresponding to the first module.

7. The communication system of any of claims 4-6, wherein each second module further comprises at least one of a language resource, a resolution resource, and an Application Binary Interface (ABI) resource corresponding to the second module.

8. The communication system according to any of claims 4-6, wherein the first componentization package or the second componentization package further comprises: a fourth module;

the fourth module includes at least one of a language resource, a resolution resource, and an application binary interface, ABI, resource corresponding to the first module and each second module.

9. The communication system according to any of claims 1-6, wherein the first programming language or the second programming language comprises: at least one of Java computer programming language, C/C + + computer programming language, and JavaScript computer programming language.

10. An application downloading method is applied to a second device, the second device comprises a first metaization package corresponding to a first device type and a second metaization package corresponding to a second device type, the first metaization package and the second metaization package are obtained based on an development kit of a first application, the development kit is written by at least a first programming language and a second programming language, the first programming language is different from the second programming language, the first programming language is corresponding to the first device type, the second programming language is corresponding to the second device type, and the second device type is different from the first device type;

the method comprises the following steps:

the second device receives a first message from a third device, wherein the first message is used for requesting to download a first application, and the first message carries the device type of the third device;

when the second device determines that the device type of the third device is the first device type, sending a second message to the third device, where the second message is used to indicate a storage address of the first componentization package, and the storage address of the first componentization package is used for the third device to download the first componentization package, and install the first application based on the first componentization package, where the first device is a developer device, the second device is a server-side device, and the third device is a user-side device.

11. The method of claim 10, further comprising:

the second device receiving the development kit from the first device;

the second device obtains the first componentization package and the second componentization package based on the development package.

12. The method of claim 11, wherein the second device comprises: a first server, a second server and a third server;

the second device obtains the first componentization package and the second componentization package based on the development package, and the method includes:

the first server unpacks and divides the development package to obtain the first meta-sub-package and the second meta-sub-package;

the first server storing the first metalized package and the second metalized package in the second server;

the first server stores the configuration information of the first metaalized packet and the second metaalized packet and the configuration information in the third server, and the configuration information of the first metalized packet at least includes: the first meta-sub package is a storage address in the second server, the first server is an application market server, the third server is a meta-sub intelligent platform HAG server, and the second server is a Content Delivery Network (CDN) server.

13. The method of claim 12,

the second device receiving a first message from a third device, comprising:

the third server receives the first message sent by the third equipment;

when determining that the device type of the third device is the first device type, the second device sends a second message to the third device, where the second message includes:

and when determining that the device type of the third device is the first device type, the third server sends the second message to the third device, where the second message carries a storage address of the first metaquantization packet in the second server, and the storage address of the first metaquantization packet in the second server is used for the third device to download the first metaquantization packet from the second server.

14. The method of claim 13, wherein the first or second componentization package comprises: a first module and a second module set;

15. The method of claim 14, wherein when at least two second modules are included in the second set of modules, the first componentization package or the second componentization package further comprises: a third module;

16. The method of claim 15, wherein the first module further comprises at least one of a language resource, a resolution resource, and an Application Binary Interface (ABI) resource corresponding to the first module.

17. The method of any of claims 14-16, wherein each second module further comprises at least one of a language resource, a resolution resource, and an Application Binary Interface (ABI) resource corresponding to the second module.

18. The method of any one of claims 14-16, wherein the first componentization package or the second componentization package further comprises: a fourth module;

19. The method of any of claims 10-16, wherein the first programming language or the second programming language comprises: at least one of Java computer programming language, C/C + + computer programming language, and JavaScript computer programming language.

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

the memory is to store program instructions;

the processor is operable to invoke the program instructions in the memory to cause the second device to perform the application download method of any of claims 10-19.

21. A chip system, wherein the chip system is applied to an electronic device comprising a memory, a display screen, and a sensor; the chip system includes: a processor; the electronic device, when the processor executes the computer instructions stored in the memory, performs the application download method as recited in any of claims 10-19.

22. A computer-readable storage medium, on which a computer program is stored, the computer program, when being executed by a processor, causes an electronic device to carry out the application download method of any one of claims 10 to 19.