> App應用雙開（多開）技術
微信分身，微信多開，微信雙開- http://blog.csdn.net/yunajie/article/details/50894488
Android應用分身功能介紹- http://blog.csdn.net/maetelibom/article/details/52084085

-- LBE平行空間和市面上的其他應用雙開app有本質區別，其他方案是通過改包名、改Framework等非常粗糙的方式達到目的，而 LBE是讓應用在自己開的虛擬機里面運行，單獨的進程單獨的環境來實現雙開；而機友精靈是把應用通過復制改代碼重新生成APK文件來實現的；MIUI8。LBE平行空間的底層是一個完整的虛擬化引擎：MultiDroid更準確的說，MultiDroid并不是硬件虛擬化或OS虛擬化 (譬如VMware, Xen, KVM)，它也不是應用層虛擬化（譬如XenApp, Wine)，MultiDroid更類似容器(Container).LBE出品的平行空間（Parallel Space）。
? 現階段，已有許多安全公司研發出了較早時期的App雙開技術：LBE平行空間、卓盟雙開助手、金山開小號，但是它們的原理無一例外的是插件化。

?- LBE MultiDroid的關鍵技術有：
? 1. Framework層的虛擬實現在Android環境中，每個應用在運行時都需要和Android framework打交道。Android系統的System-Server進程提供了大部分的系統API。 應用程序通過Binder IPC調用系統API。LBE之前在安全大師產品中，也就是通過對System-Server的hook來實現主動防御和權限管理，但MultiDroid在設計之初的一個最重要的目標就是不需要root權限，從而不能通過hook的方式來實現虛擬化。為此，我們需要自行實現一套完整的System-Server API，這就是MultiDroid的核心，工作量非常大，更麻煩的是，我們的設計目標是支持所有Android 4.0以上版本，而每個版本的Framework實現又千差萬別……
? 2. 文件系統虛擬化程序在運行的時候，會加載文件系統上的程序指令和程序數據。要建立虛擬的應用程序運行環境，需要模擬一個獨立的文件系統，在這個獨立的文件系統中，再針對不同的虛擬應用的主目錄進行區分和權限控制；
? 3. Android系統組件管理一個Android應用基本上是由Android四大組件（Activity， Service， Broadcast Receiver，Content Provider）構成。在Android環境中，System-Server和應用通過進程間通信交互，Android系統負責了四大組件的管理，包括創建，激活，銷毀等。MultiDroid引擎實現了一套Android組件管理系統，用來模擬系統對Android組件的管理。每個運行在虛擬環境中的應用，會把自己的組件注冊給MultiDroid引擎，由MultiDroid引擎負責各個組件的生命周期維護；
? 4. 應用進程管理Android本身在應用和進程之間做了隔離，應用幾乎不需要感知進程的存在，只需要關注應用自身的四大組件。但是應用本身還是需要在Dalvik進程中運行。虛擬環境中的進程仍然是一個Dalvik進程， MultiDroid引擎負責了虛擬應用進程的創建，進程ID的分配，進程的銷毀等；
??
?- MultiDroid的未來發展：
?目前的MultiDroid引擎已經相當完善，可以很好的運行市面上的絕大部分App，而且在耗電和內存使用上都做了非常多的優化，但這只是起步，我們期望下一版的MultiDroid引擎將會從某種程度上改變Android本身的生態環境和使用體驗，譬如支持整個虛擬環境的快照和恢復，發燒友就不用為了嘗試各種新鮮玩法而反復刷機了，當然，還有虛擬環境內應用數據的云備份，類似iCloud，雖然有Android廠商也支持類似功能，但跨廠商的設備同步目前還沒有；再譬如代碼動態優化，雖然目前的MultiDroid引擎并沒有性能問題，但我們希望可以借鑒ART的做法，通過在虛擬環境中的代碼預優化和動態轉換，來提升應用加載速度；同時，我們已經找到了一個辦法把具有某些特征的dex字節碼片段在虛擬環境中轉為native指令來運行，性能的提升非常夸張。總之，MultiDroid打開了一個盒子，里面有無窮可能。

-- 實現雙開（多開）的幾種方案：
?1.靜態修改APK包名，然后重打包
作為廠商肯定不推薦這個方式拉，可能存在法律風險
?2.動態修改APK包名
對原生代碼修改量小，兼容性差，部分APP需單獨適配
?3.動態修改進程的實例
對原生代碼修改量大，兼容性一般，可能會導致系統一些亂七八糟的BUG
?4.通過多用戶機制實現
MIUI的實現機制，更多的是修改多用戶在相關的代碼
?5.通過動態加載（運行）的機制來實現（LBE的平行空間）
作為第三方開發者，不能ROOT，不能修改系統源碼，逼的LBE用這種方式，也是難為他們了

-- 不管是平行空間還是雙開助手還是其他的類似實現，都離不開Hook技術。幾種Hook技術：
1.Binder Hook，DroidPlugin；
2.Handler Hook，去看看ActivityThread.mH是干啥的就知道了；
3.Native Hook。就是文件系統Hook，比如：
?open("/data/data/${pkg}/", flag) ==>open("/data/data/http://com.lbe.xxx/yy/${pkg}/", flag); LBE用的是inline hook

-- 企業空間和原本用戶空間
? 使用Android原生接口，實現“應用雙開”，源代碼可以從 https://github.com/bobohuang1985/android-utils-api 下載，具體代碼位置在utils.bobo.com.boboutils.MultiApp包內，

-- APK多開原理- https://segmentfault.com/a/1190000005139577
?packageName 在代碼中使用，通常在 AndroidManifest.xml中指定，applicationId 則只是用于程序的標識，通常在 build.gradle 中指定。這樣有一個好處，假如你想發布一個免費版，一個收費版，你只需要在 build.gradle 中把applicationId 后面加上免費版的后綴包名（如".free"），收費版加上收費版的后綴即可，而不需要修改你的其他代碼。?
　　你可以通過使用以下的 Gradle DSL 方法，為不同的flavors和構建類型修改你的應用程序的 ApplicationId：
?productFlavors {
? ? ? ? pro {
? ? ? ? ? ? applicationId = "com.example.my.pkg.pro"
? ? ? ? }
? ? ? ? free {
? ? ? ? ? ? applicationId = "com.example.my.pkg.free"
? ? ? ? }
? ? }
? ? buildTypes {
? ? ? ? debug {
? ? ? ? ? ? applicationIdSuffix ".debug"
? ? ? ? }
? ? }
?改掉主配置文件中的包名和smali文件相關的包名后，雖然可以安裝，但是并不能運行，最直接的一點就是改掉了主配置文件的包名，那些像百度地圖，極光推送，環信聊天等第三方SDK就都不能用了，因為這些都是在開發者中心注冊ID的，和包名是綁定的，所以用ApkTool工具反編譯的APK并不是雙開實現的工具。

-- 三星MY KNOX不僅僅是一個軟件這么簡單，它具有兩大特性。首先就是安全沙盒機制，My Knox功能可以為需要安全保護的APP應用（如：微信、支付寶等）和信息（如：通訊錄、相冊等）提供一個獨立的、與外界隔離的空間，從使用場景來看就是應用雙開；其次是Root操作熔斷機制，如果有人企圖非法獲取系統管理權，一旦觸發Root操作，手機主板上的Knox“保險絲”會物理熔斷，且不可逆轉。

> DroidBox安卓沙盒
Android 雙開沙箱 VirtualApp 源碼分析（三）App 啟動- http://blog.csdn.net/ganyao939543405/article/details/76177392
針對Android沙盒的“中間APP攻擊”- http://blog.csdn.net/qq_27446553/article/details/56674931

? App沙盒/雙開技術是現在仍處于發育時期的未成熟技術，它的目標是使一個未安裝的APK直接運行在一個容器當中，與外部環境部分隔離（或完全隔離），處于沙盒之中的App無法覺察到自己的環境與普通運行時的環境有所不同，并能夠與沙盒之中的其它App進行交互。概念上來講，它類似Docker。
??
-- App沙盒的難點主要有：
?1.欺騙 App，讓其認為自己運行在正常的環境中。
?2.完整得驅動四大組件。
?3.讓組件的進程分布與實際完全一致。
?4.隨時與處在沙盒外部的容器和宿主(Host)進行同步的遠程通信。
?5.兼容不同系統API版本的設備。
?6.SD卡隔離(Native IO Redirect)。
?

總結

以上是生活随笔為你收集整理的App应用双开技术，Android沙盒的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。