Let's port Xposed to N #230
Comments
The actual implementation is the smallest part of developing Xposed. Getting the knowledge about how the ART compiler and runtime works and finding ways to integrate Xposed with maximum compatiblity is the most time-consuming and complex part. Books could be written about the small, yet very important details that have to be considered. Sometimes when I understood how a particular implementation works and which tricks they're using, I indeed think I should write something up about it, but that would take me even more time (which I currently don't have). |
@Revo89 its very good to see that you are still pursuing beloved xposed, thank you for that. Are you also looking into developing xposed for Android O too? Maybe Like Marshmallow some things even made it possible to integrate Xposed in a more elegant way in Android O and a workaround for JIT & AOT?! (We could only hope for) We know your time is so little and there are many difficulties but seeing you replying replying gives xposed fan lots of hope |
@rovo89 I just got my hands dirty. Please take a look at my copy: https://github.com/abforce/xposed_art_n. Everything works smoothly and flawlessly but XPrivacy. It breaks the boot process. I've posted an issue there along with its logcat output. I'm heading toward building a built-in enabled Xposed firmware, so I was just porting commits relating to hooking methods not those relating to recompiling. See diff to get a clear insight on what I've done. |
@abforce very interesting job. |
Sure, please ask them on the issue page. |
@abforce or may call you AliReza Aint you the person who started that project? i have OnePlust 3T and a Samsung Note4 n910c, unfortunately at the moment i use my OP3T for business purposes so i can not do testings on it , and there is no Android N for my Note4. but when your project gets stable enough and one made those ART modification to the N Rom i will flash it on my OP3T. |
Congrats ;) Unfortunately, I can't review your changes, it's just too much and I don't remember all those details where I deviated from simply porting the Marshmallow changes and which additional changes were required to make it reliable (i.e. to ensure that the hooks are called even with compiler optimizations). As you already mentioned, your changes could only work for ROMs compiled from scratch with Xposed already active, so people should understand that this won't work (at least not reliably) on their stock or otherwise pre-compiled ROMs. |
@rovo89 Thanks for your prompt feedbacks. Surprisingly by porting M changes to N everything works well, As I traced down the error, the problem seems to be related to visiting roots when GC marks objects. Moving form M to N, just one of your commits I couldn't port directly, that of Also enabling hook resources causes the problem when GC runs, are you sure your modified
No, that's not too much. Please only review those parts relating to visiting roots. I'll heartily appreciate your effort. There's lots of people waiting for my custom ROM. Just a moment please stop playing with your puppies and give them a rest. They really do need it. |
Congrats, this indeed seems just great Either way i may give a look at building aosp with "patched" art |
Thanks to @abforce and BlackSoulxxx |
haha yup :) |
https://forum.xda-developers.com/xposed/xposed-android-nougat-sdk-25-arm64-t3639221 Sorry Revo, they beat you to the punch. |
Be polite people. |
@newstart Don't they use rovo's codes? It can't exist without his work on Marshmallow, I don't think that's a punch. |
Here are more builds, more stable.... surprisingly. https://drive.google.com/drive/folders/0B5ePoKNP9UFtWGRVN2JlazhYU2c |
Exactly |
From my experience, I can tell you that it's indeed not that hard to get the basics done, but it takes a hell lot of time for the details. It's like the 80-20 rule, except that it's more like 95-5 or so. The hooking approach I have designed for the previous releases is rather stable and can be applied for newer releases as well. I assume you needed most of the time to check all the places where Besides that, you took an approach where hooks would only work properly for ROMs which are entirely compiled from scratch. On stock ROMs and even most custom ROMs (that didn't include your port while building) as well as for any apps the device might have compiled before. So you'd have to start all over again with a wiped device running a special ROM. If not, then optimizations (e.g. inlining) might prevent a method from being called at all, and hence hooks wouldn't work. The worst thing about this is that the exact behavior would depend on the ROM, or even how the user uses the device (now that apps are compiled based on profiles). Modules would fail randomly and the module developers would be wondering what they did wrong (answer: nothing). If not all of the prerequisites are fulfilled, it's a pretty unreliable API. Imagine Google published an update where the
Their code is @abforce's port, with all the limitations I listed above. 🙄 It doesn't make sense at all to publish flashable ZIPs with this, as the port is only intended for recompiling a ROM from scratch. I just checked my Git log and I had the basic hooking (as in this port) ready in October. Since then, I have worked on removing the limitations. To make it more reliable on pre-compiled ROMs, I could have ported the recompiling part as well, however that's still not ideal. As explained somewhere above, we have JIT now, which allows us to keep all the optimizations, only invalidating (and possibly recompiling) the methods which are directly affected by hooking. This is quite challenging, as it's more than just copy & paste. And until this isn't done, I won't publish anything. 9 months for that (until now) is really a long time, I know, but hey, it's my spare time and e.g. due to moving to a new apartment, I couldn't work on Xposed for several months (!) at all, and had only very limited time otherwise.
I just commented on your diff. There's no real difference in my code for these two methods, so you'll have to debug it yourself. I know this can be hard, as the real culprit can sometimes be in a totally different place. Even if it ends up to be a single character that needs to be changed, you can easily spend dozens of hours on debugging one issue. That said - if you're seriously interested in contributing, this might be a good challenge. 😉 |
Totally agree with rovo, from my test, my module (which hooks many fundamental classes like android.view.ViewGroup) would fail randomly with many native crashes from the hooked app. Although we can install it (even flash it) with a not pre-odexed rom and cleaning every partition to clear odex files, it is not stable at all and cannot be used for production environment. |
Rovo of course Im totally with you on this. Also prebuilt stuff its not the way, I'll be doing (even with all the limitations ) patch our ROM source, that's really the only way to at least debug and not just flash an miracle prebuilt stuff.zip We all appreciate your work rovo, and I know how long this stuff can takes when done on our limited free Tim |
And just to add to my reply above: Imagine I published my current WIP now. I bet that some people would publish it as their build, without any warnings that it's incomplete and not intended to be used productively. |
Surely ! |
Can confirm this. I build with full dexpreopt and dexpreopt_pic and the unofficial xposed causes multiple soft-reboots repeatedly even when modules are not enabled on my ROM |
Just saw xda's "Purify" and there's an higher BS there.. |
And there is an XDA News article backed it up... |
Yup top notch ... |
Slightly offtopic, but I was also interested in hacking around to get Xposed to work on Nougat. The only thing that put me off is the huge resource requirements for the dev environment. 100 GB+ of disk space/bandwidth and large RAM requirements just to get AOSP to compile! Is there a better way to work with android/ART? How do you guys do it? @rovo89 @abforce |
Its the normal environment to get aosp compiled .. You could get away with just 8gb Ram a fairly CPU and ofc the HDD space (ssd even better) if you don't have those requirements, maybe search for a cloud/build server solution |
Yep, that quite unfortunate, but that's because AOSP source is so huge. The only hint I can share is to initialize like this:
With the Besides that, if you're planning to check out multiple versions of AOSP (e.g. Lollipop, Marshmallow and Nougat), it helps to symlink the ".repo/project-objects" folder to a shared place before fetching the source code. |
So... if the Xposed code is compiled with the ROM, is it stable without any said limitations? |
I did the following to fix it>
fixed, no problems, Superkernel Android 7.0 stock, S7 Edge |
People! Please keep calm and wait and don't try to leave chatty comments. Please do leave your knowledge not pointless comments. My ART copy works well (actually thank to @rovo89's work for Android M, I've done nothing), but there's random crashes when GC runs. I think there's a problem in memory allocation on the heap. I'm sure enough to say that hooking functionality works pretty good. So we should move our attentions to where memories are allocated. After reviewing stacktraces all crashes somehow is related to CMS (Concurrent Mark and Sweep) GC algorithm. I'm not saying that the CMS itself needs modification, no no. I just think that methods called For example, the following methods could be the main culprit because of which we're receiving SIGABRT and SIGSEGV. Please inspect them elaborately.
If anyone has a deep insight on how GC works in ART, his/her input will be welcomed. If no one has, just get your hands dirty, dig down until you reach the first commit of ART. |
@abforce the visitRoots issues seems to be fixed with @ahronshor commit: abforce/xposed_art_n@94ba5a5 But I'm still getting a few cases of mark/sweep crashes. |
@abforce I also fixed resources hooking for Android 7.1 on OOS, based on the same solution of @ahronshor ahronshor/XposedBridge@0aec3f9#diff-a34e2ca228dbe63004fcc32e3bf8581a , you need to look for the correct signature of the method "getOrCreateResources", at least OOS does not have any signature of the method that have the resourcekey as a second parameter, you need to do something like this: |
I can't believe it fixed the problem. I'm more thinking that it just suppressed the problem preventing us from booting the device, not fixing the problem in an ideal way. Since we've got little or no knowledge of ART internals, our works little or more can be thought of as trials and errors. That being said, fixing a problem may cause another issue elsewhere.
What do you think about them? |
I agree, i'm not sure if it's an ideal solution, but at least it didn't cause any other visible issue yet.
I got that crash twice last week, i don't know how to reproduce it again, it crashed here https://github.com/abforce/xposed_art_n/blob/master/runtime/gc/collector/mark_sweep.cc#L415 but i have no idea why, the stack trace does not tell much about when it started. |
@ahronshor @wanam |
@C3C0 will you make a pull request? |
@avently |
@rovo89 What's up man? Is it WIP or zzZ? Is it needed to get my hands dirty for the second time? 😆 |
;-) |
var answer = prompt('Has anyone told you today that loves you?');
if (answer === 'no') {
for(var i = 0; i < 1000; i++) {
console.log('I love you!');
}
} |
I love you |
Now, answer = yes |
Hey rovo |
Yes, there are thousands of superusers waiting patiently for your release of Xposed for Android N |
Rovo just close this... Just spammers here. People no ETA, when its done its done! |
@rovo89 What prevent you from starting community funding for Xposed? This project got a real value for many people and that value can be expressed in money. I'd love to donate to the project to ensure you can focus on xposed for N, instead of doing anything else to earn money to pay your bills. |
And what would he do after he finished porting xposed, the donations
stopped and he has no job as he quit it for xposed?
Not a really good suggestion
…On 21 Aug 2017 13:38, "Marcin Orlowski" ***@***.***> wrote:
@rovo89 <https://github.com/rovo89> What prevent you from starting
community funding for Xposed? This project got a real value for many people
and that value can be expressed in money. I'd love to donate to the project
to ensure you can focus on xposed for N, instead of doing anything else to
earn money to pay your bills.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#230 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQVFTj5O08kFgZe69WUE7Hh_PBvqg_eOks5saTsUgaJpZM4OMIXh>
.
|
The same thing he would do after completing any other project. Focus on something else. |
so much spam from people who don't know any shit. |
Yup... |
@amakuramio There's no @rovo89's crowdfunded project alive AFAIR to donate to, so stop playing smartass rich dude while you in fact got not much to say. It's none of your business what people do with own money. FYI: I personally agree to rovo89's statement about the current outbreak of N's "compatible" builds, so I will not sponsor these forks. But I would rovo89 given the way to do that. |
?? Why are you quoting me on this? That didn't come from me lol Either way @rovo89 again just close this... Too many spammers here |
@abforce Let's port Xposed to O 😂. O Will be released with the eclipse lol. |
This thread really doesn't bring any progress, so I'll close it. And no, I wouldn't give up my job just to spend more time on Xposed, it's still just a hobby. 😀 |
No worries Rovo, abforce has given us what we want. Take all the time in the world. |
@rovo89 We know that you're too busy to implement Xposed for N. No problem, just enjoy your life. But let us to do the job. You've got a high level of knowledge how stuff works on Art, and how Xposed should be implemented. but you've no time to do this.
On the other hand, there's lots of people been waiting for it, and of course they have much free time to do this great job, however they don't have a minimum and required insight on how just Art works and how it should be changed.
So, an idea would be sharing the knowledge by you, implementing it by us. Unfortunately Art doesn't come with a minimum and acceptable documentation, which drastically slows down the research on how stuff works. So, if you consider taking your time to write a brief and techninal writeup on the how, we'll have a good chance to keep the Xposed up to date with the latest release of Android.
What do you think? Do you have time for this or would prefer to still enjoy your life (and possibly playing with your puppies)?
Thanks in advance.
The text was updated successfully, but these errors were encountered: