A method, device and storage medium for dynamically updating a software development kit

Abstract

This application provides a method, apparatus, and computer-readable storage medium for dynamically updating a software development kit (SDK). The method includes: when a host application starts, determining that the target plugin included in the SSD corresponding to the host application has been updated; copying the updated target plugin to the project directory of the host application; changing the class loading mechanism through a hook, loading the class of the target plugin in the host application based on the changed loading mechanism, and reflecting on and calling the methods of the class of the target plugin to implement the target plugin.

Description

Technical Field

[0001] This application relates to the field of data processing technology in financial technology (Fintech), and includes, but is not limited to, a method, apparatus, and computer-readable storage medium for dynamically updating a software development kit. Background Technology

[0002] With the development of computer technology, more and more technologies are being applied in the financial field, and the traditional financial industry is gradually transforming into financial technology (Fintech). However, due to the security and real-time requirements of the financial industry, Fintech also places higher demands on technology.

[0003] In the fintech sector, various applications can directly display information to users on mobile devices. Currently, a common method for displaying information through applications is to embed the Software Development Kit (SDK) as a whole into the application. SDK updates require a component linker, and each update necessitates patch generation. Patch synthesis may fail, increasing the cost of reverting to an older version. Existing SDK update methods involve decompression, repackaging, and copying the dex or so files.

[0004] However, this update method is not only cumbersome, but also prone to errors during file operations. For example, a sudden program exit or a power outage can cause file writing to fail. Therefore, the method of copying dex or so files to update the SDK is very prone to problems, leading to update failure. Summary of the Invention

[0005] This application provides a method, apparatus, and computer-readable storage medium for dynamically updating a software development kit (SDK), in order to solve the problem that updating an SDK by copying a dex file or a so file is prone to failure in related technologies.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a method for dynamically updating a software development kit, including:

[0008] When the host application starts, it is determined from the tool development end that the target plugins included in the software development kit corresponding to the host application have been updated.

[0009] Copy the updated target plugin to the project directory of the host application;

[0010] By changing the class loading mechanism through hooks, the target plugin's class is loaded in the host application based on the changed loading mechanism, and the methods of the target plugin's class are called by reflection to implement the target plugin.

[0011] This application provides a device, including:

[0012] The memory is used to store executable instructions; the processor is used to implement the above method when executing the executable instructions stored in the memory.

[0013] This application provides a computer-readable storage medium storing executable instructions for implementing the above-described method when executed by a processor.

[0014] The embodiments of this application have the following beneficial effects:

[0015] When the host application starts, it determines if the target plugins in the software development kit (SDK) corresponding to the host application have been updated. The updated target plugins are copied to the host application's project directory. A hook is used to change the class loading mechanism, and based on the changed mechanism, the target plugin's class is loaded in the host application. Methods of the target plugin's class are then called via reflection to implement the target plugin. This approach eliminates the need to encapsulate and copy the plugin's DEX file to update the SDK, achieving a plug-in-based SDK update. This not only reduces the probability of file operation failures but also allows the SDK to be broken down into multiple plugins, ensuring fine-grained plugin updates. Specifically, when a plugin is updated, the SDK is updated using a plug-in-based update method, thus saving bandwidth spent downloading plugins and time spent integrating them. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of a multi-threaded concurrency scenario provided in an embodiment of this application;

[0017] Figure 2 This is an optional flowchart illustrating the method for dynamically updating a software development kit provided in an embodiment of this application;

[0018] Figure 3 This is an optional flowchart illustrating the method for dynamically updating a software development kit provided in an embodiment of this application;

[0019] Figure 4 This is a schematic diagram of an optional architecture of the facial recognition access control SDK provided in this application embodiment;

[0020] Figure 5 This is a schematic diagram of a plugin update scenario corresponding to the method for dynamically updating the software development kit provided in this application embodiment;

[0021] Figure 6 This is an optional flowchart illustrating the method for dynamically updating a software development kit provided in an embodiment of this application;

[0022] Figure 7 This is a schematic diagram of the class loader loading new host dexElements according to an embodiment of this application;

[0023] Figure 8 This is an optional flowchart illustrating the method for dynamically updating a software development kit provided in an embodiment of this application;

[0024] Figure 9 This is an optional flowchart illustrating a method for dynamically updating a software development kit provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of this application pertain. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit the application.

[0027] The following describes exemplary applications of the device with the dynamically updated software development kit provided in this application. This device can be implemented as any terminal with a screen display function, such as a laptop, tablet, desktop computer, mobile device (e.g., mobile phone, portable music player, personal digital assistant, dedicated messaging device, portable gaming device), or intelligent robot, or as a server. The following will describe exemplary applications of the device with the dynamically updated software development kit implemented as a terminal.

[0028] See Figure 1 , Figure 1 This is a schematic diagram of the structure of the terminal 100 provided in the embodiments of this application. Figure 1The terminal 100 shown includes at least one processor 110, at least one network interface 120, a user interface 130, and a memory 150. The various components in the terminal 100 are coupled together via a bus system 140. It is understood that the bus system 140 is used to implement communication between these components. In addition to a data bus, the bus system 140 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 1 The general labeled all buses as Bus System 140.

[0029] The processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0030] User interface 130 includes one or more output devices 131 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 130 also includes one or more input devices 132, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0031] Memory 150 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. Memory 150 may optionally include one or more storage devices physically located remote from processor 110. Memory 150 may include volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM), and volatile memory may be random access memory (RAM). The memory 150 described in this application embodiment is intended to include any suitable type of memory. In some embodiments, memory 150 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

[0032] Operating system 151 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0033] The network communication module 152 is used to reach other computing devices via one or more (wired or wireless) network interfaces 120, such as Bluetooth, WiFi, and Universal Serial Bus (USB).

[0034] The input processing module 153 is used to detect and translate one or more user inputs or interactions from one or more input devices 132.

[0035] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 1 A device 154 for dynamically updating a software development kit (SDK) stored in memory 150 is shown. This device 154 can be a device for dynamically updating an SSD in terminal 100, and can be software in the form of programs and plug-ins, including the following software modules: a processing module 1541 and an acquisition module 1542. These modules are logically linked and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0036] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the method of dynamically updating the software development kit provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0037] The method for dynamically updating the software development kit provided in this application will be described below with reference to exemplary applications and implementations of the terminal 100 provided in the embodiments of this application. See also Figure 2 , Figure 2 This is an optional flowchart illustrating a method for dynamically updating a software development kit provided in an embodiment of this application, which will be combined with... Figure 2 The steps shown are explained below.

[0038] Step S201: When the host application starts, determine that the target plugins included in the software development kit corresponding to the host application on the tool development end have been updated.

[0039] The method for dynamically updating the Software Development Kit (SDK) provided in this application is based on a component-based architecture, which decomposes the SDK into modules at the finest granularity. All component modules are made into plugins, enabling plugin-based updates of the SDK. Here, componentization and pluginization are explained: Componentization refers to dividing an application (APP) into multiple code modules, each of which is a component (Module). During development, these components can depend on each other or be debugged individually, but in the final release, these components are merged into a single Android application package (APK). Pluginization refers to splitting the entire APP into multiple functional modules, including a host and multiple plugins. Each functional module is an APK, and in the final packaging, the host APK and plugin APKs are packaged separately or together.

[0040] In this embodiment of the application, step S201, when the host application starts, determines that the target plugins included in the software development kit corresponding to the host application on the tool development end have been updated. This can be achieved through the following steps:

[0041] First, when the host application starts, it retrieves the version number of the same plugin both locally and in the cloud;

[0042] Secondly, when there is a target association between the local version number and the cloud version number of the same plugin, it is determined that the same plugin has been updated, where the target plugin includes the same plugin.

[0043] For example, if the terminal determines that the version number of the same plugin on the local machine is less than the version number on the cloud machine, then the terminal determines that there is a target association between the version number of the same plugin on the local machine and the version number on the cloud machine, and at this time, it determines that the plugin has been updated.

[0044] In practical applications, each plugin included in the SDK has a name and version number. When updating a plugin, the plugin to be updated resides in the cloud. The host application checks the plugin version number each time it starts to determine whether to download and update it. If a version exists, the terminal will replace the plugin after a successful download.

[0045] In addition, to improve flexibility and determine when the target plugins included in the software development kit corresponding to the host application of the tool development end are updated, the following steps can also be taken:

[0046] When the host application starts, retrieve the most recent update time of the local plugin;

[0047] If the duration between the most recent update and the current time exceeds a preset duration, the plugin is identified as the target plugin, and the target plugin is updated from the cloud. Here, the current time can be understood as the time when the host application started.

[0048] It is understandable that by using the above method, when updating a plugin, it is possible to update not only based on the version number, but also based on the local update duration, thus achieving flexibility in updating the target plugin.

[0049] Step S202: Copy the updated target plugin to the project directory of the host application.

[0050] In this embodiment, when the terminal determines that a certain local plugin has an updated target plugin in the cloud, it copies the updated target plugin to the project directory of the host application so that the plugin-based update SDK can be executed subsequently.

[0051] Step S203: Change the class loading mechanism through hooks, load the target plugin class in the host application based on the changed loading mechanism, and call the methods of the target plugin class by reflection to implement the target plugin.

[0052] Here, the host application is the installed and running APK. When the Android system's JVM loads the host application's dex file, it can call the methods of the host application's classes. To implement the plugin functionality, the host application must call the plugin's methods. This application loads the target plugin's class in the host application through a modified loading mechanism and uses reflection to call the target plugin's class methods, thus enabling the target plugin to execute the methods of these classes.

[0053] In this embodiment, the downloaded updated target plugin is the new plugin. The SDK uses reflection to hook the underlying code of the Android system. According to the class loading process of the Android system's Java Virtual Machine (JVM), after obtaining the class loader in the host application, the class loader object is modified. The updated target plugin APK's DEX file is inserted into the host application's executable file array `dexElements` to run the updated target plugin APK, thereby enabling the host application to call the updated target plugin's methods.

[0054] Here, the implementation process of changing the class loading object is further explained. In this embodiment, when changing the class loading mechanism by hooking, it can be achieved by calling `BaseDexClassLoader.findClass()`. Inside the `findClass()` method, `findClass()` is called for each element of the `Element[]` array, where each element is a dex file. When the host program starts, the JVM automatically loads the host's dex files. At this time, the host's `dexElements` contains all the host's dex files, and the host's classes and methods can be directly called. However, the plugin's class dex files are not in the host's `dexElements`, so the plugin's classes cannot be directly called. Since `dexElements` is an array, this application proposes to hook the host's class loading using reflection. Specifically, the host's `dexElements` and the plugin's `dexElements` are obtained, merged to generate a new `dexElements`, and the host loads this new `dexElements`. This loads both the plugin's and the host's dex files into the host, thus changing the class loading object.

[0055] Currently, SDK updates use a differential upgrade method, requiring differential plugin processing on a cloud-based deployment platform and plugin restoration on the application terminal. It also relies on a component linker for dynamic plugin updates. Furthermore, plugin patches are updated by decompressing, repackaging, and copying files, making the update mechanism cumbersome. Copying dex or so files to update the SDK is prone to problems, leading to update failures. However, the application area has abandoned this method of repackaging and copying plugin dex files to update the SDK, achieving plugin-based SDK updates. This not only reduces the probability of file operation failures but also allows for fine-grained plugin updates, thus saving bandwidth spent downloading plugins and time spent integrating them.

[0056] The method for dynamically updating a software development kit (SDK) provided in this application determines when the target plugins included in the SSD corresponding to the host application are updated when the host application starts. The updated target plugins are copied to the project directory of the host application. A hook is used to change the class loading mechanism, and based on the changed loading mechanism, the class of the target plugin is loaded in the host application. Methods of the target plugin class are then called using reflection to implement the target plugin. This method eliminates the need to encapsulate and copy the plugin's DEX file to update the SDK, achieving plugin-based SDK updates. This not only reduces the probability of file operation failures but also allows for fine-grained plugin updates, saving bandwidth for downloading plugins and time for integrating plugins, thus reducing maintenance costs.

[0057] Of course, in other embodiments of this application, the entire SDK can also be divided into one plugin or a small number of plugins. This division method can realize plugin-based SDK updates, but compared with fine-grained module splitting and making all component modules into plugins, the update speed is slower and the process consumption is also increased.

[0058] In some embodiments, before step S201, when the host application starts, determines that the target plugins included in the software development kit corresponding to the host application are updated, can be determined through... Figure 3 The steps shown yield the host application:

[0059] Step S301: Obtain the software development kit released by the tool development end.

[0060] The software development kit (SDK) includes a binary archive file and at least two plugins, each containing a target plugin. The binary archive file includes an AAR file, which provides an interface for the terminal to call the at least two plugins.

[0061] Step S302: Copy the binary archive file and at least two plugins to the application's project directory.

[0062] Step S303: Integrate at least two plugins by calling the interface in the binary archive file through the application to obtain the host application.

[0063] Here, the terminal copies the binary archive file and at least two plugins to the application's project directory. The terminal then integrates the at least two plugins by calling the interface in the aar file through the application, thus obtaining the host application. The host application is an installed and running APK. The Android system's JVM loads the host application's dex file, which allows it to call the methods of the host application's classes. To implement the plugin functionality, the host application must call the plugin's methods.

[0064] For example, see Figure 4 As shown, taking updating the facial recognition access control SDK as an example, the architecture of the facial recognition access control SDK is as follows: Figure 4 As shown, the access control facial recognition SDK 401 consists of an AAR file 402 and multiple plugins 403. Here, a plugin-based SDK update approach is used to create plugins for different functions. For example, the access control facial recognition SDK includes an initialization plugin, a face recognition plugin, a detail reporting plugin, a task distribution plugin, a network request plugin, an Android local database plugin (such as the WeChat Database (WCDB)), an AI algorithm face detection plugin, an AI algorithm infrared liveness detection plugin, an AI algorithm liveness capture plugin, an AI algorithm face retrieval plugin, a standard (normal) public library plugin, a data analysis and reporting plugin, a log library plugin, and a camera library plugin. When the terminal loads plugins, it needs to use dex and so files. A plugin is essentially an APK, containing dex, so, and resource files. The bandwidth required for the terminal to download new plugins and the size of the plugin package determine the need to create multiple plugins for the functionality. When a bug occurs or a plugin needs upgrading, the terminal can find the corresponding plugin in the cloud for updating; other plugins do not need to be updated. This significantly reduces bandwidth consumption when the terminal downloads new plugins. The multiple plugins are divided using a component-based architecture, which minimizes the granularity of each module into individual plugins. Here, aar is a shell that calls SDK methods to launch the SDK, enabling better terminal access to the cloud SDK.

[0065] This application provides a plug-in approach to updating the access control facial recognition SDK, providing one AAR file and multiple plugins. Since the access control facial recognition SDK contains multiple modules, especially with large files representing various algorithm models, updating the SDK by copying dex or so files consumes significant bandwidth, particularly for IoT devices. To address this, this application adopts a component-based architecture, breaking down the modules into numerous plugins for fine-grained updates, thus saving bandwidth and loading time for plugin downloads. When the access control facial recognition SDK needs an upgrade, the plugins are dynamically updated on the device. During terminal integration, the AAR file and all plugins are copied to the project directory, and the interfaces provided in the SDK's AAR file are called to implement access control facial recognition. The principle behind the plug-in update of the access control facial recognition SDK is based on the Android JM class loading mechanism and the underlying system source code. The host application loads the updated plugin's dex file, allowing it to call the updated plugin's classes and methods.

[0066] In some embodiments, step S202, copying the updated target plugin to the project directory of the host application, can be achieved by loading the executable file and dynamic library files of the virtual machine included in the updated target plugin into the project directory. The executable file of the virtual machine includes a dex file, and the dynamic library files include so files.

[0067] For example, see Figure 5 As shown, in a feasible plugin update scenario, the tool development end 501, also known as the SDK end, updates the plugin and pushes the updated plugin to the cloud 502. The user terminal 503 retrieves the updated plugin from the cloud and implements the plugin on the terminal side.

[0068] Here, each plugin's name identifies it, and each plugin has an internal version number stored in a text document (TXT) within the APK. When the SDK updates a plugin, the new plugin is pushed to the cloud. Each time the user's application launches, it requests the cloud to check for new plugins. The comparison method is: if a plugin with the same name as the one on the cloud is found, their version numbers are compared to determine whether to download the cloud plugin; if no plugin with the same name is found, no update is needed. Downloaded new plugins can be placed in the same location as the old plugins to replace them. Plugins can be selected to use a Secure Digital Memory Card (SD) or internal storage. Here, the access control facial recognition SDK selects internal storage to prevent accidental deletion of SD card content by the user. If the download fails, the old plugins are retained unaffected, and their version numbers remain the same.

[0069] A plugin is essentially an APK, a compressed file containing dex, libs, and res directories. The dex directory stores the compiled binary bytecode files of the classes; the assets directory stores the algorithm model library; the libs directory stores the shared object (.so) libraries; and the res directory stores resource files. Since the access control facial recognition SDK lacks UI and other resource files, the res directory is empty. The APK integrated with the access control facial recognition SDK on the user terminal is called the host. The host is the APK that is installed and run. The Android system's JVM loads the host's dex file to call the methods of the host's classes. For the host to implement the access control facial recognition function, it must call the methods of the plugins within the SDK. Plugins are also APKs, copied into the project as part of the SDK, and are not installed; therefore, the host cannot call the plugin's class methods. This application uses hooks to change the class loading mechanism to load the plugin's classes within the host. Once the class is loaded, reflection is used to call the class's methods and obtain its attributes. During the class loading phase, the JVM performs three tasks: First, it obtains the binary byte stream defining the class using its fully qualified name. Second, the static storage structure represented by this byte stream is transformed into the runtime data structure of the method area. Third, a Class object representing this class is generated in the Java heap, serving as the access point for the method area data. In other words, after the JVM loads each class from the dex file through the ClassLoader, it can execute the methods of these classes.

[0070] Furthermore, the virtual machine's executable file includes a dex file. The updated target plugin's virtual machine executable file is loaded into the project directory, which can then be accessed via... Figure 6 The steps shown are to be implemented as follows:

[0071] Step S601: Obtain the dexElements of the host application and the dexElements of the target plugin through reflection.

[0072] Here, the terminal uses reflection to hook the underlying system source code. After obtaining the host application's class loader, it uses reflection to obtain the host application's dexElements array object; then it creates the target plugin's class loader and uses reflection to obtain the target plugin's dexElements object.

[0073] Step S602: Merge the dexElements of the host application and the dexElements of the target plugin to obtain the target dexElements.

[0074] Step S603: Assign the target dexElements to the host application's dexElements.

[0075] Here, the terminal merges the host application's `dexElements` and the target plugin's `dexElements` into a new `dexElements` array, and then uses reflection to assign this new `dexElements` array object to the host application's `dexElements`. In other words, it combines... Figure 7 As shown, at this point, the host application's dexElements, i.e., the new host dexElements701, becomes the host application's dexElements and the target plugin's dexElements. This allows the host application to load all classes and methods of the target plugin's dex file upon startup.

[0076] Furthermore, let's explain class loading in more detail. A Java program consists of multiple classes, and during program execution, these classes need to be loaded into the JVM via a ClassLoader to run correctly. Similarly, Android programs also require a ClassLoader mechanism to load classes into Android's Dalvik / ART for proper operation. However, unlike Java's ClassLoader, Android APK packaging packages class files into one or more dex files, which are then processed by BaseDexClassLoader. By examining the source code, this application confirms that class loading can be achieved by using DexClassLoader to load a dex file, thereby successfully loading all classes corresponding to the dex. Class loading ultimately involves calling BaseDexClassLoader's findClass() method. The entire loading process is as follows: First, it checks if the class has already been loaded. If it has, it retrieves and returns the class. If it hasn't been loaded, and parent is not null, it calls parent.loadClass to load the class, recursively. If the class is found or loaded, it returns; otherwise, it attempts to load the class itself.

[0077] Furthermore, the dynamic library files include .so files. The updated target plugin's included dynamic library files are loaded into the project directory, which can then be accessed via... Figure 8 The steps shown are to be implemented as follows:

[0078] Step S801: Merge the nativeLibraryPathElements of the host application and the nativeLibraryPathElements of the target plugin to obtain the target nativeLibraryPathElements.

[0079] The nativeLibraryPathElements array refers to the array of dynamic library paths.

[0080] Step S802: Assign the target nativeLibraryPathElements to the nativeLibraryPathElements of the host application.

[0081] In this embodiment, since dex is a binary bytecode file of a regular class, if we want to call the methods of the plugin's so package, we can also hook it through reflection. We set the host's nativeLibraryPathElements to the host's nativeLibraryPathElements plus the plugin's nativeLibraryPathElements, and assign the merged array to the host's nativeLibraryPathElements. This is a call to a regular class. For the so files under the libs directory, we also need to be able to call the methods of the plugin's so. If we only use the addDexPath method to insert the plugin's dex into the host's dexElements, and the plugin APK contains a loaded so file, an UnsatisfiedLinkError exception will be thrown because the dex does not contain the so file. The `System.loadLibrary` source code obtains the library path by iterating through the `nativeLibraryPathElements` array in `BaseDexClassLoader` and querying child elements. This application locates `nativeLibraryPathElements`, which is generated by the `makePathElements` method. Therefore, this application uses reflection to call the `makePathElements` method, passing in the `librarySearchPath` path to obtain a new `nativeLibraryPathElements` array, and then merges the old and new arrays. The hooking method is the same as the method used with ordinary classes described above.

[0082] Regarding the algorithm model files in the assets directory of the plugin, since the SDK only needs to load the files in the corresponding directory, after downloading the plugin, unzip the plugin APK, copy the algorithm model files in the assets directory to the data assets directory corresponding to the host APK, and then replace and install it.

[0083] In other embodiments of this application, the software development kit further includes at least two algorithm plugins, and the host application can switch between different algorithms. The method for dynamically updating the software development kit provided in this application also includes, for example... Figure 9 The steps shown are as follows:

[0084] Step S901: When the host application detects an algorithm switching event, it obtains at least two algorithm type flag bits sent from the cloud.

[0085] Step S902: Select the target algorithm flag corresponding to the algorithm switching event from at least two algorithm type flags through the intermediate layer, and load the target algorithm plugin from the cloud based on the target algorithm flag.

[0086] In this embodiment, the terminal achieves free loading and switching between multiple algorithms through an intermediate layer. When the host application detects an algorithm switching event, the terminal sends a request based on the event to load the switched algorithm, i.e., load the switched algorithm plugin, and then calls the intermediate layer's algorithm application programming interface (API). It should be noted that when switching algorithms is required, only the algorithm type flag bit needs to be changed in the terminal's intermediate layer according to the algorithm type flag bit sent from the cloud. The method for calling the intermediate layer is that the intermediate layer loads the specific plugin from the cloud based on its internal algorithm flag bit. This significantly reduces the package size and maintenance costs.

[0087] Step S903: Unzip the target algorithm plugin and copy the unzipped algorithm model file to the data native resource file directory corresponding to the host application to replace the algorithm model file in the data native resource file directory, and install the unzipped algorithm model file.

[0088] The following continues to describe an exemplary structure of the apparatus 154 for dynamically updating the software development kit provided in the embodiments of this application, implemented as a software module. In some embodiments, such as Figure 1 As shown, the software modules stored in the dynamically updated software development kit (SDK) device 154 in the memory 150 can be the dynamically updated SSD device in the terminal 100, including:

[0089] Processing module 1541 is used to determine, when the host application starts, whether the target plugins included in the software development kit corresponding to the host application on the tool development end have been updated.

[0090] Processing module 1541 is used to copy the updated target plugin to the project directory of the host application.

[0091] Processing module 1541 is used to change the class loading mechanism through hooks, load the target plugin class in the host application based on the changed loading mechanism, and reflectively call the methods of the target plugin class to implement the target plugin.

[0092] In some embodiments, the apparatus 154 for dynamically updating the software development kit further includes an acquisition module 1542 for acquiring the software development kit released by the tool development end, wherein the software development kit includes a binary archive file and at least two plugins, the at least two plugins including a target plugin.

[0093] The processing module 1541 is also used to copy the binary archive file and at least two plugins to the application's project directory; and to integrate at least two plugins by calling the interface in the binary archive file through the application to obtain the host application.

[0094] In some embodiments, the processing module 1541 is further configured to load the executable file and dynamic library file of the virtual machine included in the updated target plugin into the project directory.

[0095] In some embodiments, the executable file of the virtual machine includes a dex file. The processing module 1541 is further configured to obtain the dexElements of the host application and the dexElements of the target plugin through reflection; merge the dexElements of the host application and the dexElements of the target plugin to obtain the target dexElements; and assign the target dexElements to the dexElements of the host application.

[0096] In some embodiments, the dynamic library file includes an .so file. The processing module 1541 is further configured to merge the nativeLibraryPathElements of the host application and the nativeLibraryPathElements of the target plugin to obtain the target nativeLibraryPathElements; and assign the target nativeLibraryPathElements to the nativeLibraryPathElements of the host application.

[0097] In some embodiments, the acquisition module 1542 is further configured to acquire at least two algorithm type flag bits sent from the cloud when the host application detects an algorithm switching event;

[0098] The processing module 1541 is also used to select the target algorithm flag corresponding to the algorithm switching event from at least two algorithm type flags through the intermediate layer, and load the target algorithm plugin from the cloud based on the target algorithm flag.

[0099] In some embodiments, the processing module 1541 is further configured to decompress the target algorithm plugin, copy the decompressed algorithm model file to the data native resource file directory corresponding to the host application, so as to replace the algorithm model file in the data native resource file directory, and install the decompressed algorithm model file.

[0100] In some embodiments, the processing module 1541 is further configured to obtain the version number of the same plugin locally and in the cloud when the host application starts; and determine that the same plugin has been updated when there is a target association relationship between the version number of the same plugin locally and the version number of the same plugin in the cloud, wherein the target plugin includes the same plugin.

[0101] It should be noted that the description of the apparatus in this application embodiment is similar to the description of the method embodiment described above, and has similar beneficial effects as the method embodiment; therefore, it will not be repeated. For technical details not disclosed in this apparatus embodiment, please refer to the description of the method embodiment of this application for understanding.

[0102] This application provides a storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to perform the method provided in this application, for example... Figure 2 The method shown.

[0103] In some embodiments, the storage medium may be a computer-readable storage medium, such as a ferromagnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic surface memory, optical disk, or a compact disk-read-only memory (CD-ROM); or it may be a device that includes one or any combination of the above-mentioned memories.

[0104] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0105] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file containing other programs or data, for example, in one or more scripts within a Hyper Text Markup Language (HTL) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files storing one or more modules, subroutines, or code sections). As an example, executable instructions may be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0106] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for dynamically updating a software development kit, characterized in that, include: When the host application starts, it is determined from the tool development end that the target plugins included in the software development kit corresponding to the host application have been updated. Copying the updated target plugin to the project directory of the host application includes: loading the executable files and dynamic library files of the virtual machine included in the updated target plugin into the project directory, wherein the executable files of the virtual machine include dex files; loading the executable files of the virtual machine included in the updated target plugin into the project directory includes: obtaining the executable file array of the host application and the executable file array of the target plugin through reflection; merging the executable file array of the host application and the executable file array of the target plugin to obtain a target executable file array; assigning the target executable file array to the executable file array of the host application; the dynamic library files include so files; loading the dynamic library files included in the updated target plugin into the project directory includes: merging the dynamic library path array of the host application and the dynamic library path array of the target plugin to obtain a target dynamic library path array; assigning the target dynamic library path array to the dynamic library path array of the host application. By changing the class loading mechanism through hooks, the target plugin's class is loaded in the host application based on the changed loading mechanism, and the methods of the target plugin's class are called by reflection to implement the target plugin.

2. The method according to claim 1, characterized in that, The method, which determines that the target plugins included in the software development kit corresponding to the host application have been updated before the host application starts, includes the following steps: Obtain the software development kit (SDK) released by the tool development end, wherein the SSD includes a binary archive file and at least two plugins, and the target plugin is one of the at least two plugins; Copy the binary archive file and the at least two plugins to the application's project directory; The host application is obtained by integrating the at least two plugins by calling the interface in the binary archive file through the application.

3. The method according to claim 1, characterized in that, The method further includes: When the host application detects an algorithm switching event, it obtains at least two algorithm type flag bits sent from the cloud; The intermediate layer selects the target algorithm flag corresponding to the algorithm switching event from the at least two algorithm type flags, and loads the target algorithm plugin from the cloud based on the target algorithm flag.

4. The method according to claim 3, characterized in that, After loading the target algorithm plugin from the cloud based on the target algorithm flag, the method further includes: Unzip the target algorithm plugin and copy the unzipped algorithm model file to the data native resource file directory corresponding to the host application to replace the algorithm model file in the data native resource file directory, and install the unzipped algorithm model file.

5. The method according to any one of claims 1 to 4, characterized in that, When the host application starts, determining that the target plugins included in the software development kit corresponding to the host application have been updated includes: When the host application starts, it obtains the version number of the same plugin both locally and in the cloud; When there is a target association between the version number of the same plugin on the local machine and the version number on the cloud machine, it is determined that the same plugin has been updated, wherein the target plugin includes the same plugin.

6. A device for dynamically updating a software development kit, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the method according to any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that, It stores executable instructions for causing a processor to execute, thereby implementing the method of any one of claims 1 to 5.

Images