CN115510505A - 应用文件的打包方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本申请涉及公开了一种应用文件的打包方法、装置、电子设备及可读存储介质，其方法包括：获取源代码文件，并确定源代码文件的开发类型；若确定的开发类型为第一格式，则基于第一格式的原有打包流程，对源代码文件进行打包，得到第一格式应用文件；若确定的开发类型为第二格式，则对源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。本申请即兼顾了原有的第一格式应用，又兼顾了新的第二格式应用的需求，使得应用本申请的编译平台具备较高的兼容性，且满足了底层开发框架对待发布的应用文件的格式要求；另外若确定的开发类型为第二格式，则对源代码文件进行加固，从而可以保证源代码不被泄露，提高了源代码的安全强度。

Description

应用文件的打包方法、装置、电子设备及可读存储介质

技术领域

本申请涉及安卓应用市场技术领域，具体涉及一种应用文件的打包方法、装置、电子设备及可读存储介质。

背景技术

自2021年8月起，谷歌应用市场开始要求开发者以Android App Bundle(AAB)格式发布新应用。AAB格式可以针对不同设备的配置和语言进行分发，同时，可以使应用程序的体积更小、下载应用程序的速度更快，进而提升用户安装应用和更新应用的体验。

对于投放到海外的AAB格式应用程序文件，需要保证应用程序文件的代码不被泄露，提高代码的安全强度。同时，在对开发的应用程序文件进行测试时，需要真机验证，然而，AAB格式的文件不同于APK格式的文件，它不能直接安装到设备上，故给测试人员带来诸多不便。

发明内容

针对上述情况，本申请实施例提供了一种应用文件的打包方法、装置、电子设备及可读存储介质。

第一方面，本申请实施例提供了一种应用文件的打包方法，包括：

获取源代码文件，并确定所述源代码文件的开发类型；

若确定的开发类型为第一格式，则基于所述第一格式的原有打包流程，对所述源代码文件进行打包，得到第一格式应用文件；

若确定的开发类型为第二格式，则对所述源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。

第二方面，本申请实施例还提供了一种应用文件的打包装置，所述装置部署于编译平台，包括：

获取单元，用于获取源代码文件，并确定所述源代码文件的开发类型；

第一打包单元，用于若确定的开发类型为第一格式，则基于所述第一格式的原有打包流程，对所述源代码文件进行打包，得到第一格式应用文件；

第二打包单元，用于若确定的开发类型为第二格式，则对所述源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。

第三方面，本申请实施例还提供了一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行上述任一的方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行上述任一的方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请提供了一种应用文件的打包方法，该方法主要针对现有应用需要采用新的文件格式进行发行的需求提出，其可以由编译平台执行，当检测到开发人员提交的源代码的开发类型为第一格式，则基于第一格式的原有打包流程，对源代码打包；而当检测到开发人员提交的源代码的开发类型为第二格式，则对所述源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。一方面，本申请先判断源代码的开发类型，进而确定对源代码文件进行哪种类型的打包流程，即兼顾了原有的第一格式应用，又兼顾了新的第二格式应用的需求，使得应用本申请的编译平台具备较高的兼容性，且满足了底层开发框架对待发布的应用文件的格式要求；第二方面，本申请通过判断源代码的开发类型，若确定的开发类型为第二格式，则对源代码文件进行加固，从而可以保证源代码不被泄露，提高了源代码的安全强度。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请提供的一个实施例的应用文件的打包方法的流程示意图；

图2为本申请提供的另一个实施例的应用文件的打包方法的结构示意图；

图3为本申请提供的一个实施例的应用文件的打包装置的结构示意图；

图4为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

对于投放到海外的AAB格式应用程序文件，需要保证应用程序文件的代码不被泄露，提高代码的安全强度。同时，在对开发的应用程序文件进行测试时，需要真机验证，然而，AAB格式的文件不同于APK格式的文件，它不能直接安装到设备上，故给测试人员带来诸多不便。

针对上述问题，本申请提出了一种应用文件的打包方法，图1为本申请提供的一个实施例的应用文件的打包方法的流程示意图，所述方法可由编译平台执行，从图1可以看出，本申请至少包括步骤S101-步骤S103：

步骤S101：获取源代码文件，并确定源代码文件的开发类型。

开发人员可以在编译平台进行应用的开发和代码的提交，在开发人员将源代码文件提交后，编译平台获取源代码文件，在本申请提供的编译平台上，同时支持第一格式和第二格式开发代码的打包，对于第一格式的源代码的打包，可以理解为现有需求，对其第一格式的源代码可以记为第一格式的原有打包流程，可以直接将其集成在编译平台上，以供调用；而对于第二格式的源代码的打包，可以理解为新的需求，在本申请中，对于不同格式的源代码采用不同的打包流程，从而实现兼容两种不同格式应用文件的打包流程，以满足日志增长的前端应用的开发的需求。

首先，确定源代码文件的开发类型。本申请提供的编译平台能够兼顾多种格式的打包流程，故在获取到应用程序的源代码文件后，可以先根据源代码文件的文件后缀，判断源代码文件的开发类型，进而判断针对该源代码文件进行哪种打包流程。

步骤S102：若确定的开发类型为第一格式，则基于所述第一格式的原有打包流程，对源代码文件进行打包，得到第一格式应用文件。

在确定了源代码文件的开发类型之后，若确定的开发类型为第一格式，则基于第一格式对应的原有的打包流程，对源代码文件进行打包，得到第一格式应用文件。第一格式的原有打包流程可以根据第一格式具体为何种格式进行设定，在本申请的一些实施例中，第一格式为Android Package格式(APK格式)，这种情况下，第一格式对应的原有的打包流程为安卓框架下集成开发工具Android studio提供的打包流程，可调用Android studio提供的接口对源代码文件进行打包，或者将Android studio提供的打包方法集成于本申请提供的编译平台上直接只用，对源代码打包后得到第一格式应用文件。

具体的，Android Package格式(APK格式)是Android操作系统使用的一种应用程序包文件格式，用于分发和安装移动应用及中间件，一个APK文件内包含被编译的代码文件、文件资源、原生资源文件、证书、和清单文件等。

在Android studio中，可以根据下述步骤生成Android Package格式文件：点击Build、选择Generate Signed Bundle/APK…、选择APK、点击Next、选择源代码文件、选择已创建的密钥、填写密钥的别名和密码、点击Next、选择release版本、点击finish。点击Android studio中Event Log窗口的locate或者analyze可以跳转查看到打包生成的APK格式文件。

步骤S103：若确定的开发类型为第二格式，则对源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。

在本申请的一些实施例中，第二格式为Android APPBundle格式(AAB格式)。为了保证上架在海外软件平台上的第二格式应用文件的代码不被泄露，需要利用软件加固工具对源代码文件进行加固，得到加固后的文件。经过虚拟化技术保护后的、加固后的文件具备以下优势：(1)虚拟化的代码形成自定义二进制格式文件，无法静态查看，无法通过三方工具、API等进行解析并进一步分析；(2)无法被内存dump、调试等动态手段所查看；(3)虚拟化的代码属于不可逆状态，即一经保护则无法还原为原始明文。

其中，AAB格式的软件可以针对不同设备配置和语言进行分发。这种方式可令应用体积更小，下载速度更快，进而提升安装量，减少卸载量；AAB格式以动态方式交付大型资源，可以减少使用者等待时间，同时缩减交付成本。

根据安卓系统的要求，需要对上述加固后的文件进行目标框架签名。在本申请的一些实施例中，在上述方法中，目标框架为Google Play框架。这里，Google Play框架自带签名机制，该机制可以在系统后台生成一个签名文件，基于该签名文件，可以对上述加固后的文件进行数字签名，进而得到第二格式应用文件。

从图1所示的方法可以看出，本申请提供了一种应用文件的打包方法，该方法主要针对现有应用需要采用新的文件格式进行发行的需求提出，其可以由编译平台执行，当检测到开发人员提交的源代码的开发类型为第一格式，则基于第一格式的原有打包流程，对源代码打包；而当检测到开发人员提交的源代码的开发类型为第二格式，则对所述源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。一方面，本申请先判断源代码的开发类型，进而确定对源代码文件进行哪种类型的打包流程，可兼顾了多种格式文件的打包流程，使得应用本申请的编译平台具备较高的兼容性，且满足了底层开发框架对待发布的应用文件的格式要求；第二方面，本申请通过判断源代码的开发类型，若确定的开发类型为第二格式，则对源代码文件进行加固，从而可以保证源代码不被泄露，提高了源代码的安全强度。

需要说明的是，在应用包上架之前，通常需要对应用包进行测试，而AAB格式的文件不能直接安装到设备上，因此，需要生成一个供测试人员进行测试验证的APK格式的测试包。具体的，在本申请的一些实施例中，在上述方法中，所述方法还包括：将得到的第二格式应用文件转化为第一格式的测试应用文件，其中，测试应用文件为本地版本文件或通用版本文件。

将得到的第二格式应用文件转化为第一格式的测试应用文件，其中，测试应用文件为本地版本文件或通用版本文件。在一些实施例中，可以利用bundletool命令生成第一格式的测试应用文件。具体的，可以根据下述命令生成第一格式的测试应用文件：

bundletool build-apks--bundle＝/app/myapp.aab--output＝test_aab.apks--

ks＝/usr/build_lib/android-sdk-linux/ijiami/doctor-th-az.keystore--ks-

pass＝pass:keystore的pwd

--ks-key-alias＝doctor

--key-pass＝pass:keystore的pwd

--mode＝universal

bundletool extract-apks--apks＝test_aab.apks--output-

dir＝my_pixel2_APK_set.apks--device-

spec＝/home/scmbuild/aab_config/test_abb.json

然后，对通用测试包进行设备配置，具体的：

"supportedAbis":["arm64-v8a","armeabi-v7a"],

"supportedLocales":["en","fr"],

"screenDensity":640,

"sdkVersion":30

在上述实施例中，将得到的第二格式应用文件转化为第一格式的测试应用文件，由于该测试应用文件可以直接安装到设备上，故测试人员可以实现对源代码文件的测试验证。

在本申请的一些实施例中，在上述方法中，所述方法还包括：获取测试应用文件的测试结果；若测试结果为通过，则将与测试应用文件对应的第二格式应用文件进行上架。

获取测试应用文件的测试结果；若测试结果为通过，则将与测试应用文件对应的第二格式应用文件进行上架。具体的，在一些实施例中，若测试结果为通过，则将与测试应用文件，即APK格式的文件对应的第二格式应用文件，即AAB格式的应用文件上架到应用程序商店中；若测试结果为不通过，则对源代码进行修改，并再次测试，直到测试结果为通过。

在本申请的一些实施例中，在上述方法中，所述测试应用文件为本地版本文件，且所述本地版本文件存储于电脑端，所述获取所述测试应用文件的测试结果包括：通过数据线载入所述电脑端，下载所述本地版本文件；对所述本地版本文件进行测试得到所述测试结果；或者，所述测试应用文件为通用版本文件，且通用版本文件关联可视识别码，所述获取所述测试应用文件的测试结果包括：使测试终端设备通过扫描所述可视识别码下载所述通用版本文件；对所述通用版本文件进行测试得到所述测试结果。

这里，测试终端设备可以为智能手机、平板等设备。测试应用文件的存储有两种情况，一种为存储于本地终端，另一种为存储于云端。

若测试应用文件为本地版本文件，且存储于电脑端，在进行测试时，测试终端设备刻意通过数据线连接或者载入电脑端下载本地版本文件，并进行测试，测试后得到测试结果。如在一些实施例中，测试人员可以通过数据线将智能手机与电脑连接在一起，下载获得本地版本文件，基于编写好的测试用例，在智能手机上对该本地版本文件进行测试，进而得到测试结果。

若测试应用文件存储于云端时，测试应用文件为通用版本文件，且通用版本文件关联可视识别码(如二维码)，在进行测试时，可以使测试终端设备通过扫描可视识别码下载所述通用版本文件，并进行测试得到测试结果。如在一些实施例中，测试人员可以利用智能手机与通用版本文件关联的扫描二维码，得到通用版本文件，再基于编写好的测试用例，在智能手机上对该本地版本文件进行测试，进而得到测试结果。

在本申请的一些实施例中，加固是根据下述方法进行的：调用娜迦信息加固平台提供的加固接口，对源代码文件进行加固。

其中，娜迦信息加固平台可以对APP文件/APK应用进行dex加壳、乱序保护、so加壳、虚拟机指令等多重保护，有效的对存储数据进行加密保护、保护APP安全。在一些实施例中，还可以根据实际情况，调用腾讯云应用乐固、阿里聚等平台提供的加固接口，对源代码文件进行加固，本申请对此不做限定。

图2为本申请提供的另一个实施例的应用文件的打包方法的结构示意图；由图2可知，本实施例的应用文件的打包方法包括以下步骤S201～步骤S209。

步骤S201，获取源代码文件，并确定源代码文件的开发类型。

步骤S202，确定开发类型是否为.apk格式；若是，则转步骤S203；若否，则转步骤S204。

步骤S203，基于.apk格式的原有打包流程，对源代码文件进行打包，得到.apk格式应用文件。

步骤S204，调用娜迦信息加固平台提供的加固接口，对源代码文件进行加固,得到加固后文件。

步骤S205，对加固后文件进行Google Play框架签名，得到.aab格式应用文件。

步骤S206，将得到的.aab格式应用文件转化为.apk格式的测试应用文件。

步骤S207，对.apk格式的测试应用文件进行测试，得到测试结果。

步骤S208，确定测试结果是否为通过；若是，则转步骤S209。

步骤S209，将与测试应用文件对应的.aab格式应用文件进行上架。

图3为本申请提供的一个实施例的应用文件的打包装置的结构示意图，所述装置300包括：

获取单元301，用于获取源代码文件，并确定所述源代码文件的开发类型；

第一打包单元302，用于若确定的开发类型为第一格式，则基于所述第一格式的原有打包流程，对所述源代码文件进行打包，得到第一格式应用文件；

第二打包单元303，用于若确定的开发类型为第二格式，则对所述源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。

在本申请的一些实施例中，在上述装置还包括：转化单元，用于将得到的第二格式应用文件转化为第一格式的测试应用文件，其中，所述测试应用文件为本地版本文件或通用版本文件。

在本申请的一些实施例中，在上述装置还包括：上架单元，用于获取所述测试应用文件的测试结果；若所述测试结果为通过，则将与所述测试应用文件对应的第二格式应用文件进行上架。

在本申请的一些实施例中，在上述装置中，所述测试应用文件为本地版本文件，且所述本地版本文件存储于电脑端，获取单元301，用于通过数据线载入所述电脑端，下载所述本地版本文件；对所述本地版本文件进行测试得到所述测试结果；或者，所述测试应用文件为通用版本文件，且通用版本文件关联可视识别码，获取单元301，用于使测试终端设备通过扫描所述可视识别码下载所述通用版本文件；对所述通用版本文件进行测试得到所述测试结果。

在本申请的一些实施例中，在上述装置中，所述加固是根据下述方法进行的：调用娜迦信息加固平台提供的加固接口，对所述源代码文件进行加固。

在本申请的一些实施例中，在上述装置中，所述目标框架为Google Play框架。

在本申请的一些实施例中，在上述装置中，所述第一格式为Android Package格式，所述第二格式为Android APP Bundle格式。

需要说明的是，上述任一的应用文件的打包装置可一一对应实现前述的应用文件的打包方法，这里不再赘述。

图4为本申请实施例提供的一种电子设备的结构示意图。如图4所示，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成应用文件的打包装置。处理器，执行存储器所存放的程序，并具体用于执行前述方法。

处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备可执行本申请多个实施例提供的应用文件的打包方法，并实现成应用文件的打包装置在图3所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行本申请多个实施例提供的应用文件的打包方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的同一要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种应用文件的打包方法，其特征在于，所述方法由编译平台执行，所述方法包括：

获取源代码文件，并确定所述源代码文件的开发类型；

若确定的开发类型为第一格式，则基于所述第一格式的原有打包流程，对所述源代码文件进行打包，得到第一格式应用文件；

若确定的开发类型为第二格式，则对所述源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将得到的所述第二格式应用文件转化为所述第一格式的测试应用文件，其中，所述测试应用文件为本地版本文件或通用版本文件。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

获取所述测试应用文件的测试结果；

若所述测试结果为通过，则将与所述测试应用文件对应的第二格式应用文件进行上架。

4.根据权利要求3所述的方法，其特征在于，所述测试应用文件为本地版本文件，且所述本地版本文件存储于电脑端，所述获取所述测试应用文件的测试结果包括：

通过数据线载入所述电脑端，下载所述本地版本文件；对所述本地版本文件进行测试得到所述测试结果；

或者，

所述测试应用文件为通用版本文件，且通用版本文件关联可视识别码，所述获取所述测试应用文件的测试结果包括：

使测试终端设备通过扫描所述可视识别码下载所述通用版本文件；对所述通用版本文件进行测试得到所述测试结果。

5.根据权利要求1所述的方法，其特征在于，所述加固是根据下述方法进行的：

调用娜迦信息加固平台提供的加固接口，对所述源代码文件进行加固。

6.根据权利要求1～5中任一项所述的方法，其特征在于，所述目标框架为Google Play框架。

7.根据权利要求1～5中任一项所述的方法，其特征在于，所述第一格式为AndroidPackage格式，所述第二格式为Android APP Bundle格式。

8.一种应用文件的打包装置，其特征在于，所述装置部署于编译平台，所述方法包括：

获取单元，用于获取源代码文件，并确定所述源代码文件的开发类型；

第一打包单元，用于若确定的开发类型为第一格式，则基于所述第一格式的原有打包流程，对所述源代码文件进行打包，得到第一格式应用文件；

第二打包单元，用于若确定的开发类型为第二格式，则对所述源代码文件依次进行加固和目标框架签名，得到第二格式应用文件。

9.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行所述权利要求1～7所述方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行所述权利要求1～7所述方法。

Images