Application development method, electronic device, and program product

Abstract

This disclosure provides an application development method, an electronic device, and a program product. The application development method includes: a host application obtaining a software development kit (SDK), wherein the SSD's manifest file does not declare any system permissions, and the functions within the SSD have been modularly split according to system permission types, forming multiple independent tool modules; configuring tool module configuration rules in the host application's configuration file based on the required system permissions declared in the host application's manifest file, the tool module configuration rules specifying which tool modules should be retained or removed; and, based on the tool module configuration rules, performing packaging of the host application and the SSD to obtain an application package.

Description

Technical Field

[0001] This disclosure relates to an application development method, electronic device, and application product. Background Technology

[0002] In application development, software development kits (SDKs) typically declare a large number of system permissions (such as camera, location, storage, contacts, etc.) in their manifest files to support full functionality. When an SSD is integrated into a host application, the host application automatically inherits all permission declarations from the SSD.

[0003] However, most host applications only use a portion of the software development kit's functionality, leading to a disconnect between permission claims and actual usage. This results in excessive permission requests, violating the principle of least privilege and making them vulnerable to rejection by app stores. Maintaining multiple versions of the software development kit (such as full and simplified versions) would result in high development, testing, and documentation costs, as well as chaotic version management. Summary of the Invention

[0004] This disclosure provides an application development method, an electronic device, and an application product.

[0005] According to one aspect of this disclosure, an application development method is provided, comprising: The host application obtains a software development kit (SDK). The SSD's manifest file does not declare any system permissions, and the functions in the SSD have been modularized according to system permission types, forming multiple independent tool modules. Based on the required system permissions declared by the host application in its own manifest file, configure tool module configuration rules in the host application's configuration file, and specify the tool modules that need to be retained or removed. Based on the configuration rules of the tool module, the host application and the software development kit are packaged to obtain the application package.

[0006] One technical solution involves acquiring a Software Development Kit (SDK) that doesn't declare any system permissions in its manifest file and is already divided into multiple independent tool modules based on system permission types. This fundamentally avoids the problem of discrepancies between system permission declarations and actual functionality caused by the host application passively inheriting all system permission declarations from the SDK. Next, based on the tool module configuration rules configured in the host application's configuration file, the tool modules to be retained or removed are specified. Then, the host application and SDK are packaged according to these rules to obtain an application package. This ensures that the application package only contains the tool modules actually used by the host application, achieving a precise match between the system permissions declared by the host application and the actual integrated tool modules. This avoids app stores rejecting applications due to mismatches between the required system permissions and the code. It also eliminates the tedious work of maintaining multiple versions of the SDK to meet different system permission requirements, enabling on-demand integration based on a single version of the SDK.

[0007] An application development method according to at least one embodiment of this disclosure, based on the tool module configuration rules, performs packaging of the host application and the software development kit to obtain an application package, including: Based on the tool module configuration rules, identify the target tool modules that need to be retained from each tool module of the software development kit; The tool modules in the software development kit other than the target tool module are trimmed; The host application and the trimmed software development kit are packaged together to obtain the corresponding application package.

[0008] According to the technical solution of this embodiment, the software development kit is trimmed according to the tool module configuration rules, which effectively avoids the situation of necessary tool modules being accidentally deleted or redundant tool modules remaining.

[0009] An application development method according to at least one embodiment of this disclosure, comprising identifying target tool modules to be retained from each tool module of the software development kit according to the tool module configuration rules, including: Based on the code execution logic of the host application, determine whether there is a calling relationship between the host application and each tool module in the software development kit; The tool modules in the software development kit that have a calling relationship with the host application and are not specified as needing to be removed, as well as the tool modules that are specified as needing to be retained in the tool module configuration rules, are identified as target tool modules.

[0010] According to the technical solution of this embodiment, through the collaborative operation of call relationship detection and tool module configuration rules, the tool modules required by the host application can be identified based on the actual call relationships, avoiding the possibility of runtime class missing or functional abnormalities caused by blind deletion. This achieves accurate and safe removal of redundant tool modules in the software development kit.

[0011] According to at least one embodiment of the application development method of this disclosure, determining whether there is a calling relationship between the host application and each tool module in the software development kit based on the code execution logic of the host application includes: Identify the method call instructions and data access instructions contained in the business code of the host application; Starting from the entry class of the host application, the execution path is traced along the method call instructions and the data access instructions; Based on the execution path tracing results, it is determined that there is a calling relationship between the tool modules that are called or accessed in the execution path and the host application.

[0012] According to the technical solution of this embodiment, by simultaneously tracking method call instructions and data access instructions, it is possible to capture indirect dependencies triggered not only through explicit method calls but also through field access (such as static constants and singleton instances), accurately restore the true dependency status of the host application on each tool module, and avoid the accidental deletion of necessary tool modules or the retention of redundant tool modules due to omissions in tool module rule configuration.

[0013] According to at least one embodiment of the application development method of this disclosure, after obtaining the application package, the application development method further includes: During the operation of the application package, in response to a tool call request, the tool module to be called corresponding to the tool call request is determined and it is detected whether the tool module to be called has been integrated into the application package; If the tool module to be invoked has been integrated into the application package, determine the system permission granting status of the tool module to be invoked, whereby the system permission granting status includes authorized or unauthorized. If the system permission grant status of the tool module to be invoked is authorized, the invocation of the tool module to be invoked shall be performed.

[0014] According to the technical solution of this embodiment, dynamic binding between function calls and the actual existence and permission validity of the code is achieved. This effectively accommodates dynamic code changes caused by the deletion of tool modules, avoids application crashes due to calling deleted tool modules, and significantly improves runtime fault tolerance and stability.

[0015] According to at least one embodiment of the application development method of this disclosure, after determining the system permission granting status of the tool module to be invoked, the application development method further includes: If the system permission grant status of the tool module to be called is unauthorized, permission is requested for the tool module to be called through the permission management interface; Based on the permission request result, if the permission request result is that authorization is allowed, the call to the tool module to be called is executed.

[0016] According to the technical solution of this implementation, the power to make permission decisions is returned to the user, strictly adhering to the principle of least privilege and privacy compliance requirements, effectively avoiding the risk of censorship caused by covert collection or forced acquisition of system permissions.

[0017] According to at least one embodiment of the application development method of this disclosure, detecting whether the tool module to be called has been integrated into the application package includes: Determine the class name of the class file of the tool module to be called, and attempt to load the class file by calling the reflection application programming interface based on the class name; If the class file loads successfully, it is determined that the tool module to be called has been integrated into the application package; if the class file fails to load, it is determined that the tool module to be called has not been integrated into the application package.

[0018] According to the technical solution of this embodiment, a runtime dynamic verification of the existence of tool modules is achieved through a reflection loading detection mechanism, perfectly compatible with the dynamic changes of tool modules caused by tool module trimming. This effectively avoids application interruptions caused by directly calling non-integrated tool modules.

[0019] According to at least one embodiment of the application development method of this disclosure, if the tool module to be called is not integrated into the application package or the permission application result is denied, the calling process of the tool module to be called is terminated.

[0020] According to the technical solution of this embodiment, the calling process of unintegrated or unauthorized tool modules is directly terminated to avoid abnormal program interruption.

[0021] According to another aspect of this disclosure, an application development apparatus is provided, comprising: The acquisition module is used by the host application to acquire the software development kit. The software development kit itself does not declare any system permissions in its manifest file, and the functions in the software development kit have been modularized according to system permission types to form multiple independent tool modules. The configuration module is used to configure tool module configuration rules in the configuration file of the host application according to the required system permissions declared by the host application in its own manifest file. The tool module configuration rules specify the tool modules that need to be retained or removed. The processing module is used to package the host application and the software development kit based on the configuration rules of the tool module and obtain the application package.

[0022] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform an application development method according to any embodiment of this disclosure.

[0023] According to another aspect of this disclosure, a readable storage medium is provided that stores executable instructions, which, when executed by a processor, are used to implement an application development method according to any embodiment of this disclosure.

[0024] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements an application development method according to any embodiment of this disclosure. Attached Figure Description

[0025] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0026] Figure 1 This is a flowchart illustrating an application development method according to one embodiment of the present disclosure.

[0027] Figure 2 This is a flowchart illustrating step S130 of an application development method according to an embodiment of the present disclosure.

[0028] Figure 3 This is a flowchart illustrating step S131 of an application development method according to an embodiment of the present disclosure.

[0029] Figure 4 This is a flowchart illustrating the process of determining call relationships in an application development method according to one embodiment of the present disclosure.

[0030] Figure 5 This is a flowchart illustrating the tool module invocation process in an application development method according to one embodiment of the present disclosure.

[0031] Figure 6This is a schematic diagram of the permission request process in an application development method according to one embodiment of the present disclosure.

[0032] Figure 7 This is a schematic diagram of the reflection loading detection process in an application development method according to one embodiment of the present disclosure.

[0033] Figure 8 This is a schematic diagram of the hierarchical architecture of an application package according to one embodiment of the present disclosure.

[0034] Figure 9 This is a schematic structural block diagram of an application development apparatus according to one embodiment of the present disclosure.

[0035] Figure 10 This is a schematic structural block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0036] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0037] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0038] Existing technologies make it difficult to accurately match the permission declarations of software development kits with the actual functional requirements of the host application, resulting in excessive permission requests, difficulties in app store review, and high maintenance costs for multiple versions of software development kits.

[0039] To address this issue, this disclosure proposes the following technical solution. This solution obtains a Software Development Kit (SDK) whose manifest file does not contain any system permission declarations and is divided into multiple independent tool modules according to system permission types. This fundamentally avoids the problem of discrepancies between system permission declarations and actual functionality caused by the host application passively inheriting all system permission declarations of the SDK. Next, based on the tool module configuration rules configured in the host application's configuration file, the tool modules to be retained or removed are specified. Then, the host application and the SDK are packaged according to the tool module configuration rules to obtain the application package.

[0040] This ensures that the application package contains only the tool modules actually used by the host application, achieving a precise match between the system permissions declared by the host application and the tool modules actually integrated. This avoids the problem of app stores rejecting applications due to mismatches between the system permissions required by the application package and the code. It also eliminates the tedious work of maintaining multiple versions of the software development kit to meet different system permission requirements, enabling on-demand integration based on a single version of the software development kit.

[0041] Figure 1 This is a flowchart illustrating an application development method according to one embodiment of the present disclosure. The application development method can be applied to a terminal device or server, the terminal device including one or more electronic devices such as smartphones, tablets, laptops, and desktop computers.

[0042] like Figure 1 As shown, the application development method preferably includes steps S110 to S130.

[0043] In step S110, the host application obtains a software development kit (SDK). The SSD's manifest file does not declare any system permissions, and the functions in the SSD have been modularly split according to system permission types, forming multiple independent tool modules.

[0044] In this context, the host application is an application that can integrate and call third-party software development kits (such as Android applications), and it serves as the executor of permission declarations and runtime control. Preferably, the host application declares the system permissions (such as camera permissions, location permissions, and contact permissions) required for its own runtime in its manifest file. This completely transfers the responsibility for system permission declarations from the software development kit to the host application, enabling the host application to autonomously control which permissions it needs.

[0045] Software development kits are code libraries developed by third parties to provide callable functions (such as camera taking pictures, location positioning, file storage, contact reading, etc.).

[0046] Preferably, during software development kit (SDK) integration, the host application obtains the SSD to be integrated (e.g., from local cache or third-party storage). The SSD's manifest file (e.g., AndroidManifest.xml) does not contain system permission declarations; that is, no system permission declarations are made. Therefore, after integrating the SSD, the host application will not passively inherit any system permission declarations, avoiding excessive permission requests.

[0047] Furthermore, the functionality of this software development kit has been modularized according to system permission types, forming multiple independent tool modules (such as camera module, positioning module, storage module, address book module, etc.). The tool modules maintain a low coupling state, and each tool module corresponds to different system permissions and business logic implementations.

[0048] In step S120, based on the required system permissions declared by the host application in its own manifest file, tool module configuration rules are configured in the host application's configuration file, and the tool module configuration rules specify the tool modules that need to be retained or removed.

[0049] Preferably, based on the tool modules actually needed by the host application in the business scenario, the required system permissions are declared in the host application's manifest file. Then, based on the system permissions declared in the host application's manifest file, tool module configuration rules are explicitly configured in the host application's configuration file, converting the abstract system permission usage intent into parsable configuration information, thereby clearly informing the tool modules that need to be retained or removed in the software development kit.

[0050] Understandably, since the tool module configuration rules are generated directly based on the actual system permission requirements of the host application, it ensures that there are precise filtering boundaries when performing tool module trimming on the software development kit, effectively avoiding the accidental deletion of necessary tool modules or the retention of redundant tool modules (such as tool modules that are specified to be removed) due to fuzzy rules.

[0051] In step S130, based on the tool module configuration rules, the host application and the software development kit are packaged to obtain the application package.

[0052] Preferably, based on the tool module configuration rules configured in the host application's configuration file, redundant tool modules (such as tool modules other than those specified to be retained or those specified to be removed) in the software development kit are trimmed to obtain a trimmed software development kit.

[0053] Next, the host application and the trimmed software development kit are packaged (e.g., compiled using a compiler) to obtain the corresponding application package (e.g., APK (Android application package) file).

[0054] Therefore, based on the application development method provided in this disclosure, it is ensured that the application package only contains the tool modules actually used by the host application. This achieves a precise match between the system permissions declared by the host application and the tool modules actually integrated, avoiding the problem of app stores refusing to list the application due to mismatches between the system permissions required by the application package and the code. It also eliminates the tedious work of maintaining multiple versions of the software development kit to meet different system permission requirements, enabling on-demand integration based on a single version of the software development kit.

[0055] In some embodiments of this disclosure, step S130, based on the tool module configuration rules, involves packaging the host application and the software development kit to obtain the application package. Preferably, this includes steps S131 to S133. Please refer to [reference needed]. Figure 2 .

[0056] In step S131, the target tool modules that need to be retained are identified from each tool module of the software development kit according to the tool module configuration rules.

[0057] In step S132, the tool modules in the software development kit other than the target tool module are trimmed.

[0058] In step S133, the host application and the trimmed software development kit are packaged together to obtain the corresponding application package.

[0059] In this implementation, the retention instructions (indicating the tool modules that need to be retained) or removal instructions (indicating the tool modules that need to be removed) in the tool module configuration rules are parsed to clarify the processing intention for each tool module.

[0060] Next, based on the parsing results of the tool module configuration rules, the target tool modules that need to be retained are identified from the tool modules of the software development kit. These target tool modules are either specified tool modules that need to be retained or tool modules that are not specified and need to be removed.

[0061] The software development kit (SDK) is trimmed of all tool modules except the target tool modules, retaining only the target tool modules required by the host application. The host application and the trimmed SSD are then packaged together to generate a standalone, installable application package.

[0062] Therefore, by tailoring the software development kit according to the tool module configuration rules, the accidental deletion of necessary tool modules or the retention of redundant tool modules can be effectively avoided.

[0063] In some embodiments of this disclosure, step S131, identifying the target tool modules to be retained from each tool module of the software development kit according to the tool module configuration rules, preferably includes steps S1311 to S1312. Please refer to [link / reference needed]. Figure 3 .

[0064] In step S1311, based on the code execution logic of the host application, it is determined whether there is a calling relationship between the host application and each tool module in the software development kit.

[0065] In step S1312, the tool modules in the software development kit that have a calling relationship with the host application and are not specified as needing to be removed, as well as the tool modules specified as needing to be retained in the tool module configuration rules, are identified as target tool modules.

[0066] The code execution logic is the program execution flow of the host application's business code, including the program entry point, method call chain, conditional branches, loop structures, etc.

[0067] In this implementation, a full-link scan is performed based on the code execution logic of the host application to identify all tool modules that are directly or indirectly called by the business code of the host application (i.e., tool modules that have a calling relationship with the host application).

[0068] Next, the tool modules that have a calling relationship with the host application are compared with the tool modules that are specified to be retained or removed in the tool module configuration rules. Based on the comparison results, the tool modules in the software development kit that have a calling relationship with the host application and are not specified to be removed, as well as the tool modules that are specified to be retained, are identified as the target tool modules.

[0069] Therefore, through the collaborative computation of call relationship detection and tool module configuration rules, the tool modules required by the host application can be identified based on the actual call relationships, avoiding runtime class omissions or functional abnormalities that may be caused by blind deletion. This achieves precise and safe removal of redundant tool modules in the software development kit.

[0070] In some embodiments of this disclosure, determining whether there is a calling relationship between the host application and each tool module in the software development kit (SDK) is performed based on the code execution logic of the host application. Preferably, this includes steps S410 to S430. Please refer to [link / reference needed]. Figure 4 .

[0071] In step S410, the method call instructions and data access instructions contained in the business code of the host application are determined.

[0072] In step S420, starting from the entry class of the host application, the execution path is traced along the method call instructions and the data access instructions.

[0073] In step S430, based on the execution path tracing results, it is determined that there is a calling relationship between the tool module that is called or accessed in the execution path and the host application.

[0074] In this implementation, when determining the calling relationships between the host application and the tool modules in the software development kit, all method call instructions and data access instructions contained in the business code of the host application are first extracted. Then, starting from the entry class of the host application (i.e., the program entry point), the execution path is traced along all method call instructions and data access instructions to determine all methods that may be called and fields that may be accessed.

[0075] Based on the execution path tracing results, if a class, method, or field of a certain tool module is called or accessed, it can be determined that there is a calling relationship (including direct or indirect calls) between the tool module and the host application.

[0076] Therefore, by simultaneously tracking method call instructions and data access instructions, it is possible to capture indirect dependencies triggered not only through explicit method calls but also through field accesses (such as static constants and singleton instances), accurately reconstructing the true dependency status of the host application on each tool module, and avoiding the accidental deletion of necessary tool modules or the retention of redundant tool modules due to omissions in tool module rule configuration.

[0077] In some embodiments of this disclosure, after obtaining the application package, the application development method preferably further includes steps S510 to S530, please refer to... Figure 5 .

[0078] In step S510, during the operation of the application package, in response to a tool call request, the tool module to be called corresponding to the tool call request is determined and it is detected whether the tool module to be called has been integrated into the application package.

[0079] In step S520, if the tool module to be invoked has been integrated into the application package, the system permission granting status of the tool module to be invoked is determined, and the system permission granting status includes authorized or unauthorized.

[0080] In step S530, if the system permission granting status of the tool module to be invoked is authorized, the invocation of the tool module to be invoked is performed.

[0081] In this implementation, during the execution of the application package, when its business code triggers a certain function, a tool invocation request is generated and passed to the software development kit (SDK). The SSD first parses the tool invocation request, extracts the identification information (such as class identifier) ​​of the corresponding tool module to be invoked, and loads the tool module to be invoked based on the identification information. If loading is successful and a class instance is obtained, it is determined that the tool module to be invoked has been integrated into the application package. Preferably, if loading fails, it is determined that the tool module to be invoked has not been integrated, and the invocation process for the tool module is directly terminated to avoid abnormal program interruption.

[0082] If it is determined that the application package has already integrated the tool module to be called, the system permission granting status corresponding to the tool module to be called is further checked (e.g., by querying the system permission manager). The system permission granting status is the user authorization result for a certain system permission, including authorized (i.e., the user has agreed to grant authorization) and unauthorized (i.e., the user has refused authorization or has not yet applied for authorization). If the system permission granting status of the tool module to be called is authorized, the call to the module to be called is executed.

[0083] This achieves dynamic binding between function calls and the actual existence and permission validity of the code. It effectively accommodates dynamic code changes caused by the deletion of utility modules, avoids application crashes due to calling deleted utility modules, and significantly improves runtime fault tolerance and stability.

[0084] In some embodiments of this disclosure, after determining the system permission granting status of the tool module to be invoked, the application development method preferably further includes steps S610 to S620, please refer to... Figure 6 .

[0085] In step S610, if the system permission grant status of the tool module to be called is unauthorized, permission is requested for the tool module to be called through the permission management interface.

[0086] In step S620, based on the permission request result, if the permission request result is that authorization is allowed, the call to the tool module to be called is executed.

[0087] In this implementation, when it is determined that the system permissions required by the tool module to be invoked have not yet been granted by the user (i.e., the system permission granting status is unauthorized), a permission request is proactively initiated to the user through a unified permission management interface, and a system permission authorization pop-up is displayed on the terminal interface. Preferably, this permission management interface is a standardized permission request component, used to shield the differences in the underlying permission request APIs (Application Programming Interfaces) of different operating system versions, and to uniformly handle permission request initiation, result callback listening, and authorization status management.

[0088] Based on the detected user interaction with the permission authorization pop-up, the corresponding permission request result is determined. If the permission request result is "grant" (e.g., the user clicks the "grant" button in the permission authorization pop-up), the call to the tool module to be invoked is executed. If the permission request result is "deny" (e.g., the user clicks the "deny" button in the permission authorization pop-up), the invocation process of the tool module to be invoked is terminated to avoid abnormal program interruption.

[0089] By returning the power to make permission decisions to the user and strictly adhering to the principle of least privilege and privacy compliance requirements, the risk of censorship caused by covert collection or forced acquisition of system permissions is effectively avoided.

[0090] In some embodiments of this disclosure, detecting whether the tool module to be invoked has been integrated into the application package preferably includes steps S710 to S720. Please refer to [link / reference needed]. Figure 7 .

[0091] In step S710, the class name of the class file of the tool module to be called is determined, and the reflection application programming interface is called according to the class name to attempt to load the class file.

[0092] In step S720, if the class file is loaded successfully, it is determined that the tool module to be called has been integrated into the application package; if the class file fails to load, it is determined that the tool module to be called has not been integrated into the application package.

[0093] In this implementation, when detecting whether the application package has integrated the tool module to be called, the class name of the class file of the tool module to be called is determined (e.g., extracted from the tool call request), the reflection application programming interface provided by the runtime environment is called, the class name is passed as a parameter to the class loading instruction, and an attempt is made to dynamically find and load the corresponding class file in memory.

[0094] During the execution of the class loading instruction, the return status is monitored in real time. If the reflection application programming interface successfully returns a class object instance, it is determined that the class file has been loaded successfully, thus confirming that the utility module to be called has been integrated into the current application package, and the subsequent permission granting status detection process continues.

[0095] If the reflection application programming interface catches a Class Not Found exception or Null Pointer exception during execution, it determines that the class file loading failed, and thus determines that the utility module to be called has not been integrated into the application package.

[0096] Therefore, by using a reflection-based loading detection mechanism, runtime dynamic verification of the existence of tool modules is achieved, perfectly accommodating dynamic changes in tool modules caused by module trimming. This effectively avoids application interruptions caused by directly calling non-integrated tool modules.

[0097] Figure 8 This is a schematic diagram of the hierarchical architecture of an 8-application package according to one embodiment of the present disclosure.

[0098] like Figure 8 As shown, the target application package preferably includes a host application, a permission declaration layer, a software development kit, and a functional requirements configuration file (i.e., the configuration file of the aforementioned host application).

[0099] The host application is an application that can be integrated with and use the software development kit (SDK). It declares the required system permissions in its permission declaration layer (such as the AndroidManifest.xml file) according to its actual functional needs. It also explicitly specifies which tool modules need to be retained or removed through a feature requirements configuration file.

[0100] The Software Development Kit (SDK) provides common functionalities (such as camera, location, and map). These functionalities are modularized according to system permission types, forming multiple independent tool modules. The SSD transfers the responsibility for permission declaration to the host application (i.e., the SSD's manifest file does not contain any system permission declarations), and uses an internal scheduling mechanism to dynamically load tool modules and manage permissions.

[0101] Preferably, the software development kit (SDK) comprises three core components: a business module, a tool scheduler, and a tool module layer. The business module is responsible for triggering tool call requests to specific business scenarios and sending these requests to the tool scheduler, thus decoupling business logic from tool calls. The tool scheduler receives tool call requests from business modules and uses a reflection loading detection mechanism (i.e., attempting to load the module via reflection application programming interfaces) to check whether the requested tool module has been integrated, examines its system permission granting status, and initiates a permission request if the system permission is not granted. Finally, it coordinates the invocation of the corresponding tool module to execute the function. The tool module layer includes multiple tool modules independently split according to system permission types (such as a camera module, a positioning module, etc.), physically isolating and loosely encapsulating tool modules corresponding to different system permissions.

[0102] Figure 9 This is a schematic structural block diagram of an application development apparatus according to one embodiment of the present disclosure.

[0103] like Figure 9As shown, the application development apparatus preferably includes an acquisition module 910, a configuration module 920, and a processing module 930.

[0104] The acquisition module 910 is used by the host application to acquire a software development kit (SDK). The SSD itself does not declare any system permissions in its manifest file, and the functions in the SSD have been modularly split according to system permission types, forming multiple independent tool modules. The configuration module 920 is used to configure tool module configuration rules in the host application's configuration file according to the required system permissions declared by the host application in its manifest file. The tool module configuration rules specify the tool modules that need to be retained or removed. The processing module 930 is used to package the host application and the SSD based on the tool module configuration rules and obtain an application package.

[0105] In some embodiments of this disclosure, after obtaining the target application package, the processing module 930 is further configured to: during the operation of the application package, in response to a tool invocation request, determine the tool module to be invoked corresponding to the tool invocation request and detect whether the tool module to be invoked has been integrated into the application package; if the tool module to be invoked has been integrated into the application package, determine the system permission granting status of the tool module to be invoked, the system permission granting status including authorized or unauthorized; and if the system permission granting status of the tool module to be invoked is authorized, execute the invocation of the tool module to be invoked.

[0106] In some embodiments of this disclosure, after determining the system permission granting status of the tool module to be invoked, the processing module 930 is further configured to: request permission for the tool module to be invoked through the permission management interface when the system permission granting status of the tool module to be invoked is unauthorized; and, based on the permission request result, execute the invocation of the tool module to be invoked when the permission request result is authorized.

[0107] Figure 10 This is a schematic structural block diagram of an electronic device according to one embodiment of the present disclosure.

[0108] like Figure 10As shown, the hardware structure of electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. Bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400 such as peripherals, voltage regulators, power management circuits, external antennas, etc. Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one connection line is used in this figure, but this does not indicate that there is only one bus or one type of bus.

[0109] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means that can contain a program for storage, communication, propagation, or transmission for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0110] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0111] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0112] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0113] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0114] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0115] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0116] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0117] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

[0118] It is understood that before using the technical solutions disclosed in the embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained. For example, in response to receiving a user's active request, a prompt message can be sent to the user to clearly inform the user that the requested operation will require the acquisition and use of the user's personal information. This allows the user to choose whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media that perform the operations of the technical solutions of this disclosure, based on the prompt message. As an optional but non-limiting implementation, the way to send a prompt message to the user in response to receiving a user's active request can be, for example, a pop-up window, in which the prompt message can be presented in text form. Furthermore, the pop-up window can also include a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0119] It is understood that the above notification and user authorization acquisition process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure. The data involved in the technical solution of this disclosure (including but not limited to the data itself, the acquisition or use of data) shall comply with the requirements of relevant laws, regulations and related provisions.

Claims

1. An application development method, characterized in that, include: The host application obtains a software development kit (SDK). The SSD's manifest file does not declare any system permissions, and the functions in the SSD have been modularized according to system permission types, forming multiple independent tool modules. Based on the required system permissions declared by the host application in its own manifest file, configure tool module configuration rules in the host application's configuration file, and specify the tool modules that need to be retained or removed. as well as Based on the configuration rules of the tool module, the host application and the software development kit are packaged to obtain the application package.

2. The application development method as described in claim 1, characterized in that, Based on the tool module configuration rules, the process of packaging the host application and the software development kit to obtain the application package includes: Based on the tool module configuration rules, identify the target tool modules that need to be retained from each tool module of the software development kit; The software development kit (SDK) is trimmed of all tool modules except the target tool module; and The host application and the trimmed software development kit are packaged together to obtain the corresponding application package.

3. The application development method as described in claim 2, characterized in that, Based on the tool module configuration rules, the target tool modules that need to be retained are identified from the various tool modules of the software development kit, including: Based on the code execution logic of the host application, determine whether there is a calling relationship between the host application and the tool modules in the software development kit; and The tool modules in the software development kit that have a calling relationship with the host application and are not specified as needing to be removed, as well as the tool modules that are specified as needing to be retained in the tool module configuration rules, are identified as target tool modules.

4. The application development method as described in claim 3, characterized in that, Based on the code execution logic of the host application, determine whether there is a calling relationship between the host application and the various tool modules in the software development kit, including: Identify the method call instructions and data access instructions contained in the business code of the host application; Starting from the entry class of the host application, the execution path is traced along the method call instructions and the data access instructions; and Based on the execution path tracing results, it is determined that there is a calling relationship between the tool modules that are called or accessed in the execution path and the host application.

5. The application development method as described in claim 1, characterized in that, After obtaining the application package, the application development method further includes: During the operation of the application package, in response to a tool call request, the tool module to be called corresponding to the tool call request is determined and it is detected whether the tool module to be called has been integrated into the application package; If the tool module to be invoked has been integrated into the application package, determine the system permission granting status of the tool module to be invoked, wherein the system permission granting status includes authorized or unauthorized; and If the system permission grant status of the tool module to be invoked is authorized, the invocation of the tool module to be invoked shall be performed.

6. The application development method as described in claim 5, characterized in that, After determining the system permission granting status of the tool module to be invoked, the application development method further includes: If the system permission grant status of the tool module to be invoked is unauthorized, permission requests are made to the tool module to be invoked through the permission management interface; and Based on the permission request result, if the permission request result is that authorization is allowed, the call to the tool module to be called is executed.

7. The application development method as described in claim 5, characterized in that, Detecting whether the tool module to be invoked has been integrated into the application package includes: Determine the class name of the class file of the tool module to be invoked, and attempt to load the class file by invoking the reflection application programming interface based on the class name; and If the class file loads successfully, it is determined that the tool module to be called has been integrated into the application package; if the class file fails to load, it is determined that the tool module to be called has not been integrated into the application package.

8. The application development method as described in claim 5 or 6, characterized in that, If the tool module to be invoked is not integrated into the application package or the permission request result is denied, the invocation process for the tool module to be invoked shall be terminated.

9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the application development method according to any one of claims 1 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the application development method according to any one of claims 1 to 8.

Images