CN110941443B - Method and device for modifying file name in SDK (software development kit) and electronic equipment - Google Patents

Abstract

The embodiment of the specification discloses a method and a device for modifying a file name in an SDK and electronic equipment. The scheme comprises the following steps: acquiring first file name information; the first file name information is used for representing the file name of a file in a first SDK which needs to be sent to a program access end; acquiring second file name information; the second file name information is used for representing the file name of a file in a second SDK stored by the program access end; determining a conflicting file in the first SDK based on the first file name information and the second file name information; the file name of the conflict file is the same as the file name of the file in the second SDK; and modifying the file name of the conflict file.

Description

Method, device and electronic equipment for modifying file name in SDK

technical field

The present application relates to the field of computer technology, in particular to a method, device and electronic equipment for modifying file names in SDK.

Background technique

In the prior art, the program access party sometimes accesses a software development kit (Software Development Kit, SDK) of the service output party multiple times. In addition, for better service, the SDK will be continuously optimized, so the same There will be several different versions of the SDK. Therefore, when the service exporter is exporting each SDK, it needs to check whether the service receiver has already connected to the SDK, and determine whether the connected version is the same as the SDK to be connected. If the versions are different, you need to solve the problem of compatibility between different versions.

Need to provide a faster solution for incompatible versions of the same SDK.

Contents of the invention

In view of this, the embodiments of the present application provide a method, device, and electronic device for modifying file names in the SDK, so as to improve the processing efficiency of program access.

In order to solve the above-mentioned technical problems, the embodiments of this specification are implemented as follows:

A method for modifying the file name in the SDK provided by the embodiment of this specification includes:

Obtain first file name information; the first file name information is used to indicate the file name of the file in the first SDK that needs to be sent to the program access terminal;

Obtaining second file name information; the second file name information is used to indicate the file name of the file in the second SDK stored by the program access terminal;

Determine the conflicting file in the first SDK based on the first file name information and the second file name information; the file name of the conflicting file is the same as the file name of the file in the second SDK;

Modify the filename of the conflicting file.

The device for modifying the file name in the SDK provided by the embodiment of this specification includes:

The first obtaining module is used to obtain the first file name information; the first file name information is used to represent the file name of the file in the first SDK that needs to be sent to the program access terminal;

The second obtaining module is used to obtain the second file name information; the second file name information is used to indicate the file name of the file in the second SDK stored by the program access terminal;

A conflicting file determination module, configured to determine a conflicting file in the first SDK based on the first file name information and the second file name information; the file name of the conflicting file is the same as that in the second SDK The files have the same filename;

The file name modification module is used to modify the file name of the conflicting file.

An electronic device provided in an embodiment of this specification includes:

at least one processor; and,

a memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions being executable by the at least one processor to enable the at least one processor to:

Obtain first file name information; the first file name information is used to indicate the file name of the file in the first SDK that needs to be sent to the program access terminal;

Obtaining second file name information; the second file name information is used to indicate the file name of the file in the second SDK stored by the program access terminal;

Determine the conflicting file in the first SDK based on the first file name information and the second file name information; the file name of the conflicting file is the same as the file name of the file in the second SDK;

Modify the filename of the conflicting file.

The embodiment of this specification provides a computer-readable medium, on which computer-readable instructions are stored, and the computer-readable instructions can be executed by a processor to implement the above-mentioned method for modifying a file name in the SDK.

The above-mentioned at least one technical solution adopted in the embodiment of this specification can achieve the following beneficial effects: before sending the first SDK to the program access terminal, first obtain the second SDK stored in the program access terminal, the first SDK frame and the second SDK The package names are the same, and then compare whether the file names of the files in the first SDK and the second SDK are the same. If they are the same, modify the file name of the first SDK, so as to avoid the conflict between the first SDK and the second SDK when compiling in the program access terminal. The above method can effectively solve the problem that there are two different versions of SDK in the same machine, and the problem of version conflict and incompatibility occurs. Processing efficiency.

Description of drawings

The drawings described here are used to provide a further understanding of the application and constitute a part of the application. The schematic embodiments and descriptions of the application are used to explain the application and do not constitute an improper limitation to the application. In the attached picture:

Fig. 1 is a schematic flow chart of a method for modifying a file name in SDK provided by an embodiment of this specification;

FIG. 2 is a schematic structural diagram of a device for modifying file names in the SDK corresponding to FIG. 1 provided by the embodiment of this specification;

FIG. 3 is a schematic structural diagram of an electronic device corresponding to FIG. 1 provided by the embodiment of this specification.

Detailed ways

In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in conjunction with specific embodiments of the present application and corresponding drawings. Apparently, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the scope of protection of this application.

When an application APP (program accessor) needs to access a certain service (such as payment code service) of another application (service output party), for example, a shopping APP needs to access payment codes of payment platforms such as WeChat and Alipay When serving, it is necessary to call the payment code service SDK provided by the service exporter (WeChat, Alipay). The developer of the receiving party can realize the SDK after decompressing the payment code SDK and learning the logic of the SDK function. This service occurs in the development stage of the application. Only when the program access party successfully accesses the service, the corresponding application APP of the program access party can be launched and used by registered users of the APP.

However, in some cases, the development platform of the service exporter has more functions. In order to facilitate the programming of developers, some frequently used programs that implement basic functions will be packaged to generate a basic SDK. When developing a certain service, developers only need to call these basic SDKs to realize a certain function without reprogramming. Therefore, in addition to the main program, some services also include multiple basic SDKs called. With development, in order to cope with changes in requirements, the basic SDK process is often upgraded. Therefore, in different time periods, the version of the basic SDK output by the service exporter is different. Therefore, before the service exporter exports a certain service to the program accesser, it is assumed that the service includes the login SDK, and the program accesser has already accessed the login SDK, and the login SDK that the program accessor has accessed is a lower version, and the login SDK that the service exporter will export to the program accesser is a higher version. If a higher version of the login SDK is directly output to the program access party, then when compiling, different versions will be incompatible.

In order to solve the problem of incompatibility of different versions, the developer of the program access party and the service exporter can communicate offline. After upgrading the lower version of the service exporter to a higher version, the service exporter can then export the service. In this way, it depends on offline operation, the process is cumbersome, and the access efficiency is low.

In order to solve the above problem of incompatibility of different versions of the SDK and improve the access efficiency, the embodiment of this specification first obtains the second SDK stored in the program access terminal, the first SDK and the first SDK before sending the first SDK to the program access terminal. The package names of the second SDK are the same, and then compare whether the file names of the files in the first SDK and the second SDK are the same. If they are the same, modify the file name in the first SDK file, so as to avoid the conflict between the first SDK and the second SDK when compiling in the program access terminal. The above method can effectively solve the problem that there are two different versions of SDK in the same machine, and the problem of version conflict and incompatibility occurs. Compared with the solution of artificially upgrading the lower version of the software in the prior art, the processing efficiency is improved.

The technical solutions provided by various embodiments of the present application will be described in detail below in conjunction with the accompanying drawings.

FIG. 1 is a schematic flowchart of a method for modifying a file name in an SDK provided by an embodiment of this specification. From a program point of view, the subject of execution of the process can be a program or an application client installed on an application server. The execution subject of this solution is the device of the service exporter, which can be a development server or any development client.

As shown in Figure 1, the process may include the following steps:

Step 102: Obtain first file name information; the first file name information is used to indicate the file name of the file in the first SDK that needs to be sent to the program access terminal.

SDK is generally a collection of development tools used by some software engineers to create application software for specific software packages, software frameworks, hardware platforms, operating systems, etc. Therefore, an SDK with special functions will include many files, and these files may be modules in the development software called, such as class libraries in Java.

Java officially provides developers with many powerful classes, which are placed in various packages and released together with the JDK, called Java class libraries or Java APIs. API (Application Programming Interface, Application Programming Interface) is a general concept.

A class library in Java is a module that a developer has developed and can be called by other developers. Literally understood, a class library is like a warehouse, and there are many developed classes in the warehouse. Therefore, these classes are often used in a certain service.

The first file name information is used to indicate the file name of the file in the first SDK that needs to be sent to the program access terminal. These file name information can be obtained by calling the first SDK, or only the files in the first SDK can be called The filename of the associated file. Assuming that the first file name information exists in a certain file of the first SDK, it is only necessary to obtain the content in the file.

In this solution, the first SDK can be sent to the program access terminal alone, or it can be sent to the program access terminal together with other SDKs, or the first SDK can be packaged with other SDKs and then sent to the program access terminal. end.

It should be noted that the "first" in the "first file name information" and the "first" in the "first SDK" are only used for distinction and have no actual meaning.

Step 104: Obtain second file name information; the second file name information is used to indicate the file name of the file stored in the second SDK at the program access terminal.

After determining the first SDK that needs to be sent to the program access terminal, it is necessary to determine whether the program access terminal has access to the second SDK with the same package name as the first SDK. If the program access terminal has already connected to the second SDK, it needs to determine whether the first SDK and the second SDK conflict. The package names of the first SDK and the second SDK are the same, which means that the functions implemented by the first SDK and the second SDK are the same or similar.

The way to obtain the second file name information can be to obtain the second SDK accessed from the program access terminal, and then obtain the second file information from the second SDK; it can also be output from the service only according to the package name and version number of the second SDK The party obtains the second file name information from the second SDK stored by the service output party, so that the operation can be simplified without calling the second SDK at the program access end.

Step 106: Determine the conflicting file in the first SDK based on the first file name information and the second file name information; the file name of the conflicting file and the file name of the file in the second SDK same.

Since it is necessary to modify the file name in the first SDK to avoid having the same file name as that in the second SDK, it is necessary to determine the conflicting file in the first SDK. The conflict file can be understood as if the file name of a file in the first SDK also exists in the second SDK, then the file can be called a conflict file.

A specific screening method may be to compare the file names corresponding to the first file name information and the file names corresponding to the second file name information one by one, and filter out the file names of the files with the same file name. For example, taking the file name in the first file name information as the object of comparison, for file name A, if the file name A exists in the second file name information, then the file in the first SDK corresponding to file name A is A conflict file; if the file name A does not exist in the second file name information, then the file in the first SDK corresponding to the file name A is not a conflict file.

Step 108: Modify the file name of the conflicting file.

After determining the conflicting file, it is necessary to modify the file name of the conflicting file, so that the modified file name is not the same as the file name of the second SDK file, so as to avoid conflicts.

In order to distinguish it from the file in the second SDK, just modify the file name in the first SDK. For the modification of the file name, some characters or character strings can be added to make a distinction. These characters and strings can be generated randomly or according to certain rules. It can be meaningless, or it can represent special meaning, and some special information can be obtained according to these characters and strings in the file name.

The method in Figure 1, before sending the first SDK to the program access terminal, first obtain the second SDK stored in the program access terminal, the package names of the first SDK box and the second SDK are the same, and then compare the first SDK and Whether the file name of the file in the second SDK is the same. If they are the same, modify the file name of the first SDK, so as to avoid the conflict between the first SDK and the second SDK when compiling in the program access terminal. The above method can effectively solve the problem that there are two different versions of SDK in the same machine, and the problem of version conflict and incompatibility occurs. Processing efficiency.

Based on the method in FIG. 1 , the embodiment of this specification also provides some specific implementations of the method, which will be described below.

In some specific scenarios, before step 102: before obtaining the first file name information, it also includes:

Obtain the first version number information of the first SDK;

Determine the second SDK according to the package name of the first SDK, the package name of the second SDK is the same as the package name of the first SDK;

Obtain the second version number information of the second SDK;

Based on the first version number information and the second version number information, judge whether the versions of the first SDK and the second SDK are the same, and obtain a judgment result;

The acquisition of the first file name information specifically includes:

When the judgment result indicates that the versions of the first SDK and the second SDK are different, the first file name information is acquired.

In this embodiment, the implementation of a certain service often needs to call multiple basic SDKs. Since the basic SDKs are always being updated, the output time of each service is different, resulting in different versions of the selected basic SDKs. Therefore, it is possible that the two conflicting SDKs are two different versions of one SDK.

Therefore, after determining the first SDK to be exported, it is first necessary to determine whether the program access terminal has accessed the SDK with the same package name as the first SDK. The determination method can be provided by the program access terminal actively, or there will be a table at the service output terminal, recording the name and version number of the SDK sent to the program access terminal each time. If the program access terminal does not store an SDK with the same package name as the first SDK, after the first SDK is sent to the program access terminal, there will be no conflict during compilation. If it is determined that the program access terminal has stored the second SDK with the same package name as the first SDK, it needs to determine whether the version numbers of the first SDK and the second SDK are the same. Obtaining the second version number information of the second SDK may be provided by the program access terminal, or may be obtained from a data table stored in the service output terminal.

If the version number of the first SDK is the same as the version number of the second SDK, it means that the second SDK stored in the program access terminal is exactly the same as the first SDK, and there will be no conflict during compilation. If the version number of the first SDK is different from that of the second SDK, it is necessary to modify the files in the first SDK that will conflict with the second SDK. In order to simplify the operation, it is only necessary to modify the file name of the file in the second SDK. Therefore, it is only necessary to obtain the file name information of the first SDK and the second SDK for comparison to find out the conflicting file.

In order to distinguish it from the file in the second SDK, just modify the file name in the first SDK. For the modification of the file name, some characters or character strings can be added to make a distinction. Specifically, in order to improve modification efficiency, the modification of the file name of the conflicting file specifically includes:

Adding a specific character string to the original file name of the conflicting file, wherein, when there are multiple conflicting files, the specific character string added to the file names of the multiple conflicting files is the same.

There are many packages in the Java class library:

Starting with java.* is the core package of Java, and all programs will use the classes in these packages;

The extension package starts with javax.*, and x means extension, that is, extension. Although javax.* is an optimization and extension of java.*, because javax.* is used more and more, many programs depend on javax.*, so javax.* is also a part of the core, and it is also released with JDK .

Packages starting with org.* are packages released by various institutions or organizations. Because these organizations are very influential and their code quality is high, some commonly used classes developed by them are also released together with the JDK.

Assume that the conflicting file name is okio.A, where okio is the toolkit name (cannot be modified), and A is the class name. To modify the file name of the conflicting file is to set a class mapping relationship to map okio.A to the modified file name, such as okio.custom.A, where custom is an added string.

Assuming that there is another conflicting file named java.util.Date, where java.util is the toolkit name and Date is the class name, then the modified file name is java.util.custom.Date. Therefore, it is possible to add all conflicting files to a specific character string, which improves the modification efficiency.

In order to call the file accurately, after the modification of the file name of the conflicting file, it also includes:

According to the modified file name of the conflict file, the program statement that refers to the conflict file is modified.

In a specific application, modifying the file name means modifying the corresponding relationship between the file name and the file. Therefore, when the file is called, the corresponding program statement in the code that calls the file needs to be modified. The specific operation is to traverse all class (code) files, replace the class name and import reference. import can only import the classes contained in the package, not the package.

For example, the original quote statement is: import java.util.Date; //import Date under the java.util package;

The modified application statement is: import java.util.custom.Date; //Import custom.Date under the java.util package.

In some specific scenarios, a service often requires multiple basic SDKs to be completed together. Therefore, conflicts between multiple basic SDKs may occur. Therefore, it is necessary to determine whether each basic SDK is compatible with the program access terminal. The stored SDK conflicts, and then modify the files of the conflicting SDK one by one. Then send multiple SDKs to the program access terminal respectively.

Because multiple SDKs are output separately, after receiving multiple SDKs, developers at the program access end need to learn the programming languages and programming logics of multiple SDKs respectively. This virtually increases the access cost of the access party and reduces the access efficiency. In order to improve the access efficiency, the embodiment of this manual will package each SDK and then output it. The developers at the program access end only need to study the packaged SDK in a unified manner.

In one or more embodiments of this specification, after the modification of the program statement that references the conflicting file, it also includes:

Determine multiple SDKs that need to be sent to the program access terminal, the multiple SDKs and the first SDK are used to jointly implement the first service;

Encapsulating the plurality of SDKs and the modified first SDK to generate a merged SDK;

Send the combined SDK to the program access terminal.

In this embodiment, the first SDK and multiple SDKs exist in a packaged form, that is, in a binary form. Therefore, before merging multiple SDKs, firstly decompress each SDK to obtain the class (code) files and resource files, property files, etc., such as R.java files and manifest files. First, merge properties files, etc., and then merge multiple class files. Then compile the merged property file and class file to generate the merged SDK, and then send it to the program access terminal.

In the embodiment of this specification, the first SDK and multiple SDKs can be edited and developed in Java language. Java is a cross-platform, interpreted language. Java source code is compiled into an intermediate "bytecode" and stored in a class file. Due to cross-platform requirements, Java bytecode includes a lot of source code information, such as variable names and method names, and access variables and methods through these names. These symbols carry a lot of semantic information and are easily decompiled into Java. source code. In order to prevent this phenomenon, you can use the Java obfuscator to obfuscate the Java bytecode.

Obfuscation is to reorganize and process the released program so that the processed code has the same function as the pre-processed code, and the obfuscated code is difficult to decompile, even if the decompilation is successful, it is difficult to obtain the true semantics of the program . The obfuscated program code still follows the original file format and instruction set, and the execution result is the same as before obfuscation, but the obfuscator changes the names of all variables, functions, and classes in the code into short English letter codes. In the case of corresponding function names and program comments, even if decompiled, it will be difficult to read. At the same time, obfuscation is irreversible. During the obfuscation process, some information that does not affect normal operation will be permanently lost. The loss of these information makes the program more difficult to understand.

The function of the obfuscator is not only to protect the code, but also to reduce the size of the compiled program. Due to the shortening of variable and function names and the loss of some information described above, the volume of the compiled jar file can be reduced by about 25%, which is meaningful for the current expensive wireless network transmission.

In this embodiment, after the first SDK and multiple SDKs are packaged, they are uniformly obfuscated, which avoids the phenomenon that multiple SDKs use multiple obfuscation rules to perform code obfuscation, and improves access efficiency.

However, it is necessary to solve the problem of conflicting resource IDs of resource files in multiple SDKs during packaging. In order to solve the above problems, said packaging said multiple SDKs and said modified first SDK includes:

Obtain the first resource ID of the resource file in the first SDK;

Obtain the second resource ID of the resource files in the plurality of SDKs;

determining conflicting resource files with the same resource ID based on the first resource ID and the second resource ID;

Modifying the resource ID of the conflicting resource file, so that a resource file identified by the resource ID is unique;

Based on the modified resource ID of the conflicting resource file, modify the program statement that refers to the conflicting resource file;

Packaging the modified multiple SDKs and the modified first SDK.

Resource files will be packaged into the APK (res folder) or packaged into an independent resource APK package (such as framework-res.apk) during the compilation process. But these resource files will be given a unique ID or resource index to facilitate system access. Among them, the R.java file in the gen directory is automatically generated by the compiler, and it does not require developers to maintain it. R.java will automatically collect all resource files in the current application, and create corresponding IDs based on these resource files, including: layout resources, control resources, String resources, Drawable resources, etc. R.java can be simply understood as the resource dictionary of the current Android application.

Since each SDK includes an R.java file, the resource ID in the R.java file is automatically generated. Since multiple R.java files are included, it can only be guaranteed that there is no resource ID in one R.java file. Conflict issues. However, there may be a resource ID that exists in multiple R.java files, that is to say, a resource ID has corresponding resource files in different SDKs, so when calling the corresponding resource file through the resource ID A call conflict will occur. Therefore, it is necessary to modify the resource IDs of multiple resource files corresponding to the resource ID to avoid the problem of calling conflicts.

According to the method of this solution, if a resource ID conflict occurs, it is first necessary to determine the resource files in multiple SDKs where the resource ID conflict occurs, and then rename these resource files. Some specific rules can be set for renaming, which are not specifically limited here.

Identify conflicting resource files with the same resource ID. The following method can be adopted: For any resource ID, you can search it from all the R.java files in the SDK to see how many times the resource ID appears in total. If it only appears once, it means that the resource ID corresponds to a unique resource file. If the resource ID appears twice or more than twice, it means that the resource ID appears in multiple R.java files. Therefore, it is necessary to modify the same resource ID as the resource ID of the R.java files in multiple SDKs.

For example, one resource ID "0x7f030000" corresponds to multiple resource files a, b and c. Among them, a is located in SDK1, b is located in SDK2, and c is located in SDK3. In order to avoid resource file call conflicts, only the resource IDs of b and c can be modified. For example, the resource ID of b can be changed to "0x7f030001", and the resource ID of c can be changed to "0x7f030002". It is also possible to modify resource files a, b and c. For example, the resource ID of b can be modified to "0x7f030003", the resource ID of b can be modified to "0x7f030001", and the resource ID of c can be modified to "0x7f030002"

In order to accurately call the resource file, said modifying the resource IDs in the plurality of software development kits according to the resource IDs in the compiled files may also include:

The resource IDs in the R.java files in the multiple SDKs are replaced with the modified resource IDs;

Replace the resource ID in the resource file reference statement in the software development kit with the modified resource ID.

In the specific application, the R.java file records the corresponding relationship between the resource file and the resource ID, and the resource ID in the R.java file needs to be modified. Modifying the resource ID in the R.java file means modifying the resource file and the resource ID. Correspondence between resource IDs. Therefore, in order to accurately call the resource file, correspondingly, the program statement for calling the resource file in the code needs to be modified.

For example, to refer to a resource file in a java program, refer to it according to the syntax of java: R.resource_type.resource_name, note: resource_name does not need the suffix of the file. If the resource ID of the resource file is changed from "0x7f030000" to "0x7f030001", then the reference statement of the resource file needs to be changed from "R.resource_type.0x7f030000" to "0x7f030001".

In addition, since multiple pairs of the first SDK and multiple SDKs are merged, Android components in different SDKs may run in different processes. Therefore, when implementing a service, multiple processes are often required to run in parallel, thus wasting system resources. . In order to reduce the waste of system resources, said packaging said plurality of SDKs and said modified first SDK may also include:

Decompressing the modified first SDK to obtain a first manifest file;

Decompressing the plurality of SDKs to obtain a plurality of second manifest files;

Modifying the process name in the first manifest file and the process names in the plurality of second manifest files to the same process name.

In the Android system, there are four major components, namely: Activity (display interface), Service (service), Content ProvIDer (data communication), and BroadcastReceiver (broadcast).

Activities are windows for users to interact with applications. An Activity is equivalent to an actual web page. When a screen is opened, the previous screen will be put into a paused state and pushed into the history stack. Users can roll back Operation returns to the previously opened screen.

Service is a program that can run for a long time, which is equivalent to a service in the background. The Service component is not visible at runtime, but it is responsible for updating data sources and visible Activities, as well as triggering notifications. They are often used to perform some processing that needs to run continuously when your Activity is no longer active or visible.

Content Provider is a content provider that provides shared data storage. A database that can be used to manage and share applications, through which you can share your own data to external calls, and provide an interface for third-party application data access.

Broadcast Receiver: Receive one or more Intents as the trigger time, receive related messages, do some simple processing, convert them into a Notification, and unify the Android event broadcast model. By creating and registering a Broadcast Receiver, an application can listen for broadcast Intents that meet certain criteria. BroadcastReceiver will automatically start your Android application to respond to the new incoming Intent.

The manifest file in the Android system can be understood as an application manifest, which must be included in the root directory of each application, and the file name must be exactly the same. This file contains the configuration information of the SDK, and the system needs to run the code of the SDK according to the content inside to display the interface.

The manifest file mainly has the following functions:

1. Name the Java package of the application. The package name acts as a unique identifier for the app. This is the name of our apk, usually our name is like "com.Android.gles3jni", similar to the Java class name, the purpose is to make it a unique value.

2. Describe the various components of the application, including the activities, services, broadcast receivers, and content providers that make up the application. It also names the classes that implement each component and publishes their functionality, such as the Intent messages they can handle. These declarations tell the Android system about components and the conditions under which those components can be started.

3. Determine the process hosting the application components.

4. Declare which permissions the application must have to access protected parts of the API and interact with other applications. Also declares the permissions that other apps need to interact with the app's components

5. List the Instrumentation classes that provide analysis and other information while the application is running. These declarations will only appear in the manifest while the app is in development and will be removed before the app is published.

6. Declare the minimum Android API level required by the application

7. List the libraries that the application must link against.

Therefore, if you want to modify the process name, you need to get the manifest file of each SDK. In this embodiment, the invoked SDK exists in a packaged form, so the SDK needs to be decompressed first to obtain a manifest file. Then, change the process names in all the manifest files to the same process name, and then merge all the manifest files. In this way, when compiling and running the packaged SDK, only one process needs to be established, and there is no need to establish multiple processes, thereby reducing the waste of system resources.

For the modification of the process name, the original process name can be adopted, and a new process name can also be adopted.

In one or more embodiments of this specification, modifying the process name in the first manifest file and the process names in the plurality of second manifest files to the same process name may specifically include:

Obtain a plurality of process names in the first manifest file and a plurality of process names in the plurality of second manifest files;

Determine the main process name, the main process name is one of the multiple process names in the first manifest file, or the main process name is one of the multiple process names in the multiple second manifest files one of;

Modifying multiple process names in the second manifest file to the main process name;

Modifying multiple process names in the multiple second manifest files to the main process name.

In the above embodiment, a method for modifying the process name in the manifest file is provided, which can randomly select one of the multiple process names in the first manifest file, or multiple process names in the multiple second manifest files One of the process names is used as the main process name. Then modify all the process names in the first manifest file and the process names in the multiple second manifest files to the main process name.

It should be noted that there may be multiple process names in a manifest file, because an SDK may include multiple Android components, and different components may also run in different processes. Therefore, it is necessary to modify all the process names in a manifest file.

Based on the same idea, the embodiment of this specification also provides a device corresponding to the above method. FIG. 2 is a schematic structural diagram of an apparatus for modifying file names in the SDK corresponding to FIG. 1 provided by the embodiment of this specification. As shown in Figure 2, the device may include:

The first obtaining module 201 is used to obtain the first file name information; the first file name information is used to indicate the file name of the file in the first SDK that needs to be sent to the program access terminal;

The second acquiring module 202 is configured to acquire second file name information; the second file name information is used to indicate the file name of the file in the second SDK stored by the program access terminal;

A conflicting file determining module 203, configured to determine a conflicting file in the first SDK based on the first file name information and the second file name information; the file name of the conflicting file is the same as that in the second SDK. The file name of the file is the same;

The file name modifying module 204 is configured to modify the file name of the conflicting file.

The device in Figure 2, before sending the first SDK to the program access terminal, first obtains the second SDK stored in the program access terminal, the package names of the first SDK box and the second SDK are the same, and then compares the first SDK and the second SDK Whether the file names of the files in the two SDKs are the same. If they are the same, modify the file name of the first SDK, so as to avoid the conflict between the first SDK and the second SDK when compiling in the program access terminal. The above method can effectively solve the problem that there are two different versions of SDK in the same machine, and the problem of version conflict and incompatibility occurs. Processing efficiency.

Optionally, before the obtaining of the first file name information, the device may further include:

The first version obtaining module is used to obtain the first version number information of the first SDK;

The second SDK determination module is configured to determine the second SDK according to the package name of the first SDK, the package name of the second SDK is the same as the package name of the first SDK;

a second version obtaining module, configured to obtain the second version number information of the second SDK;

A judging module, configured to judge whether the versions of the first SDK and the second SDK are the same based on the first version number information and the second version number information, and obtain a judgment result;

The first obtaining module 201 may be specifically configured to: obtain the first file name information when the judgment result indicates that the versions of the first SDK and the second SDK are different.

Optionally, the device may also include:

The reference statement modification module is used to modify the program statement that refers to the conflict file according to the modified file name of the conflict file.

Optionally, the file name modification module 204 may be specifically configured to: add a specific character string to the original file name of the conflicting file, wherein, when there are multiple conflicting files, multiple conflicting files The file name of the file is incremented by the same specific string.

Optionally, the device may also include:

A plurality of SDK determination modules, configured to determine a plurality of SDKs that need to be sent to the program access terminal, and the plurality of SDKs and the first SDK are used to jointly implement the first service;

An encapsulation module, configured to encapsulate the plurality of SDKs and the modified first SDK to generate a merged SDK;

A sending module, configured to send the merged SDK to the program access terminal.

Optionally, the packaging module may specifically include:

The first resource ID unit is used to obtain the first resource ID of the resource file in the first SDK;

The second resource ID unit is used to obtain the second resource ID of the resource files in the plurality of SDKs;

A conflicting resource file determining unit, configured to determine conflicting resource files with the same resource ID based on the first resource ID and the second resource ID;

A resource ID modifying unit, configured to modify the resource ID of the conflicting resource file, so that a resource file identified by the resource ID is unique;

A reference statement modifying unit, configured to modify a program statement that refers to the conflict resource file based on the modified resource ID of the conflict resource file;

A packaging unit, configured to package the modified multiple SDKs and the modified first SDK.

Optionally, the packaging module may also include:

a first decompression unit, configured to decompress the modified first SDK to obtain a first manifest file;

The second decompression unit is used to decompress the multiple SDKs to obtain multiple second manifest files;

A process name modifying unit, configured to modify the process name in the first manifest file and the process names in the plurality of second manifest files to the same process name.

Based on the same idea, the embodiment of this specification also provides a device corresponding to the above method.

FIG. 3 is a schematic structural diagram of an electronic device corresponding to FIG. 1 provided by the embodiment of this specification. As shown in Figure 3, device 300 may include:

at least one processor 310; and,

a memory 330 communicatively connected to the at least one processor; wherein,

The memory 330 stores instructions 320 executable by the at least one processor 310, the instructions are executed by the at least one processor 310, so that the at least one processor 310 can:

Obtain first file name information; the first file name information is used to indicate the file name of the file in the first SDK that needs to be sent to the program access terminal;

Obtaining second file name information; the second file name information is used to indicate the file name of the file in the second SDK stored by the program access terminal;

Determine the conflicting file in the first SDK based on the first file name information and the second file name information; the file name of the conflicting file is the same as the file name of the file in the second SDK;

Modify the filename of the conflicting file.

The electronic device in Figure 3, before sending the first SDK to the program access terminal, first obtains the second SDK stored in the program access terminal, the package name of the first SDK box and the second SDK are the same, and then compares the first SDK and the second SDK. Whether the file name of the file in the second SDK is the same. If they are the same, modify the file name of the first SDK, so as to avoid the conflict between the first SDK and the second SDK when compiling in the program access terminal. The above method can effectively solve the problem that there are two different versions of SDK in the same machine, and the problem of version conflict and incompatibility occurs. Processing efficiency.

The embodiment of this specification also provides a computer-readable medium, on which computer-readable instructions are stored, and the computer-readable instructions can be executed by a processor to implement the above-mentioned method for modifying a file name in the SDK.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (Programmable Logic Device, PLD) (such as a Field Programmable Gate Array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, and its logic function is determined by programming the device by a user. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when writing programs. The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., currently the most commonly used is VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers, and embedded microcontrollers, examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Combinations of any of these devices.

For the convenience of description, when describing the above devices, functions are divided into various units and described separately. Of course, when implementing the present application, the functions of each unit can be implemented in one or more pieces of software and/or hardware.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may 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.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, A magnetic tape cartridge, magnetic tape disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

This application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment.

The above descriptions are only examples of the present application, and are not intended to limit the present application. For those skilled in the art, various modifications and changes may occur in this application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims (9)

1. A method of modifying file names in an SDK, comprising:

acquiring first file name information; the first file name information is used for representing the file name of a file in a first SDK which needs to be sent to a program access end;

acquiring second file name information; the second file name information is used for representing the file name of a file in a second SDK stored by the program access end; the first SDK and the second SDK have the same packet name;

determining a conflicting file in the first SDK based on the first file name information and the second file name information; the conflict file is represented by comparing the file name corresponding to the first file name information with the file name corresponding to the second file name information, and screening out the file names of the files with the same file name; the file name of the conflict file is the same as the file name of the file in the second SDK;

modifying the file name of the conflict file specifically comprises the following steps: adding a specific character string in the original file name of the conflict file;

setting a mapping relation, and mapping the original file of the conflict file to the modified file;

the method further comprises the following steps:

determining a plurality of SDKs which need to be sent to the program access terminal, wherein the plurality of SDKs and the first SDK are used for jointly realizing a first service;

packaging the plurality of SDKs and the modified first SDK to generate a combined SDK;

and sending the combined SDK to the program access end.

2. The method of claim 1, further comprising, prior to said obtaining first filename information:

acquiring first version number information of the first SDK;

determining the second SDK according to the packet name of the first SDK, wherein the packet name of the second SDK is the same as the packet name of the first SDK;

acquiring second version number information of the second SDK;

judging whether the versions of the first SDK and the second SDK are the same or not based on the first version number information and the second version number information to obtain a judgment result;

the acquiring of the first file name information specifically includes:

and when the judgment result shows that the versions of the first SDK and the second SDK are different, acquiring the first file name information.

3. The method according to claim 1, wherein the modifying the filename of the conflicting file specifically comprises:

and adding specific character strings in the original file names of the conflict files, wherein when the conflict files are multiple, the added specific character strings of the file names of the multiple conflict files are the same.

4. The method of claim 1, further comprising, after said modifying the filename of the conflicting file:

and modifying the program statement for referencing the conflict file according to the modified file name of the conflict file.

5. The method of claim 1, wherein the encapsulating the plurality of SDKs and the modified first SDK comprises:

acquiring a first resource ID of a resource file in the first SDK;

acquiring second resource IDs of resource files in the plurality of SDKs;

determining a conflicting resource file with the same resource ID based on the first resource ID and the second resource ID;

modifying the resource IDs of the conflicting resource files such that a resource file identified by one of the resource IDs is unique;

modifying a program statement for referencing the conflicted resource file based on the modified resource ID of the conflicted resource file;

and packaging the modified plurality of SDKs and the modified first SDK.

6. The method of claim 5, the encapsulating the plurality of SDKs and the modified first SDK, further comprising:

decompressing the modified first SDK to obtain a first manifest file;

decompressing the plurality of SDKs to obtain a plurality of second manifest files;

and modifying the process name in the first manifest file and the process names in the plurality of second manifest files into the same process name.

7. An apparatus for modifying a file name in an SDK, comprising:

the first acquisition module is used for acquiring first file name information; the first file name information is used for representing the file name of a file in a first SDK which needs to be sent to a program access end;

the second acquisition module is used for acquiring second file name information; the second file name information is used for representing the file name of a file in a second SDK stored by the program access terminal; the first SDK and the second SDK have the same packet name;

a conflict file determining module, configured to determine a conflict file in the first SDK based on the first file name information and the second file name information; the file name of the conflict file is the same as the file name of the file in the second SDK; the conflict file is represented by comparing the file name corresponding to the first file name information with the file name corresponding to the second file name information, and screening out the file names of the files with the same file name;

the file name modifying module is used for modifying the file name of the conflict file; adding a specific character string in the original file name of the conflict file; setting a mapping relation, and mapping the original file of the conflict file to the modified file;

a determining module, configured to determine multiple SDKs that need to be sent to the program access terminal, where the multiple SDKs and the first SDK are used to jointly implement a first service;

the generating module is used for packaging the plurality of SDKs and the modified first SDK to generate a combined SDK;

and the sending module is used for sending the combined SDK to the program access end.

8. An electronic device, comprising:

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to:

acquiring first file name information; the first file name information is used for representing the file name of a file in a first SDK which needs to be sent to a program access end;

acquiring second file name information; the second file name information is used for representing the file name of a file in a second SDK stored by the program access terminal; the first SDK and the second SDK have the same packet name;

determining a conflicting file in the first SDK based on the first file name information and the second file name information; the conflict file is represented by comparing the file name corresponding to the first file name information with the file name corresponding to the second file name information, and screening out the file names of the files with the same file name; the file name of the conflict file is the same as the file name of the file in the second SDK;

modifying the file name of the conflict file specifically comprises the following steps:

adding a specific character string in the original file name of the conflict file;

setting a mapping relation, and mapping the original file of the conflict file to the modified file;

determining a plurality of SDKs which need to be sent to the program access terminal, wherein the plurality of SDKs and the first SDK are used for jointly realizing a first service;

packaging the plurality of SDKs and the modified first SDK to generate a combined SDK;

and sending the combined SDK to the program access end.

9. A computer readable medium having stored thereon computer readable instructions executable by a processor to implement the method of modifying filenames in an SDK of any of claims 1 to 6.

Images