WO2019062771A1 - 一种Android应用多开实现方法、移动终端及存储介质 - Google Patents

一种Android应用多开实现方法、移动终端及存储介质 Download PDF

Info

Publication number
WO2019062771A1
WO2019062771A1 PCT/CN2018/107691 CN2018107691W WO2019062771A1 WO 2019062771 A1 WO2019062771 A1 WO 2019062771A1 CN 2018107691 W CN2018107691 W CN 2018107691W WO 2019062771 A1 WO2019062771 A1 WO 2019062771A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
android
clone
host
processor
Prior art date
Application number
PCT/CN2018/107691
Other languages
English (en)
French (fr)
Inventor
涂斌健
陈东持
郑嘉斌
Original Assignee
惠州Tcl移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 惠州Tcl移动通信有限公司 filed Critical 惠州Tcl移动通信有限公司
Publication of WO2019062771A1 publication Critical patent/WO2019062771A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order

Definitions

  • the prior art Android system does not support multiple instances of the same application, that is, an application can generally open only one instance and open an application interface.
  • an application can generally open only one instance and open an application interface.
  • mobile terminal system Android
  • This kind of demand is particularly prominent in the "WeChat” social software in China.
  • WeChat will dynamically check whether its package name has been tampered with at runtime, and if it is tampered with, or the signature does not match the original signature, it will refuse to start. It can be seen that this method is not universal at all.
  • An object of the present invention is to provide a method for implementing an Android application, a mobile terminal, and a storage medium.
  • a multi-open implementation method for Android applications including:
  • the Android application multi-open implementation method wherein the startup of the clone application includes the following steps:
  • the service background is opened for a corresponding new process.
  • the mobile terminal where the Android application multiple open implementation processing program is executed by the processor, further implements:
  • FIG. 5 is a schematic flowchart of a desktop portal Intent processing process of an original application live of another preferred embodiment of the Android application multi-opening implementation method according to the present invention
  • the adaptation of the content provider ContentProvider shows an installation adaptation process for the application containing the ContentProvider (only one adaptation fragment is shown, not a complete solution).
  • the package management service PackageManagerService registers the content declared on AndroidManifest.xml when the application is installed. Since the com.tencent.mm package name already exists, the package name needs to be modified here. However, it is not enough to modify the package name. If there is a ContentProvider in the application, you need to adapt their uri (Uniform Resource Identifier). Otherwise, the clone application will request the original application when requesting.
  • the data of the cloned application needs to be stored.
  • the system allocates storage space based on its application, usually in the path: /data/data/[apply unique package name]/.
  • the mobile terminal will open up separate storage space in its own storage directory, using WeChat as the original application.
  • An example based on the host clone application is: /data/data/com.tct.parallel/com .tencent.mm-1/0.
  • the Android application multi-opening implementation method, the mobile terminal and the storage medium are four component information of the AMS registration and clone application, and cannot simply traverse the component information declared on the original application AndroidManifest.xml, and then the traversal result is originally local. Then register again on the ActivityManagerService, because this will cause repeated registration (collision), resulting in component registration failure. If the AMS returns a request failure, the corresponding component will not be loaded and initialized even if the process of cloning the application is up, and the clone application will still be unsuccessful.
  • AndroidManifest.xml it will declare all the identities that can be declared on the Android system. Since all cloned applications are parasitic in the host, if you don't declare and successfully apply for all permissions first, then the cloned application will not be able to get the corresponding permissions to run its own business logic. Therefore, in this step, the solution of the present invention will apply for all the rights that can be applied for on the corresponding version of the Android system.
  • the host will traverse the information declared by the AndroidManifest.xml under the application through the PMS to cache the information. Specifically, the host will request to start an "empty service.”
  • the so-called "empty service” is a "shell". In fact, the "shell” itself does not accomplish anything of practical significance. It is just a seat, a shell that passes the request.
  • the service backend opens a new process.
  • the present invention compares the line that restarts a clone application to explain how to implement the clone application launch to the correct original application code entry, as follows:
  • ActivityThread In the client of the present invention, there are two key interface layers, one is ActivityThread and the local ActivityManagerNative.
  • ActivityThread The processing of the clone application component Activity is as follows, which shows the Handler.dispatchMessage broken in the P0 host process, you can see that the mComponent field is "com.tct.multiagent.client.proxy.ActivityProxy$P0":
  • the createPackageContext of the present invention will put LoadedApk into the code implementation of mPackages, where Context is in the LoadedApk object.
  • Context is in the LoadedApk object.
  • the mComponent shown in the dispatchMessage process code of the aforementioned Handler is replaced by the jp.naver.line.android process, and the msg.obj.dataDir is modified to "/data/data/com.tct.multiagent" through the JAVA reflection mechanism.
  • -1/0/jp.naver.line.android is not the original application "/data/data/jp.naver.line.android".
  • the implementation method of the present invention achieves the purpose of saving the data of the clone application in its own directory by modifying this field.
  • the Android application multi-open implementation processor When executed by the processor, the following steps are further implemented: before the startup of the clone application, the original application needs to apply for permission to the user when starting as a host; if the user refuses to give the user a certain Permissions, the host refuses to start.
  • the Android application multiple implementation processing program is executed by the processor, the following steps are further implemented: the storage path of the clone application is hosted by the original application, and is stored in a storage space allocated by the system for the original application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)

Abstract

本发明公开了一种Android应用多开实现方法、移动终端及存储介质，其中，方法包括：在移动终端原应用启动之后，进行克隆应用的启动；在框架层为克隆应用提供注册和存储路径；所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。本发明Android应用多开实现方法、移动终端及存储介质由于采用通过在移动终端上设置的宿主内操作，实现同一应用程序的多开，从框架层实现，对应用和系统来说都不会造成混乱或误导崩溃，可以安全的实现多开应用程序，而不会影响原本应用的执行，其实现更为简单可行。

Description

一种Android应用多开实现方法、移动终端及存储介质 技术领域
本发明涉及移动通讯技术领域，尤其涉及的是一种Android应用多开实现方法、移动终端及存储介质。
背景技术
现有技术的Android系统不支持同一个应用的多个实例，也就是说一个应用一般只能开一个实例，打开一个应用程序界面。但是随着现在人们需求日益增长和变化，特别是对社交中必要的多身份需求，对移动终端系统(Android)社交软件不能同时登陆多个账号/开多个实例而不满意。该种需求在中国地区的“微信”社交软件上的表现得尤为突出。
为了解决这个需求，网络上涌现出许多给予用户在特定情况下完成同一应用的多个实例的实现方法，甚至于移动终端开发商在开发Android系统时已经把该需求纳入了基本市场需求中。但目前尚没有特别有效的实现方式来解决上述问题。
以“微信”为例，在数年前Android4.0的时代时，用户可以下载该应用解包后，对AndroidManifest.xml里修改应用的包名，然后再二次打包上第三方/自用签名，安装在系统上后可以多打开一个“微信”应用。但由于不同包名有不同签名，所以在系统来看两个包是不同的应用，从而达到“同一应用”而“两个实例”的效果。
但随后微信在后来的版本中，会在运行时动态查看自己的包名是否被篡改，如果被篡改、或者签名与原始签名不符，则会拒绝启动。可见，该方法根本不具有通用性。
因此，现有技术存在缺陷，有待改进与发展。
发明内容
本发明的目的在于提供一种Android应用多开实现方法、移动终端及存 储介质，针对现有技术的上述缺陷，能够实现同一应用的两个以上实例的打开，从而做到方便多个用户在同一系统中不同实例的应用中登录使用。
本发明解决技术问题所采用的技术方案如下：
一种Android应用多开实现方法，其中，包括：
在移动终端原应用启动之后，进行克隆应用的启动；
在框架层为克隆应用提供注册和存储路径；
所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。
所述Android应用多开实现方法，其中，所述克隆应用启动之前还包括：
原应用作为宿主启动时都须向用户申请权限；若用户拒绝赋予其中某个权限，则宿主拒绝启动。
所述Android应用多开实现方法，其中，所述克隆应用的启动包括：
所述克隆应用的存储路径以原应用为宿主，存储到系统为原应用分配的存储空间内。
所述Android应用多开实现方法，其中，所述克隆应用的启动包括：
在系统为原应用分配的存储空间对应的存储路径的目录下创建子目录，作为分配给克隆应用的储存空间。
所述Android应用多开实现方法，其中，所述克隆应用的启动包括事件Activity、服务Service、内容提供器ContentProvider和接收器Receiver的对应从远程服务端的请求启动。
所述Android应用多开实现方法，其中，所述克隆应用的启动包括步骤：
在Android的原应用宿主中声明若干个事件Activity、服务Service的占位符，以供系统AMS识别；
用户在宿主内每新建一个克隆应用，宿主会通过PMS去遍历该应用下AndroidManifest.xml声明过的组件等信息，把信息缓存起来；
在Android系统上进行克隆应用的启动和运行。
所述Android应用多开实现方法，其中，所述克隆应用的启动还包括：
宿主请求启动一个空服务；
除了宿主本身，服务后台开启对于对应的一个新的进程。
一种移动终端，其中，包括处理器，以及与所述处理器连接的存储器，
所述存储器存储有Android应用多开实现处理程序，该Android应用多开实现处理程序被所述处理器执行时实现：
在移动终端原应用启动之后，进行克隆应用的启动；
在框架层为克隆应用提供注册和存储路径；
所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。
所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
所述克隆应用启动之前还包括：
原应用作为宿主启动时都须向用户申请权限；若用户拒绝赋予其中某个权限，则宿主拒绝启动。
所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
所述克隆应用的存储路径以原应用为宿主，存储到系统为原应用分配的存储空间内。
所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
在系统为原应用分配的存储空间对应的存储路径的目录下创建子目录，作为分配给克隆应用的储存空间。
所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
所述克隆应用的启动包括事件Activity、服务Service、内容提供器ContentProvider和接收器Receiver的对应从远程服务端的请求启动。
所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
在Android的原应用宿主中声明若干个事件Activity、服务Service的占位符，以供系统AMS识别；
用户在宿主内每新建一个克隆应用，宿主会通过PMS去遍历该应用下AndroidManifest.xml声明过的组件等信息，把信息缓存起来；
在Android系统上进行克隆应用的启动和运行。
所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
宿主请求启动一个空服务；
除了宿主本身，服务后台开启对于对应的一个新的进程。
一种存储介质，其中，所述存储介质存储有Android应用多开实现处理程序，该Android应用多开实现处理程序被处理器执行时实现所述Android应用多开实现方法的步骤。
本发明所提供的一种Android应用多开实现方法、移动终端及存储介质，由于采用通过在移动终端上设置的宿主内操作，实现同一应用程序的多开，从框架层实现，对应用和系统来说都不会造成混乱或误导崩溃，可以安全的实现多开应用程序，而不会影响原本应用的执行，其实现更为简单可行。
附图说明
图1是本发明Android应用多开实现方法较佳实施例安装时适配片段示意图；
图2是本发明Android应用多开实现方法较佳实施例调用时适配片段示意图；
图3为本发明Android应用多开实现方法及移动终端较佳实施例中的AMS里记录的四大组件信息示意图；
图4为本发明Android应用多开实现方法较佳实施例的启动时事件Activity与AMS交互的流程示意图；
图5为本发明所述Android应用多开实现方法另一较佳实施例的原始应用live的桌面入口Intent处理流程示意图；
图6为本发明所述Android应用多开实现方法另一较佳实施例的克隆应用启动流程示意图；
图7是本发明所述Android应用多开实现方法中克隆应用在宿主内启动的原理示意图；
图8为本发明执行所述Android应用多开实现方法的移动终端系统示意图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明Android应用多开实现方法、移动终端及存储介质利用应用多实例兼容性做法，通过修改框架层代码(在数据包管理服务PackageMangerService、事件管理服务ActivityManagerService等系统服务中增加多实例兼容代码)，支持特定几个应用(微信、QQ、陌陌、淘宝等)的双实例。位于系统开发层的手机开发商可以对Android系统进行定制化开发，在具有系统特权的前提下，要特定实现应用双实例兼容是可以实现，把应用的第二个实例称为“克隆”或“克隆应用”。
以下是本发明具体实施例的实现方式，首先需要适配包名以及组件声明，这种做法与用户自己通过更改应用的包来达到“修改包名”的做法不同。本发明方法旨在安装阶段对“克隆应用”进行包括包名、AndroidManifest内的一系列声明进行适配，从而在最初的阶段上把克隆应用伪装成一个真实存在的另一个应用。
本发明所述Android应用多开实现方法，其包括步骤：在移动终端原应用启动之后，进行克隆应用的启动；在框架层为克隆应用提供注册和存储路径；所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。
以微信应用为例对本发明的实现过程做具体的说明：
首先对内容提供器ContentProvider的适配，如图1所示，展示了该方案的对包含ContentProvider的应用的一个安装适配过程(仅示出的是一个适配片段，并非完整方案)。数据包管理服务PackageManagerService在安装应用的时候，会对声明在AndroidManifest.xml上的内容进行注册。由于原本已经存在了com.tencent.mm包名，所以这里需要对包名进行修改。但是仅仅修改包名还不够，如果应用内部存在有ContentProvider，那么还需要对 他们的uri(统一资源标识符，Uniform Resource Identifier)进行一个适配，否则克隆应用在请求的时候会请求到原本应用的ContentProvider，而非克隆应用自身的ContentProvider，最终会造成：如果该ContentProvider是导出的且是允许所有应用自由访问的，那么克隆应用将会访问到错误的数据，导致内部逻辑错误；如果该ContentProvider是非导出的，那么克隆应用将会崩溃。
对于克隆应用，对于访问自身的ContentProvider应该进行适配，大致的调用时示意图如图2所示。以上只是展示了本发明技术方案的一小部分内容，本发明实现还有需要对其他组件进行适配。其核心思路在于Hook本地的请求适配成另一个代理请求，然后在服务端里对这类请求做适当的特殊处理(适配得恰当可以直接按照原生流程)，再转交给原流程处理。
有关路径的适配：这些路径包括图片的路径等等。这部分的适配比较繁琐，因为在应用内部一直认为他们是原生的路径，所以在加载图片、动态库的时候不做处理的话很可能就加载到了原应用的目录下，由于权限不对，会直接导致应用崩溃。所以有关图片路径等的适配尤为重要。
本发明方法还需要动态修改包名，这种做法与现有技术的通过更改应用的包来达到“修改包名”的做法不同。用户自身修改应用包是对应用本身的“篡改”，是一种非法行为。这种行为可以在应用内部识别出来，可行性很低。而本发明在框架层上动态修改来自克隆应用的“包名”，实则是通过在框架层上的修改“骗过”原生Android系统代码，让其以为这个请求是来自一个独立的应用，从而达到克隆应用的“合法化”。
由于是在框架层做出的修改，所以应用本身也不可能做出什么有效的判断来甄别自己到底是否是“克隆”。因此，本发明方法是可行的，只不过实现的时候需要特别注意所有对包名引用的关键代码均需做一层处理，如果漏掉一个处理，那么很可能就会导致克隆应用的崩溃，甚至影响正常应用的处理。
由于本发明方法只对特定的应用或特殊标记的应用进行“克隆”，代码层面就算有所遗漏也不会造成对正常应用的冲击，所以该方案风险较低，更适合于应用到实际程序中。
本发明所述Android应用多开实现方法、移动终端及存储介质实现方案中，不需要对系统进行订制修改，不需要系统干预和root权限，对原应用 的兼容性高。由于不需要对系统框架进行任何修改(修改的是应用程序运行的框架层)，所以它的风险是很小的，基本上把所有风险都控制在自己的应用里了。本发明说明书中下文会对“双开/多开”出来的应用，区别于原有的应用，记为“克隆引用”。下文对“双开”的描述都可以扩展为“多开”，即支持克隆出两个或两个以上的应用。至于具体到底克隆多少个完全取决于策略以及需求，在本发明技术方案中并不存在技术上的难点。
本发明Android应用多开实现方法、移动终端及存储介质实现基于应用实现的双开方案，是一个基于Android的应用。称原应用为“宿主”，原因是克隆应用的大部分数据、组件细节均由“宿主”负责适配或提供。对于Android系统，宿主的包名定为“com.tct.parallel”。具体实现细节如下：
从数据实现角度，克隆应用的数据需要储存，首先需要为克隆应用分配空间，适配其自身储存数据的需求。普通应用安装到Android系统后，系统会为其分配基于其应用的储存空间，一般在路径：/data/data/[应用唯一包名]/。在创建克隆应用的初期，移动终端会在自己的储存目录里为其开辟独立的储存空间，以微信作为原应用，基于宿主克隆应用的举例是：/data/data/com.tct.parallel/com.tencent.mm-1/0。
在移动终端自身的储存路径为：/data/data/com.tct.parallel，该路径为系统给原应用分配的路径。本发明实现方案在该目录下面会继续创建出格式为“[原应用唯一包名]-[第N个多开实例]/[用户id]”的目录，分配给克隆应用作为其独立的储存空间。例如第一个微信的克隆应用即为com.tencent.mm-1，第二个则为com.tencent.mm-2，第N个则为com.tencent.mm-N。用户Id，一般不支持多用户的Android上就直接是0，如果支持其他用户，例如Guest，那会多创建1、2等。
对克隆应用的数据安全性实现，本发明技术方案中，只要终端设备没有被root，数据储存是在被系统机制保护下的，通过简单地adb等工具无法窥窃，安全性可以得到系统机制的保障。adb的全称为Android Debug Bridge，就是起到调试桥的作用。借助adb工具，可以管理设备或手机模拟器的状态，还可以进行很多手机操作，如安装软件、系统升级、运行shell命令等等。简而言说，adb就是连接Android手机与PC端的桥梁，可以让用户在电脑上对手机进行全面的操作。
本发明实现方法在克隆应用上支持Android四大组件的方法是，由于已 知在服务进程(服务端)里的事件管理服务ActivityManagerService保存着所有Android应用的四大组件包括事件Activity、服务Service、内容提供器ContentProvider和接收器Receiver的记录信息，如图3所示是AMS(ActivityManagerService)里记录的四大组件信息示例，这是它作为一个服务端的职责。当任何一个应用请求相关组件的时候，本地会向服务端发起一个请求，去添加、查询、修改或删除某些自己有权限访问的组件。
当本发明技术方案在桌面启动一个应用的时候，大致经历如图4所示的以下流程：由本地对应APP的框架向AMS注册APP，AMS确认ok后，所述框架触发克隆事件发生。
本发明所述克隆应用对原始应用代码的使用，通过以下步骤实现：安装一个应用，应用的apk(AndroidPackage的缩写，即Android安装包)等文件会拷贝到/data/app/[应用唯一包名]/下，有JNI(Java Native Interface)的还会解压出动态库。本地应用是没有权限访问/data/app下的文件的，那么它要如何加载它们的apk来构建克隆应用呢？
本发明所述Android应用多开实现方法、移动终端及存储介质在AMS注册克隆应用的四大组件信息，不能简单地遍历把原应用的AndroidManifest.xml上声明的组件信息，然后把遍历结果原原本本地再往ActivityManagerService上再注册一次，因为这样子就会造成重复注册(冲突)，导致组件注册失败。如果AMS返回请求失败，那么尽管克隆应用的进程起来了，相应的组件也不会被载入初始化，依然会造成克隆应用的不成功。
本发明方法须将静态注册的Receiver实现被AMS的调用，当应用没有启动的时候，他们的Receiver没有注册到AMS中，所以无法接收到它们所需要的广播。为了解决这个问题，本发明应用在安装的时候，声明在AndroidManifest.xml的组件都会在系统启动之后注册到AMS之中。
本发明技术方案中，服务端里有两个重要的服务，分别是数据包管理服务PackageManagerService(PMS)以及事件管理服务ActivityManagerService(AMS)。本发明用原始应用Line作为讲述本发明方法的一较佳实例。首先启动一个原始应用的Line，本发明移动终端在PackageManagerService的resolveIntent上进行判断，观察其调用的细节，如图6所示，实现原始应用Line的桌面入口Intent处理过程，其中， “jp.naver.line.android.activity.SplashActivity”是“jp.naver.line.android”的一个桌面入口。具体实现的代码细节如下：
Figure PCTCN2018107691-appb-000001
如图6所示，其原始应用的处理程序中，箭头1：当在桌面点击Line(唯一包名是“jp.naver.line.android”)的时候，桌面应用向AMS请求要启动一个jp.naver.line.android应用下的入口SplashActivity；箭头2：AMS复制出进程并让jp.naver.line.android应用初始化自己的SplashActivity；箭头3：jp.naver.line.android应用的SplashActivity完成处理，向AMS报告SplashActivity已经初始化完毕，AMS正式把应用记录保存起来。
本发明实现方法中，克隆应用的流程上比较复杂。首先，宿主的构成如下：
在AndroidManifest.xml中，会声明使用到Android系统上所有可以申明的权限。由于所有的克隆应用都寄生在宿主里，如果不首先声明并成功申请到所有权限，那么克隆应用就不可能得到对应的权限运行它自身的业务逻辑。所以在这一步，本发明方案会申请完对应版本的Android系统上所有可以申请的权限。
其次，声明若干个具体示例如各100个Activity、Service的占位符。所谓的“占位符”，实际上是向Android系统注册了100个Activity，但实际在宿主里，这些对应的Activity并不实际完成具体的逻辑，它们仅仅是占用了一个位置，让系统AMS可以识别。之所以要注册100个，旨在可以同时支持(约)100个克隆应用/进程，实际上根据具体的应用需要，可以设置不同数量的克隆应用占位符。
在本发明Android系统中，宿主每次启动都会向用户申请权限，确保所有权限申请成功。若用户拒绝赋予其中某一个权限，则宿主拒绝启动，直接退出。这样是为保证克隆应用的能够运行，防止因为权限导致的克隆应用运行故障。
用户在宿主内每新建一个克隆应用，宿主会通过PMS去遍历该应用下AndroidManifest.xml声明过的组件等信息，把信息缓存起来。具体地，宿主会请求启动一个“空服务”。所谓的“空服务”，就是一个“壳”，实际上“壳”本身不完成任何实际意义的事情，它仅仅是占位，转嫁请求的一个Shell。除了宿主本身，服务后台又开启一个新的进程。本发明以再启动一个克隆应用的Line来做对比，来解释说明如何实现克隆应用启动到正确的原应用代码入口，如下所示：
Figure PCTCN2018107691-appb-000002
如图6所示，是本发明实现所述克隆应用被启动起来的具体过程示意图，其中：
图中的箭头1：当在桌面点击“克隆应用Line”的时候，桌面应用向AMS请求要启动一个宿主com.tct.multiagent下的service.ServiceProxy$P0服务；箭头2：服务代理P0向AMS报告初始化完毕；箭头3：服务代理P0向AMS请求启动应用内的client.ActivityProxy$P0活动代理P0；箭头4、5：AMS发通知让活动代理P0启动，活动代理P0通过获取先前缓存起来的jp.naver.line.android.SplashActivity的启动信息后内部实际上去加载并启动jp.naver.line.android.SplashActivity。
对于系统(服务端)来说，一切都只是启动了一个com.tct.multiagent下client.ActivityProxy$P0Activity，但实际上对终端用户来说，它启动的是Line，具体实现的代码如下所示，是宿主处理Activity的关键代码：
Figure PCTCN2018107691-appb-000003
从上图可以看到mType以及resolvedType里记录了图6里记载的关键信息。由于它指定了将要启动的Activity的类，宿主内部实现把这个信息传入到事件代理ActivityProxy，然后让代理去通过从原应用AndroidManifest.xml中遍历出来的启动方式启动该应用App Launcher。
如上所示的实现代码中，mClass指示了宿主内部的一个ActivityProxy$P0类，它是一个Activity的代理。至于P0，实际上是指定到了一个宿主内一个进程“P0”，如下所示，可以看到这个代理的声明：
Figure PCTCN2018107691-appb-000004
进程P0实际上是克隆应用Line的一个“宿主”，其内部组件均寄宿于P0。如果这时候再启动另一个克隆应用，那么进程将会是P1，以此类推，可以启动更多的克隆应用。但是等进程初始化完毕后，名字会变为原始应用的进程名，例如Line就会是“jp.naver.line.android”。
在本发明客户端，有两个关键的接口层，一个就是ActivityThread以及本地的ActivityManagerNative。对克隆应用组件Activity的处理如下所示， 其中显示了断在P0宿主进程里的Handler.dispatchMessage，可以看见mComponent字段是“com.tct.multiagent.client.proxy.ActivityProxy$P0”：
Figure PCTCN2018107691-appb-000005
到这步为止，两端的信息还是一致的。当流程再往下走，进入mCallback.handleMessage的时候，发现进入的不是ActivityThread.H.handleMessage，而是进入了另一个来自宿主内的对象内的方法。如下所示为Handler的dispatchMessage流程：
Figure PCTCN2018107691-appb-000006
流程进入了com.tct.multiagent的n类handleMessage方法是：宿主进程通过JAVA的反射机制，把原本是保存着android.os框架代码的Handler对象替换成了自己实现的Handler，来过滤所有消息的调用，来处理原本android.os框架要处理的事情。换句话来说，就是在宿主进程里，本发明通过JAVA的反射机制用自己实现的克隆应用框架，替换原本的android.os框架。本发明实现方法通过公共接口Context.createPackageContext()创建了jp.naver.line.android的上下文ContextImpl。这个关键的Context包含了代码、资源等等所有的jp.naver.line.android包内实现。然后利用这个Context随即可以创建出jp.naver.line.android的SplashActivity。
如下所示msg.obj.applicationInfo对象里的字段，发现它已经被替换成了如下的字段，其中的mComponent被替换成了jp.naver.line.android，因此原本还是宿主内部“com.tct.multiagent.client.proxy.ActivityProxy$P0”的调用现在变成了“jp.naver.line.android/jp.naver.line.android.activity.SplashActivity”的调用：
Figure PCTCN2018107691-appb-000007
本发明通过替换ActivityThread的mCallback，利用了服务端与客户端两端之间信息不完成对称的方式启动了克隆应用的Activity。
如图7所示，本发明克隆应用在宿主内的启动原理示意图，其中示例LBE Host(LBE：Local bio-emulator，是发明人开发时候的代号)表示宿主进程，它向AMS发起一个请求，请求启动“自己的”一个Activity A (ActivityProxy$P0)。由于声明了A组件需要独立运行于一个进程中，所以AMS内部会向Zygote请求一个新进程P0。待P0启动完毕且返回成功后，AMS会发送指令让P0调起宿主内部的一个ActivityA(ActivityProxy$P0)。
这时候P0掌握了主动权后，原本应该去调起Activity A(ActivityProxy$P0)的，但是由于本地客户端框架层中关键的mCallback被宿主给替换了，流程又转入宿主自己的方法流程里。宿主的P0进程通过修改从服务端发过来的请求(修改Intent等信息)，让它去启动目标的“jp.naver.line.android/jp.naver.line.android.activity.SplashActivity”。最后，客户端向服务端AMS报告启动成功。
所以对于AMS来说，它记录到的是P0里有一个ActivityProxy$P0组件，但实际上P0它启动的却是“jp.naver.line.android/jp.naver.line.android.activity.SplashActivity”。
由此实际上可以推断得出“LoadAPKB”这步骤后，在“Launch B.C”之前的操作，应该与ActivityThread.performLaunchActivity相类似。以上说明了本发明如何在AMS注册克隆应用的四大组件信息的过程，以及其中有关Activity的处理。宿主根本没有向AMS注册有关克隆应用中的Activity，它采用了替换(Hook)的方法修改本地客户端，让其调用了另一个Activity，因此，对系统和应用来说，都难于区别克隆应用与原先的应用，因而可以实现克隆应用的多开运行。
本发明方法还通过createPackageContext载入代码实现引用到原始应用的代码，如下所示，宿主调用了createPackageContext去创建Line的上下文：
Figure PCTCN2018107691-appb-000008
通过查阅API文档可知，该接口甚至可以不用任何权限就可以加载其他应用的APK包，包括加载其代码段，只要有了对方的Context就可以。
如上所示，是本发明createPackageContext会把LoadedApk放入mPackages里的代码实现，其中Context就在LoadedApk对象里。以后只要创建有关“jp.naver.line.android”相关的组件，直接调用Android公开接口即可，其流程自动会在mPackages里找到对应LoadedApk创建对应的组件。
为实现克隆应用数据的独立存储，本发明方法还通过修改dataDir达到数据储存与原始应用独立，如下所示，修改后的msg.obj对象示意图：
Figure PCTCN2018107691-appb-000009
其中在前述Handler的dispatchMessage流程代码中所示mComponent被替换成了jp.naver.line.android流程中，通过JAVA的反射机制把msg.obj.dataDir修改成“/data/data/com.tct.multiagent-1/0/jp.naver.line.android”而并非原始应用的“/data/data/jp.naver.line.android”。本发明实现方法通过修改这个字段，来达到把克隆应用的数据保存在自己目录下的目的。
同时，本发明还在本地调取Activity、Service、Broadcast、ContentProvier四个组件；本发明宿主进程还得在前述Handler的dispatchMessage流程代码所示中，把原本的ActivityMangerNative、PackageManagerNative等多个关键服务的本地代理，替换成本发明自己要实现的代理。本发明自己要实现的本地关键服务代理做法如下代码段所示，可以用来实现自定义的本地 ActivityManagerNative组件，诸如PackageManagerNative等多个关键服务的本地代理全部按照该方式实现，然后替换本地的原来的对应服务，并且把原来的代理保存起来——因为它们其中保存着与真正的服务进程内的AMS、PMS等服务通信的重要Binder渠道，本发明需要用这些Binder与服务端进行通信：
Figure PCTCN2018107691-appb-000010
本发明其他3个组件的实现过程与上述事件处理的流程基本同理，这里不再赘述。
本发明实现所述Android应用多开实现方法的移动终端，如图8所示，包括处理器10，以及与所述处理器10连接的存储器20，所述存储器20存储有Android应用多开实现处理程序，该Android应用多开实现处理程序被所述处理器10执行时实现以下步骤：在移动终端原应用启动之后，进行克隆应用的启动；在框架层为克隆应用提供注册和存储路径；所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。
所述Android应用多开实现处理程序被所述处理器执行时，还实现以下步骤：所述克隆应用启动之前还包括，原应用作为宿主启动时都须向用户申请权限；若用户拒绝赋予其中某个权限，则宿主拒绝启动。所述Android应用多开实现处理程序被所述处理器执行时，还实现以下步骤：所述克隆应用的储路径以原应用为宿主，存储到系统为原应用分配的存储空间内。
本发明还公开了一种存储介质，所述存储介质存储有Android应用多开实现处理程序，该Android应用多开实现处理程序被处理器执行时实现前述所述Android应用多开实现方法。
本发明所述Android应用多开实现方法、移动终端及存储介质通过在移动终端上设置的宿主内操作，实现同一应用程序的多开，从框架层实现，对应用和系统来说都不会造成混乱或误导崩溃，可以安全的实现多开程序， 并不会影响原本应用的执行，其实现更为简单可行。
应当理解的是，本发明的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。

Claims (20)

  1. 一种Android应用多开实现方法，其中，包括：
    在移动终端原应用启动之后，进行克隆应用的启动；
    在框架层为克隆应用提供注册和存储路径；
    所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。
  2. 根据权利要求1所述Android应用多开实现方法，其中，所述克隆应用启动之前还包括：
    原应用作为宿主启动时都须向用户申请权限；若用户拒绝赋予其中某个权限，则宿主拒绝启动。
  3. 根据权利要求1所述Android应用多开实现方法，其中，所述克隆应用的启动包括：
    所述克隆应用的存储路径以原应用为宿主，存储到系统为原应用分配的存储空间内。
  4. 根据权利要求3所述Android应用多开实现方法，其中，所述克隆应用的启动包括：
    在系统为原应用分配的存储空间对应的存储路径的目录下创建子目录，作为分配给克隆应用的储存空间。
  5. 根据权利要求3所述Android应用多开实现方法，其中，所述克隆应用的启动包括事件Activity、服务Service、内容提供器ContentProvider和接收器Receiver的对应从远程服务端的请求启动。
  6. 根据权利要求5所述Android应用多开实现方法，其中，所述克隆应用的启动包括：
    在Android的原应用宿主中声明若干个事件Activity、服务Service的占位符，以供系统AMS识别；
    用户在宿主内每新建一个克隆应用，宿主会通过PMS去遍历该应用下AndroidManifest.xml声明过的组件等信息，把信息缓存起来；
    在Android系统上进行克隆应用的启动和运行。
  7. 根据权利要求6所述Android应用多开实现方法，其中，所述克隆应用的启动还包括：
    宿主请求启动一个空服务；
    除了宿主本身，服务后台开启对于对应的一个新的进程。
  8. 一种移动终端，其中，包括处理器，以及与所述处理器连接的存储器，
    所述存储器存储有Android应用多开实现处理程序，该Android应用多开实现处理程序被所述处理器执行时实现：
    在移动终端原应用启动之后，进行克隆应用的启动；
    在框架层为克隆应用提供注册和存储路径；
    所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。
  9. 根据权利要求8所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    所述克隆应用启动之前还包括：
    原应用作为宿主启动时都须向用户申请权限；若用户拒绝赋予其中某个权限，则宿主拒绝启动。
  10. 根据权利要求8所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    所述克隆应用的存储路径以原应用为宿主，存储到系统为原应用分配的存储空间内。
  11. 根据权利要求10所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    在系统为原应用分配的存储空间对应的存储路径的目录下创建子目录，作为分配给克隆应用的储存空间。
  12. 根据权利要求10所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    所述克隆应用的启动包括事件Activity、服务Service、内容提供器ContentProvider和接收器Receiver的对应从远程服务端的请求启动。
  13. 根据权利要求12所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    在Android的原应用宿主中声明若干个事件Activity、服务Service的占位符，以供系统AMS识别；
    用户在宿主内每新建一个克隆应用，宿主会通过PMS去遍历该应用下 AndroidManifest.xml声明过的组件等信息，把信息缓存起来；
    在Android系统上进行克隆应用的启动和运行。
  14. 根据权利要求13所述移动终端，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    宿主请求启动一个空服务；
    除了宿主本身，服务后台开启对于对应的一个新的进程。
  15. 一种存储介质，其中，所述存储介质存储有Android应用多开实现处理程序，该Android应用多开实现处理程序被处理器执行时实现：
    在移动终端原应用启动之后，进行克隆应用的启动；
    在框架层为克隆应用提供注册和存储路径；
    所述克隆应用在原应用作为宿主内与远端服务器进行信息沟通。
  16. 根据权利要求15所述存储介质，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    所述克隆应用启动之前还包括：
    原应用作为宿主启动时都须向用户申请权限；若用户拒绝赋予其中某个权限，则宿主拒绝启动。
  17. 根据权利要求15所述存储介质，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    所述克隆应用的存储路径以原应用为宿主，存储到系统为原应用分配的存储空间内。
  18. 根据权利要求17所述存储介质，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    所述克隆应用的启动包括事件Activity、服务Service、内容提供器ContentProvider和接收器Receiver的对应从远程服务端的请求启动。
  19. 根据权利要求18所述存储介质，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    在Android的原应用宿主中声明若干个事件Activity、服务Service的占位符，以供系统AMS识别；
    用户在宿主内每新建一个克隆应用，宿主会通过PMS去遍历该应用下AndroidManifest.xml声明过的组件等信息，把信息缓存起来；
    在Android系统上进行克隆应用的启动和运行。
  20. 根据权利要求19所述存储介质，其中，所述Android应用多开实现处理程序被所述处理器执行时，还实现：
    宿主请求启动一个空服务；
    除了宿主本身，服务后台开启对于对应的一个新的进程。
PCT/CN2018/107691 2017-09-26 2018-09-26 一种Android应用多开实现方法、移动终端及存储介质 WO2019062771A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710879961.8A CN107665302B (zh) 2017-09-26 2017-09-26 一种Android应用多开实现方法、移动终端及存储介质
CN201710879961.8 2017-09-26

Publications (1)

Publication Number Publication Date
WO2019062771A1 true WO2019062771A1 (zh) 2019-04-04

Family

ID=61097619

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/107691 WO2019062771A1 (zh) 2017-09-26 2018-09-26 一种Android应用多开实现方法、移动终端及存储介质

Country Status (2)

Country Link
CN (1) CN107665302B (zh)
WO (1) WO2019062771A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112379968A (zh) * 2020-11-13 2021-02-19 网易（杭州）网络有限公司 应用多开的方法、装置、设备及存储介质
CN117093351A (zh) * 2023-10-13 2023-11-21 亿咖通(湖北)技术有限公司 应用多开方法、装置、计算机设备以及存储介质
CN117234543A (zh) * 2023-11-10 2023-12-15 亿咖通(湖北)技术有限公司 基于多开应用运行的应用安装方法、装置以及设备

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107665302B (zh) * 2017-09-26 2022-01-11 惠州Tcl移动通信有限公司 一种Android应用多开实现方法、移动终端及存储介质
CN112825072B (zh) * 2019-11-21 2023-02-17 青岛海信移动通信技术股份有限公司 通信终端以及数据共享方法
CN112836208A (zh) * 2019-11-25 2021-05-25 英业达科技有限公司 同一用户的多重登入系统及其方法
CN113051122B (zh) * 2019-12-26 2023-09-15 百度在线网络技术（北京）有限公司 性能数据获取方法、装置、电子设备和介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130239086A1 (en) * 2012-03-09 2013-09-12 User-Friendly Phone Book, L.L.C. Mobile application generator
CN106445647A (zh) * 2016-10-10 2017-02-22 广东欧珀移动通信有限公司 多开应用的数据操作方法、装置及移动终端
CN106445612A (zh) * 2016-10-10 2017-02-22 广东欧珀移动通信有限公司 一种开启应用的方法、装置及移动终端
CN107665302A (zh) * 2017-09-26 2018-02-06 惠州Tcl移动通信有限公司 一种Android应用多开实现方法、移动终端及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104199734B (zh) * 2014-09-12 2017-11-14 上海斐讯数据通信技术有限公司 一种基于安卓智能终端的应用程序多开管理方法和系统
CN105224322B (zh) * 2015-09-25 2018-10-16 维沃移动通信有限公司 一种应用程序的分身方法及终端
CN105843668B (zh) * 2016-03-11 2019-11-15 北京奇虎科技有限公司 派生进程驻存方法、派生程序生成方法及相应的装置
CN106066803B (zh) * 2016-05-25 2019-12-13 北京奇虎科技有限公司 应用程序运行控制的方法及装置
CN106227588A (zh) * 2016-07-21 2016-12-14 北京奇虎科技有限公司 一种多实例对象的创建方法、装置及移动终端

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130239086A1 (en) * 2012-03-09 2013-09-12 User-Friendly Phone Book, L.L.C. Mobile application generator
CN106445647A (zh) * 2016-10-10 2017-02-22 广东欧珀移动通信有限公司 多开应用的数据操作方法、装置及移动终端
CN106445612A (zh) * 2016-10-10 2017-02-22 广东欧珀移动通信有限公司 一种开启应用的方法、装置及移动终端
CN107665302A (zh) * 2017-09-26 2018-02-06 惠州Tcl移动通信有限公司 一种Android应用多开实现方法、移动终端及存储介质

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112379968A (zh) * 2020-11-13 2021-02-19 网易（杭州）网络有限公司 应用多开的方法、装置、设备及存储介质
CN117093351A (zh) * 2023-10-13 2023-11-21 亿咖通(湖北)技术有限公司 应用多开方法、装置、计算机设备以及存储介质
CN117093351B (zh) * 2023-10-13 2024-02-02 亿咖通(湖北)技术有限公司 应用多开方法、装置、计算机设备以及存储介质
CN117234543A (zh) * 2023-11-10 2023-12-15 亿咖通(湖北)技术有限公司 基于多开应用运行的应用安装方法、装置以及设备
CN117234543B (zh) * 2023-11-10 2024-02-13 亿咖通(湖北)技术有限公司 基于多开应用运行的应用安装方法、装置以及设备

Also Published As

Publication number Publication date
CN107665302B (zh) 2022-01-11
CN107665302A (zh) 2018-02-06

Similar Documents

Publication Publication Date Title
WO2019062771A1 (zh) 一种Android应用多开实现方法、移动终端及存储介质
US9916475B2 (en) Programmable interface for extending security of application-based operating system
US10503564B2 (en) Method and apparatus for handling security of an application and its extension
US9208328B2 (en) Security system and method for operating systems
Heuser et al. {ASM}: a programmable interface for extending android security
Jeon et al. Dr. Android and Mr. Hide: fine-grained permissions in android applications
US8074231B2 (en) Configuration of isolated extensions and device drivers
JP5021475B2 (ja) コンテキストポリシー制御によるアプリケーション間の関連付けの制御のためのシステムおよび方法
US20180253329A1 (en) Systems and Methods for Auditing a Virtual Machine
US20150332043A1 (en) Application analysis system for electronic devices
US10114932B2 (en) Adapting a mobile application to a partitioned environment
WO2015183456A1 (en) Consistent extension points to allow an extension to extend functionality of an application to another application
JP2008524686A (ja) コンピュータ装置においてアプリケーションを保守する方法
US10171502B2 (en) Managed applications
US7444624B2 (en) Method for the secure interpretation of programs in electronic devices
US11269700B2 (en) System call interception for file providers
WO2014056425A1 (zh) 应用程序整合方法及装置
CN107636667B (zh) 在设备中创建多个工作空间的系统及方法
Chuang et al. Digital right management and software protection on Android phones
JP2013196310A (ja) アプリケーション解析装置、アプリケーション解析システム、およびプログラム
Wu et al. A context-aware kernel ipc firewall for android
JP4638505B2 (ja) 電子デバイス内の安全なプログラム解釈方法
WO2018023368A1 (en) Enhanced security using scripting language-based hypervisor
Cai et al. Enforcing ACL access control on android platform
Pettersen et al. Dynamically Loading Mobile/Cloud Assemblies

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18862883

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18862883

Country of ref document: EP

Kind code of ref document: A1