You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.
Well, as the name says, the clone can be an instance of a subclass. It also doesn't check whether the object is Cloneable. It's used for XResources (see XposedBridge changes).
I'm calling dvmSetFinalizable because dvmCloneObject calls it. I don't think it is needed where I use it at the moment, but it was easier to keep the methods the same than having to investigate later.
If this isn't available on GB, use whatever dvmCloneObject uses. I would be very careful about gDvm though, it's a huge structure, so there is a bigger risk that the offsets become invalid between the versions or if a vendor added one element to it.
Got it. After looking into the codes, I have found that for cloning object, the c++ version of dalvik use dvmSetFinalizable, while the c version of dalvik use dvmHeapAddRefToLargeTable via flags.
https://github.com/rovo89/Xposed/blob/b1f0/xposed.cpp#L706
In b1f0, you introduce de_robv_android_xposed_XposedBridge_cloneToSubclassNative, what's the difference with dvmCloneObject?
Currently, I'm intened to use
dvmHeapAddRefToLargeTable(&gDvm.gcHeap->finalizableRefs, copy)
. Do you have some test method for me to test this method?The text was updated successfully, but these errors were encountered: