CN110941443A

CN110941443A - Method and device for modifying file name in SDK and electronic equipment

Info

Publication number: CN110941443A
Application number: CN201911273604.2A
Authority: CN
Inventors: 王鹏锋
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: AlipayCom Co ltd
Priority date: 2019-12-12
Filing date: 2019-12-12
Publication date: 2020-03-31
Anticipated expiration: 2039-12-12
Also published as: CN110941443B

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 and device for modifying file name in SDK and electronic equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for modifying a file name in an SDK, and an electronic device.

Background

In the prior art, sometimes a program access party accesses a Software Development Kit (SDK) of a service output party for multiple times, and in addition, the SDK is continuously optimized for better service, so that the same SDK has multiple different versions. Therefore, when the service output party outputs each SDK, it is necessary to check whether the service access party has accessed the SDK and determine whether the accessed version is the same as the SDK to be accessed. If the versions are different, the problem of compatibility between different versions needs to be solved.

There is a need to provide faster solutions that are incompatible for versions of the same SDK.

Disclosure of Invention

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

In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:

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

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.

The apparatus for modifying a file name in an SDK provided in an embodiment of this specification includes:

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 end;

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;

and the file name modifying module is used for modifying the file name of the conflict file.

An electronic device provided in an embodiment of the present specification includes:

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 content of the first and second substances,

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

and modifying the file name of the conflict file.

Embodiments of the present specification provide a computer readable medium, on which computer readable instructions are stored, the computer readable instructions being executable by a processor to implement the above method for modifying a file name in an SDK.

The embodiment of the specification adopts at least one technical scheme which can achieve the following beneficial effects: before the first SDK is sent to the program access end, a second SDK stored by the program access end is firstly obtained, the packet names of a first SDK frame and the second SDK are the same, and then whether the file names of the files in the first SDK and the file names of the files in the second SDK are the same or not is compared. And if the first SDK is the same as the second SDK, modifying the file name of the first SDK, thereby avoiding the problem that the first SDK conflicts with the second SDK when the first SDK is compiled in the program access end. The method can effectively solve the problem that the two SDKs with different versions exist in the same machine and are incompatible in version conflict, and improves the processing efficiency of program access compared with the solution of artificially upgrading the low version of software in the prior art.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1 is a schematic flowchart of a method for modifying a file name in an SDK according to an embodiment of the present disclosure;

FIG. 2 is a schematic structural diagram of an apparatus for modifying a file name in an SDK according to FIG. 1 provided in an embodiment of the present disclosure;

fig. 3 is a schematic structural diagram of an electronic device corresponding to fig. 1 provided in an embodiment of the present disclosure.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

When one application APP (program access party) needs to access a certain service (such as a payment code service) of another application (service output party), for example, when a certain shopping APP needs to access a payment code service of a payment platform such as WeChat and Paibao, an SDK of the payment code service provided by the service output party (WeChat and Paibao) needs to be called, and after a developer of the access party decompresses the payment code SDK and learns the logic of the SDK, the function of the SDK can be realized. The service occurs in the development stage of the application, and only if the program access party successfully accesses the service, the application APP corresponding to the program access party can be on-line and used by the registered user of the application APP.

However, in some cases, the development platform of the service output side has a large number of functions, and for the convenience of programming by developers, some frequently used programs for realizing basic functions are packaged to generate the basic SDK. When a developer develops a certain service, the developer only needs to call the basic SDKs to realize a certain function without programming again. Thus, some services include multiple base SDKs invoked in addition to the main program. As it evolves, the underlying SDK process is often upgraded to cope with changes in demand. Therefore, the versions of the base SDK output by the service output side are different in different time periods. Therefore, before the service exporter exports a service to the program accessor, it is assumed that the service includes the login SDK, it is assumed that the program accessor has accessed the login SDK, and that the login SDK that the program accessor has accessed is a low version, and the login SDK that the service exporter will export to the program accessor is a high version. If the high version of the login SDK is directly output to the program access side, the problem of incompatibility of different versions occurs during compiling.

In order to solve the problem of incompatibility of different versions, a method of offline communication between developers of a program access party and developers of a service output party can be adopted, and after the low version of the service output party is upgraded to the high version, the service output party outputs the service. In this way, the operation is dependent on the off-line operation, the process is complicated, and the access efficiency is low.

In order to solve the problem that the SDKs of different versions are incompatible and improve access efficiency, in an embodiment of the present specification, before sending the first SDK to the program access end, first, a second SDK stored by the program access end is obtained, where packet names of the first SDK and the second SDK are the same, and then, whether file names of files in the first SDK and the second SDK are the same is compared. And if the first SDK file is the same as the second SDK file, modifying the file name in the first SDK file so as to avoid the problem that the first SDK conflicts with the second SDK when the first SDK is compiled in the program access end. The method can effectively solve the problem that the two SDKs with different versions exist in the same machine and are incompatible in version conflict, and compared with the method for solving the problem that the low version of the software is artificially updated in the prior art, the method has the advantage that the processing efficiency is improved.

The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

Fig. 1 is a flowchart illustrating a method for modifying a file name in an SDK according to an embodiment of the present disclosure. From the viewpoint of a program, the execution subject of the flow may be a program installed in an application server or an application client. The execution subject of the scheme is a device of a service output side, and can be a development server or any development client.

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

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

SDKs are generally a collection of development tools used by some software engineers to build application software for a particular software package, software framework, hardware platform, operating system, etc. Therefore, an SDK with special functions includes many files, and these files may be called modules in development software, such as class libraries in Java.

The Java authority provides developers with a number of powerful classes that are placed separately in packages and published with JDKs, called Java class libraries or Java APIs. An API (Application Programming Interface) is a general concept.

Class libraries in Java are modules that developers have developed and can be called by other developers. It is understood that a class library is like a warehouse, and there are many classes that have already been developed in the warehouse. Therefore, these classes are often used when a service is available.

The first file name information is used for representing the file name of the file in the first SDK which needs to be sent to the program access end, and the file name information can be acquired by calling the first SDK or only calling the file related to the file name of the file in the first SDK. Assuming that the first file name information exists in a certain file of the first SDK, it is only necessary to acquire the contents in the certain file.

In this scheme, the first SDK may be sent to the program access terminal separately, or may be sent to the program access terminal together with other SDKs, or may be sent to the program access terminal after being packaged with other SDKs.

It should be noted that "first" in "first file name information" and "first" in "first SDK" are merely used for distinction, and do not have an actual meaning.

Step 104: acquiring second file name information; the second file name information is used for representing the file name of the file in the second SDK stored by the program access end.

After determining that the first SDK needs to be sent to the program access terminal, it is necessary to determine whether the program access terminal has accessed a second SDK having the same packet name as the first SDK. If the program access end has accessed the second SDK, whether the first SDK and the second SDK conflict needs to be judged. The first and second SDKs have the same packet name, which means that the functions implemented by the first and second SDKs are the same or similar.

The second file name information may be obtained by obtaining a second SDK accessed from the program access terminal, and then obtaining second file information from the second SDK; and the second file name information can be acquired from the service output party and the second SDK stored by the service output party only according to the package name and the version number of the second SDK, so that the second SDK at the program access end does not need to be called, and the operation is simplified.

Step 106: 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 conflicting file is the same as the file name of the file in the second SDK.

Because the file name in the first SDK is to be modified to avoid the existence of the same file name as the second SDK, conflicting files in the first SDK need to be determined. A conflicting file is understood to be a file in a first SDK that is also referred to as a conflicting file if the file name of the file is also present in a second SDK.

The specific screening method may be to compare the file names corresponding to the first file name information with the file names corresponding to the second file name information one by one, and screen 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, and for the file name a, if the file name a exists in the second file name information, the file in the first SDK corresponding to the file name a is the conflict file; if the file name A does not exist in the second file name information, the file in the first SDK corresponding to the file name A is not a conflict file.

Step 108: and modifying the file name of the conflict file.

If the conflict file is determined, the file name of the conflict file needs to be modified, so that the modified file name does not exist the same as the file name of the second SDK, and the conflict is avoided.

To distinguish from the files in the second SDK, only the file name in the first SDK needs to be modified. For the modification of the file name, some characters or character strings can be added for distinction. These characters and character strings may be generated randomly or according to some rules. It may be of no practical significance or may represent special significance, and some special information may be obtained from these characters and character strings in the file name.

In the method in fig. 1, before sending the first SDK to the program access terminal, the second SDK stored by the program access terminal is first obtained, and the package names of the first SDK frame and the second SDK are the same, and then it is compared whether the file names of the files in the first SDK and the second SDK are the same. And if the first SDK is the same as the second SDK, modifying the file name of the first SDK, thereby avoiding the problem that the first SDK conflicts with the second SDK when the first SDK is compiled in the program access end. The method can effectively solve the problem that the two SDKs with different versions exist in the same machine and are incompatible in version conflict, and improves the processing efficiency of program access compared with the solution of artificially upgrading the low version of software in the prior art.

Based on the method of fig. 1, the embodiments of the present specification also provide some specific implementations of the method, which are described below.

In some specific scenarios, at step 102: before the first file name information is acquired, the method further comprises the following steps:

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.

In this embodiment, the implementation of a certain service often requires that multiple basic SDKs be called, and since the basic SDKs are updated all the time, the output time of each service is different, so that the versions of the selected basic SDKs may be different. Thus, two SDKs that collide are likely to be two different versions of one SDK.

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

If the version number of the first SDK is the same as that of the second SDK, the second SDK stored by the program access end is completely the same as the first SDK, and conflict cannot be caused during compiling. If the version number of the first SDK is different from the version number of the second SDK, the files in the first SDK which conflict with the second SDK need to be modified. In order to simplify the operation, only the file name of the file in the second SDK needs to be modified, so that the file with the conflict can be found out only by acquiring the file name information of the first SDK and the second SDK and comparing the file name information with the file name information of the second SDK.

To distinguish from the files in the second SDK, only the file name in the first SDK needs to be modified. For the modification of the file name, some characters or character strings can be added for distinction. Specifically, in order to improve the modification efficiency, the modifying the filename of the conflicting file specifically includes:

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.

There are many packages in the Java class library:

beginning with Java is a Java core package, all programs will use the classes in these packages;

beginning with javax is an extension packet, x is the meaning of extension, i.e., an extension. Although java x is an optimization and extension to java x, java x is also part of the core and is also released with JDK as it is used more and many programs depend on java x.

Beginning with org are packages issued by various organizations or organizations, which also issue, along with JDK, some of the commonly used classes they develop, because they are influential and their code quality is high.

Suppose that the file name where the conflict occurs is okio.A, wherein okio is the name of the tool kit (cannot be modified), and A is the name of the class. And modifying the file name of the conflict file, namely setting a class mapping relation, and mapping the okeo.A to the modified file name, such as the okeo.custom.A, wherein the custom is an increased character string.

Assuming that the file name of a conflict file is java.util.date, wherein java.util is the name of the tool kit, and Date is the name of the class, the modified file name is java.util.custom. Therefore, all the conflict files are added into a specific character string, and the modification efficiency is improved.

In order to accurately call the file, after the modifying the file name of the conflicting file, the method further includes:

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

In specific application, modifying the file name is to modify the corresponding relationship between the file name and the file, so that when the file is called, the program statement called by the file in the code is also modified correspondingly. The specific operation is to traverse all class (code) files, replacing class names and import references. import can only import classes contained in a package, and cannot import packages.

For example, the original reference statement is: import java.util.date; importing Date under a java.util packet;

the modified application statement is: import java.util.custom.date; // import custom. date under java. oil bag.

In some specific scenarios, one service often needs to be completed by multiple basic SDKs together, and therefore, a situation that multiple basic SDKs all conflict occurs may occur, and therefore, it is necessary to determine whether each basic SDK conflicts with an SDK stored at a program access terminal, and then modify files of the conflicting SDKs one by one. And then the plurality of SDKs are respectively sent to the program access ends.

Since the plurality of SDKs are output separately, developers at the program access end need to learn the programming languages and the programming logics of the plurality of SDKs after receiving the plurality of SDKs. This virtually increases the access cost of the access party and reduces the access efficiency. In order to improve access efficiency, in the embodiments of the present specification, after the SDKs are packaged, the SDKs are output, and developers at the program access end only need to learn the packaged SDKs in a unified manner.

In one or more embodiments of the present specification, after the modifying the program statement referring to the conflict file, the method further includes:

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.

In this embodiment, the first SDK and the plurality of SDKs are in a packed form, that is, in a binary form, so that before the plurality of SDKs are merged, each SDK is first decompressed to obtain a class (code) file and a resource file, a property file, and the like, such as an r.java file and a manifest file. The property files and the like are merged first, and then a plurality of class files are merged. And compiling the combined attribute file and class file to generate a combined SDK, and then sending the SDK to a program access end.

In the embodiment of the present specification, the first SDK and the plurality of SDKs may be edited and developed in Java language. Java is a cross-platform, interpreted language in which Java source code is compiled into intermediate "bytecodes" that are stored in a class file. Due to the requirement of cross-platform, Java byte codes comprise a lot of source code information, such as variable names and method names, and variables and methods are accessed through the names, and the symbols carry a lot of semantic information and are easily compiled back into Java source codes. To prevent this, a Java obfuscator may be used to obfuscate the Java bytecode.

Obfuscating is to reorganize and process the issued program so that the processed code and the code before processing complete the same function, but the obfuscated code is difficult to be decompiled, and even if the decompilation is successful, the true semantics of the program is difficult to be obtained. The obfuscated program code still conforms to the original file format and instruction set, and the execution result is the same as before obfuscation, except that the obfuscator changes all the variable, function and class names in the code into short English letter codes, and even if the obfuscator is decompiled, the obfuscator cannot read the codes without corresponding function names and program annotations. At the same time, the obfuscation is irreversible, and some information which does not affect the normal operation will be lost permanently in the process of obfuscation, and the loss of the 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 above-mentioned reasons of shortening variable and function names and losing part of information, the volume of the compiled jar file can be reduced by about 25%, which is significant for the current expensive wireless network transmission.

In the embodiment, after the first SDK and the plurality of SDKs are packaged, the SDKs are uniformly mixed, so that the phenomenon that the plurality of SDKs adopt a plurality of mixing rules to mix codes is avoided, and the access efficiency is improved.

However, the problem of resource ID collision of resource files in multiple SDKs needs to be solved during packaging. In order to solve the above problem, the encapsulating the plurality of SDKs and the modified first SDK specifically includes:

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 the 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 plurality of modified SDKs and the first modified SDK.

Resource files may be packaged into APKs (res folders) during the compilation process or into separate resource APK packages (e.g., frame-res. But these resource files are given unique IDs, i.e., resource indices, to facilitate system access. Wherein, the R.java file under the gen catalogue is automatically generated by a compiler without being maintained by a developer. Java will automatically receive and record all resource files in the current application, and establish corresponding IDs according to these resource files, including: layout resources, control resources, String resources, Drawable resources, and the like. Java can be simply understood as a resource dictionary for current Android applications.

Because each SDK includes one r.java file, the resource ID in the r.java file is automatically generated, and because a plurality of r.java files are included, it can only be guaranteed that there is no resource ID collision in one r.java file. However, there may be a resource ID existing in a plurality of r.java files, that is, one resource ID has corresponding resource files in different SDKs, so that a call conflict occurs when the corresponding resource file is called by the resource ID. Therefore, the resource IDs of the resource files corresponding to the resource IDs need to be modified to avoid the problem of call conflicts.

According to the method of the scheme, if resource ID conflict occurs, the resource files with resource ID conflict in the SDKs need to be determined, and then the resource files are named again. The renaming may set some specific rules, which are not specifically limited herein.

And determining the conflict resource file with the same resource ID. The following method can be adopted: for any resource ID, it can be looked up from r.java files in all SDKs to see that the resource ID appears several times in total. If it occurs only once, it can be stated that the resource ID corresponds to a unique resource file. If the resource ID occurs twice or more, it is indicated that the resource ID occurs in a plurality of r.java files. It is necessary to modify the resource ID of the r.java file in the plurality of SDKs, which is identical to the resource ID.

For example, one resource ID "0 x7f 030000" corresponds to a plurality of resource files a, b, and c. Where a is located in SDK1, b is located in SDK2, and c is located in SDK 3. In order to avoid resource file call collision, only the resource IDs of b and c may be modified, for example, the resource ID of b may be modified to "0 x7f 030001", and the resource ID of c may be modified to "0 x7f 030002". Resource files a, b, and c may also be modified, e.g., resource ID of b may be modified to "0 x7f 030003", resource ID of b may be modified to "0 x7f 030001", resource ID of c may be modified to "0 x7f 030002"

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

replacing the resource ID in the R.java file in the plurality of SDKs with the modified resource ID;

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

In specific application, the corresponding relationship between the resource file and the resource ID is recorded in the r.java file, the resource ID in the r.java file needs to be modified, and modifying the resource ID in the r.java file is to modify the corresponding relationship between the resource file and the resource ID. Therefore, in order to accurately call the resource file, the program statement for calling the resource file in the code is modified correspondingly.

For example, a resource file is referenced in a java program, and the reference is according to the syntax of java: resource _ type, resource _ name, note: resource _ name does not require a suffix name for the file. If the resource ID of the resource file is modified from "0 x7f 030000" to "0 x7f 030001", the reference sentence of the resource file needs to be modified from "r.resource _ type.0x7f030000" to "0 x7f 030001".

In addition, as a plurality of pairs of the first SDKs and the plurality of SDKs are combined, but Android components in different SDKs may run in different processes, when one service is implemented, a plurality of processes are often required to be parallel, thereby wasting system resources. In order to reduce the waste of system resources, the encapsulating the plurality of SDKs and the modified first SDK may further 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;

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.

In the Android system, there are four major components, respectively: there are Activity, Service, Content ProvIDer, broadcastereiver.

Activities are windows through which the user interacts with the application, an Activity corresponds to an actual web page, when a screen is opened, the previous screen is put into a pause state and pushed into the history stack, and the user can return to the previously opened screen through a rollback operation.

Service is a program that can run for a long time, corresponding to a Service in the background. The Service component is not visible at runtime, but it is responsible for updating the data source and the Activity that is visible, as well as triggering notifications. When your Activity is not already active or visible, they are often used to perform some processing that requires constant running.

The Content ProvIDer is a Content ProvIDer that provides shared data storage. The database can be used for managing and sharing the application program, and the data of the database can be shared by the database to an external call and an interface for data access of a third party application.

Broadcast Receiver: one or more internal are received as trigger time, relevant messages are received, some simple processing is carried out, the messages are converted into a Notification, and an Android event broadcast model is unified. By creating and registering a Broadcast Receiver, an application can listen for a Broadcast Intent that meets certain conditions. Broadcastreever will automatically launch your Android application to respond to the incoming Intent.

The manifest file in the Android system can be understood as an application list, one must be contained in the root directory of each application, and the file names must be identical. The file contains the configuration information of the SDK, and the system needs to run the code of the SDK according to the content in the SDK and display an interface.

The manifest file mainly has the following functions:

1. naming the Java package of the application. The package name serves as a unique identifier for the application. This is the name of our apk, which is usually similar to "com. android. gles3jni", similar to the name of a Java class, with the aim of making it a unique value.

2. Various components of the application are described, including Activity, services, broadcast receivers, and content providers that constitute the application. It also names and publishes the class that implements each component's functionality, such as Intent messages that they can handle. These statements inform the Android system about the components and the conditions under which they can be started.

3. A process to host an application component is determined.

4. Declaring which rights an application must possess to access protected portions of the API and interact with other applications. But also declares the permissions that other applications need to possess to interact with the application component

5. Instrumentation classes are listed that can provide analysis and other information at application runtime. These declarations will only appear in the manifest when the application is in the development phase and will be removed before the application is released.

6. Declaring a minimum Android API level required by an application

7. The libraries to which the application must be linked are listed.

Therefore, to modify the process name, a manifest file for each SDK needs to be obtained. In this embodiment, the called SDK exists in a packed form, so that the SDK needs to be decompressed first to obtain a manifest file. And then modifying the process names in all the manifest files into the same process name, and then merging all the manifest files. Therefore, when the packed SDK is compiled and run, only one process needs to be established to finish the operation, and a plurality of processes do not need to be established, so that the waste of system resources is reduced.

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

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

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

determining a main process name, wherein the main process name is one of a plurality of process names in the first manifest file, or the main process name is one of a plurality of process names in the second manifest files;

modifying a plurality of process names in the second manifest file into the main process name;

and modifying the plurality of process names in the plurality of second manifest files into the main process name.

In the foregoing embodiment, a method for modifying a process name in a manifest file is provided, where one of a plurality of process names in a first manifest file or one of a plurality of process names in a plurality of second manifest files may be randomly selected as a main process name. And then modifying the plurality of process names in the first manifest file and the plurality of process names in the plurality of second manifest files into main process names.

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 run in different processes. Therefore, it is necessary to modify all of the process names in one manifest file.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method. Fig. 2 is a schematic structural diagram of an apparatus for modifying a file name in an SDK, corresponding to fig. 1, according to an embodiment of the present disclosure. As shown in fig. 2, the apparatus may include:

a first obtaining module 201, configured to obtain 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;

a second obtaining module 202, configured to obtain second filename 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;

a conflict file determining module 203, 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;

and a file name modifying module 204, configured to modify the file name of the conflicting file.

Before sending the first SDK to the program access end, the apparatus in fig. 2 first obtains the second SDK stored by the program access end, where the package names of the first SDK frame and the second SDK are the same, and then compares whether the file names of the files in the first SDK and the second SDK are the same. And if the first SDK is the same as the second SDK, modifying the file name of the first SDK, thereby avoiding the problem that the first SDK conflicts with the second SDK when the first SDK is compiled in the program access end. The method can effectively solve the problem that the two SDKs with different versions exist in the same machine and are incompatible in version conflict, and improves the processing efficiency of program access compared with the solution of artificially upgrading the low version of software in the prior art.

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

the first version acquisition module is used for acquiring first version number information of the first SDK;

the second SDK determining module is used for determining the second SDK according to the packet name of the first SDK, and the packet name of the second SDK is the same as the packet name of the first SDK;

the second version obtaining module is used for obtaining second version number information of the second SDK;

the judging module is used for 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 judging result;

the first obtaining module 201 may be specifically configured to: 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.

Optionally, the apparatus may further include:

and the reference statement modifying module is used for modifying the program statement for referencing 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: 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.

Optionally, the apparatus may further include:

the multiple SDK determining modules are used for determining multiple SDKs which need to be sent to the program access end, and the multiple SDKs and the first SDK are used for jointly realizing a first service;

the packaging 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.

Optionally, the encapsulation module may specifically include:

a first resource ID unit, configured to obtain a first resource ID of a resource file in the first SDK;

a second resource ID unit, configured to obtain a second resource ID of the resource file in the plurality of SDKs;

a conflict resource file determination unit, configured to determine, based on the first resource ID and the second resource ID, a conflict resource file with the same 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 one resource ID is unique;

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

and the packaging unit is used for packaging the plurality of modified SDKs and the first modified SDK.

Optionally, the encapsulation module may further include:

the first decompression unit is used for decompressing the modified first SDK to obtain a first manifest file;

the second decompression unit is used for decompressing the SDKs to obtain a plurality of second manifest files;

and the process name modifying unit is used for modifying the process names in the first manifest file and the process names in the second manifest files into the same process name.

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

Fig. 3 is a schematic structural diagram of an electronic device corresponding to fig. 1 provided in an embodiment of the present disclosure. As shown in fig. 3, the apparatus 300 may include:

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

a memory 330 communicatively coupled to the at least one processor; wherein the content of the first and second substances,

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

and modifying the file name of the conflict file.

Before sending the first SDK to the program access end, the electronic device in fig. 3 first obtains the second SDK stored by the program access end, where the package names of the first SDK frame and the second SDK are the same, and then compares whether the file names of the files in the first SDK and the second SDK are the same. And if the first SDK is the same as the second SDK, modifying the file name of the first SDK, thereby avoiding the problem that the first SDK conflicts with the second SDK when the first SDK is compiled in the program access end. The method can effectively solve the problem that the two SDKs with different versions exist in the same machine and are incompatible in version conflict, and improves the processing efficiency of program access compared with the solution of artificially upgrading the low version of software in the prior art.

Embodiments of the present specification also provide a computer readable medium having stored thereon computer readable instructions executable by a processor to implement the above-mentioned method for modifying a file name in an SDK.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardsradware (Hardware Description Language), vhjhd (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may 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, and the like) 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 will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The 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 memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

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

and modifying the file name of the conflict file.

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

acquiring first version number information of the first SDK;

acquiring second version number information of the second SDK;

the acquiring of the first file name information specifically includes:

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

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

5. The method of claim 4, further comprising, after said modifying the program statements referencing the conflicting file:

and sending the combined SDK to the program access end.

6. The method of claim 5, 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;

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

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

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

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

9. An electronic device, comprising:

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

and modifying the file name of the conflict file.

10. 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 7.