EDIT #2: I've found the root cause of the problem: see here.
Hey there, the XperiFirm dev here.
I've seen people that use the official Lollipop on their Xperia devices, yet they also use the "Fix Lollipop Memory Leak" Xposed module.
Let's make something clear: Xperia Lollipop does NOT have a memory leak.
Sony made sure to include the memory leak fix built in (the exact fix that the Xposed module offers) for their Lollipop releases. The Xposed module is pointless.
Basically the Xposed module replaces the AOSP function with exactly the same function but with this additional "release()" line. As you can see in the attached screenshot, Xperia already has this line included.
Hope that stops you from using the highly unstable alpha of Xposed Framework for a module that is totally useless for your Xperia device.
EDIT: please just ignore the rest of the post, I misunderstood the
Fix Lollipop Memory Leak bit.
The purpose of xposed-sonyfix is not to fix a memory leak, but to
prevent bootloops on the 2nd and subsequent boots with the framework installed. I have no idea whether that's still required with xposed-sdk21-arm-20150426.zip, but it was sure as hell a problem with xposed-arm-20150308.zip.
With stock Z3 LP firmware and xposed-arm-20150308.zip - even without the xposed apk! - one needed to wipe /cache before every boot, and wait until all the apps were compiled again. Not too convenient.
@ondrejvaroscak discovered that if the open file limits were increased during boot, the bootloop didn't happen anymore; and another dude did a .zip (actually 3
) that increased the file limits on boot.
At that stage, I stepped in, with the goal to provide a complete solution that would 1) get rid of the bootloop, and 2) when boot had finished, attempt to restore the on-init default values to zygote's process tree.
All the discussion about leaks is pure speculation.
Here I summarized that - the relevant bits are
And there's one more thing. We like to blame Xposed (or at least you seem to
), but we don't have a clue whether it's Xposed or Android itself. This just occured to me - they recently released 5.1.1, which reportedly
fixed some memory leaks that have been in since 5.0.0 - I wonder if memory's all that 5.0.2's leaking... What about handles? What if Xposed LP only works on other platforms because the kernel devels of those devices had figured **** might hit the fan, so they increased the kernel limits to accomodate a leaky Android?... What if Sony's stock app_process does some crazy Sony-specific things to avoid said leaks, or clean up after them, which Xposed's doesn't?... That wouldn't break SU, which only hooks the file entry, but would break Xposed, which replaces app_process altogether...
and
...and yeah, that's obviously the thing to do. If we talk to the Xposed devs and say, "it doesn't work on our device", I think a "so what?" answer would be actually appropriate. That's why I haven't approached them do date; when I do, I mean to be able to say, "this is what seems to be wrong, this is my analysis, here are my logs; can I help you (help me
) in any other way?"
That said, bootloops are a
fact with stock LP firmware, on the stock kernel, and xposed-arm-20150308.zip. I'm actually cleaning the phone ATM in order to have a clean testbed for checking whether xposed-sdk21-arm-20150426.zip is different in this respect.
This is not a blame game. It's sound engineering on my behalf, attempting to fix an observed, and rather inconvenient, problem - which yes, is either caused by, or triggered by, running Xposed Framework (binary version 20150308), on Sony LP devices with
a lot of .apk's installed - I expect if either one of these 3 conditions isn't met, the problem doesn't occur. It can't be observed, for instance, on debloated ROMs.
