VIEW PATH ANALYSIS - CAN DOUBLECLONER ADOPT CMasterCloner'S UI MODEL?
Analysis only. No files changed.
CORRECTION FIRST: THE VIEW PATH IS THE HOST'S OWN UI, NOT THE CLONE'S
- HomeActivity and RouterActivity both extend m1 (HomeActivity.smali:2, RouterActivity.smali:2).
- The o10 subclasses are j41, g80, gq, l30, m80, t1 - host screens, not cloned apps.
- The clone proxies FIEL$A* -> vz1 -> Activity have NO onCreate, setContentView, addView,
o10 or dm1. vz1 only stores an int and calls Activity.<init>.
So RouterActivity -> m1 -> o10 -> View is how CMasterCloner draws ITS OWN screens.
The clone's proxy activities are empty; their content is attached by the native engine
(dm1 / o0O00OOO). The View path does not render arbitrary cloned apps.
1) WHAT MUST CHANGE IN OUR CODE
Our CloneActivity is already the right shape: a real, empty Activity. The problem is
entirely in CloneRunner.
Current code -> change needed:
- CloneRunner.startActivity0 (CloneRunner.kt:199) calls instr.newActivity(...) (:221)
-> stop creating a second Activity.
- attachMethod() (:607) / setFieldsDirectly() (:684) attach the target
-> not needed if you only need its view.
- reveal() (:767) / makeVisible() (:827) attach the target's own window
-> replace with: add the target's decorView (or android.R.id.content) to the host's
android.R.id.content ViewGroup.
- CloneActivity has no content view except the error TextView (:327)
-> set a real ViewGroup content view in onCreate.
- Lifecycle calls callActivityOnStart/Resume (:317, :330)
-> drive them from the host's lifecycle, not from a fake transaction.
- SandboxLaunchTransactionSwap -> remove from DoubleClonerApp.onCreate.
Minimal change:
1. CloneActivity.onCreate -> setContentView(FrameLayout(this).apply { id = CONTENT_ID }).
2. CloneRunner.startActivity0 -> still newActivity to run the target's onCreate, but do
NOT attach/makeVisible. Take activity.window.decorView, set its layoutParams to
MATCH_PARENT/MATCH_PARENT, and hostContent.addView(decor).
3. Drive activity.onStart/onResume/onPause/onStop/onDestroy from CloneActivity lifecycle.
BUT: the target's onCreate calls setContentView on its own PhoneWindow. That still needs
an ActivityThread/ActivityRecord or setContentView can fail. Our current attach sets the
token but not the full record. This is the part the native engine solves.
2) FILES THAT BECOME UNUSED
- sandbox/SandboxLaunchTransactionSwap.kt -> unused
- sandbox/SandboxClientTransactionReplayer.kt -> unused
- sandbox/SandboxTransactionItems.kt -> unused
- sandbox/SandboxActivityThreadHook.kt -> likely unused, but CANNOT VERIFY; may still be
needed to make setContentView work
- CloneRunner.attachMethod() / setFieldsDirectly() / reveal() / makeVisible()
-> removed/replaced
- CloneRunner stub-swap branch -> unused
Still needed:
- ProxyHosts.kt
- SandboxProxyActivity.kt (host Activity)
- SandboxEngineOrchestrator.kt
- CloneClassLoader.kt
- CloneContext.kt
- CloneComponentHost.kt
- SandboxActivityManagerHook.kt
- SandboxPackageManagerHook.kt
- VirtualSpaceEngine.kt
3) CAN OUR CLASS LOADER AND SLOT MAPPING FEED THE VIEW PATH?
Partly - and not the same thing as the reference.
- Class loader: CloneClassLoader.kt can load the target APK and instantiate its Activity.
So it can feed a "reparent the decor" path.
- Slot mapping: ProxyHosts.kt + SandboxProxyActivityBase provide a real host Activity in
:agentN and bind the native storage sandbox. That works.
- Missing piece: the target's Activity is a real Android Activity. To become a View, you
must run its onCreate and reparent its decorView. That needs an Activity-like
environment (ActivityThread/ActivityRecord, window token, WindowManager). Our class
loader cannot turn an arbitrary target Activity into an o10-style view object; that is
what the reference's native engine does.
- Reference reality: the clone's proxy activities (vz1) are empty and the native engine
attaches the view. The o10 View path is only the host's own UI. So the reference's
clone rendering depends on the native engine; the o10 path does not.
CANNOT VERIFY WITHOUT A DEVICE:
- Whether reparenting decorView into the host content view works reliably across apps.
- Whether setContentView succeeds without a real ActivityThread record.
- Whether window insets, input, dialogs and WindowManager calls survive the reparent.
- Whether SandboxActivityThreadHook can be removed or is still required to fake the record.