Jump to content
Sign in to follow this  
david

XPrivacyLua on the Pro1

Recommended Posts

Has anyone managed to get XPrivacyLua running on the Pro1, under Magisk, with EdXposed?  I tried yesterday and got in a non-boot state and ended up doing a Factory Reset.  I will probably try again, but if someone has succeeded and has the steps, that would be great.

Share this post


Link to post
Share on other sites
50 minutes ago, daniel.schaaaf said:

https://community.fxtec.com/topic/2755-riru-core-edxposed-magisk/?tab=comments#comment-43838

😉

Which EdXposed did you install, SandHook or Yahfa? I never tried any Xposed modules with Yahfa, because EdXposed Manager only works with SandHook. That said, XPrivacyLUA runs great with SandHook and EdXposed Manager.

I've never done anything with Xposed/EdXposed before.  This is my first attempt (on any phone). 

I installed the Yahfa drivers, because I thought I read that was more stable.  And the instructions I was using to get XPrivacyLUA installed listed both, and didn't say anything about EdXposed manager not working with Yahfa??

This is one of the set of instructions I was looking at.  I can't find the other one right now.  And I know it says Android 10, but I think it seemed the same for other things I read about 9.

https://android.stackexchange.com/questions/218179/how-to-install-edxposed-on-android-10-without-triggering-safety-net

That one is a bit hard to follow with all the updates and strikethroughs.  I believe I restarted after installing Yahfa, and that is when the phone wouldn't boot again.

Share this post


Link to post
Share on other sites

We can take this over to that other thread.  When I first saw it before, I didn't know what riru-core was, so it didn't stick in my memory that it might be related to what I was trying to do here.  And when I saw all the wording about crashing left and right, I figured I wasn't going to mess with it.  But then I found out that the apps aren't acting the same way in Pie with contact permissions restricted like they did on Cyanogenmod with Privacy Guard.  I searched and found XPrivacyLua, and figured I'd try to get it working.

See you over in the other topic.

Share this post


Link to post
Share on other sites

The instructions in the "Riru Core EdXposed Magisk" thread to install Riru and EdXposed are very simple, and you can't break anything either. I too read that Yahfa was supposed to be more stable and installed the Magisk module first. But EdXposed Manager would just tell me that there was no EdXposed framework installed. Therefore I recommended SandHook in the other thread.

Share this post


Link to post
Share on other sites
2 hours ago, daniel.schaaaf said:

The instructions in the "Riru Core EdXposed Magisk" thread to install Riru and EdXposed are very simple, and you can't break anything either. I too read that Yahfa was supposed to be more stable and installed the Magisk module first. But EdXposed Manager would just tell me that there was no EdXposed framework installed. Therefore I recommended SandHook in the other thread.

I need to find a way to backup some apps that Titanium Backup failed to back up for me (and system settings that google failed on) before I attempt it again.  I think your number 1 way doesn't work to undo a failed boot, because that is what I was stuck in.  However, I've read in another thread how to get out of that situation without wiping /data, so I guess I can do that if needed.  But just in case that doesn't work for me, I'm going to hold off until I have a complete way to back up my apps and settings.

Thanks for posting the info in the other thread and replying in this one.

You are doing all of these things through Magisk, and in its "downloads" method, or are you downloading these things directly and pointing Magisk at them?  The information I read said that you needed to install the hook drivers separately, not through Magisk, so that is what I did with Yahfa and that is when I couldn't boot.

Share this post


Link to post
Share on other sites
18 minutes ago, david said:

I think your number 1 way doesn't work to undo a failed boot, because that is what I was stuck in.  However, I've read in another thread how to get out of that situation without wiping /data, so I guess I can do that if needed.  But just in case that doesn't work for me, I'm going to hold off until I have a complete way to back up my apps and settings.

Oh, that surprises me. Flashing back the original unpatched boot.img does disable Magisk and thereby Riru completely.

Good luck with getting your data back. If you manage, please tell us what you did 😉

 

To answer your other question: I installed Riru Core and EdXposed from within Magisk Manager, not from external sources.

Share this post


Link to post
Share on other sites
7 hours ago, daniel.schaaaf said:

Oh, that surprises me. Flashing back the original unpatched boot.img does disable Magisk and thereby Riru completely.

Yes, it definitely does that.  But with Magisk disabled, then I didn't have root. Without root, I couldn't go in and remove the modules.

Catch 22.

If I had a backup of /data *before* the modules were installed, and a way to replace it, without root in Android, then that would have been another option.  But without TWRP being able to decrypt /data yet, that wasn't possible.  I've toyed around with the idea of removing encryption and then using the TWRP that does exist, since it should be able to read data then. 

But getting TWRP and Magisk into the boot image is going to require doing things I've never toyed with before.  *And* (and this is important), if I were to get into a situation where I have to disable Magisk and boot with it disabled, then the system is going to re-assert itself and encrypt the darn /data all over again.  Of course, if I am careful enough to take a full backup of /data before getting in that state, then I can revert back to that.  But chances are I will forget to do it before installing some Magisk module, get stuck, and then loose whatever changes I had between the previous /data and the version I lost.  

And then there is the fact that TWRP doesn't backup the media folder.  So that has to be solved for somehow.  Either by sucking the data out of that when in TWRP, through ADB, or by renaming the media folder before TWRP does the backup, so that it *does* include it in the backup and then remembering what things to rename back afterward .

Those are the fun options *after* we get a TWRP that can read /data.  But we don't have that yet, so none of that matters right now.

7 hours ago, daniel.schaaaf said:

Good luck with getting your data back. If you manage, please tell us what you did 😉

@shubell gets credit for posting the solution.

Normally it would require patching the boot image, which is something I haven't done yet (other than having Magisk do it) to include the pieces to disable Magisk's modules, without disabling root.  However, @shubell provided an image where he did this already, for the 20200106 build.  So if you trust him, you can use that. :-)  

He posted his solution almost exactly when I was just finishing up restoring everything after doing a factory reset.  It wasn't the end of the world.  I just had to restore from Titanium Backup, which I did take right before installing the hook drivers.  But there are things that aren't included in that (WhatsApp and Viber media files, sysem settings, newer apps that wouldn't restore, like SwiftKeys, etc.), so I had to do a lot of manual work to get back to where I was before getting stuck.

I need to get my backup and restore system working (always relied on nandroid backups before, which is much simpler), so that I can get back to my good state if something goes horribly wrong.  In theory, with the solution @shubell posted, that won't be needed often, but I need to have it for worst case scenarios.

7 hours ago, daniel.schaaaf said:

To answer your other question: I installed Riru Core and EdXposed from within Magisk Manager, not from external sources.

But what about the hook drivers?  (SandHook)  That is the step where I got stuck.  It was before I got to EdXposed Manager.

Also, I can't remember if it was SandHook or Yahfa, but someone reported a bug recently that it heats up their phone.  Did you notice anything like that?

Share this post


Link to post
Share on other sites
9 hours ago, david said:

But what about the hook drivers?  (SandHook)  That is the step where I got stuck.  It was before I got to EdXposed Manager.

Also, I can't remember if it was SandHook or Yahfa, but someone reported a bug recently that it heats up their phone.  Did you notice anything like that?

Like I wrote before, I installed "Riru - Core (v19.7)" and "Riru - EdXposed (v0.4.5.1_beta4463 SandHook)" from the Magisk repo. I rebooted after installing Riru Core, and I rebooted again after installing EdXposed. Then I installed EdXposed Manager.

 

And yes, we are very screwed without TWRP with working decryption. We just have to wait until we get a working version. I don't know if it will be possible to install TWRP and Magisk at the same time. But at least we can flash TWRP, do stuff, and flash Magisk again.

Regarding boot halts, you have to try really hard to get the Pro1 to boot again. I just installed "Wifi QR Code Creator Xposed" and got stuck in a boot halt again. For some reason, flashing magisk_patched.img did not help like it did before. Flashing the original boot image worked and I was able to uninstall "Wifi QR Code Creator Xposed". To my surprise, the Pro1 would still not boot with magisk_patched.img flashed back. I got my phone to boot again by flashing the original boot.img, uninstalling some other Xposed modules that were disabled, and flashing magisk_patched.img. This doesn't make sense, because a disabled Xposed module should not get any more disabled by uninstalling it... but it worked! 🙄

  • Sad 1

Share this post


Link to post
Share on other sites
13 hours ago, daniel.schaaaf said:

Like I wrote before, I installed "Riru - Core (v19.7)" and "Riru - EdXposed (v0.4.5.1_beta4463 SandHook)" from the Magisk repo. I rebooted after installing Riru Core, and I rebooted again after installing EdXposed. Then I installed EdXposed Manager.

Oh, I didn't know you could install the driver and EdXposed together.  And the sources I read said to not install it from the Magisk repository.  So much for those instructions.  Lol

13 hours ago, daniel.schaaaf said:

And yes, we are very screwed without TWRP with working decryption. We just have to wait until we get a working version. I don't know if it will be possible to install TWRP and Magisk at the same time. But at least we can flash TWRP, do stuff, and flash Magisk again.

Regarding boot halts, you have to try really hard to get the Pro1 to boot again. I just installed "Wifi QR Code Creator Xposed" and got stuck in a boot halt again. For some reason, flashing magisk_patched.img did not help like it did before. Flashing the original boot image worked and I was able to uninstall "Wifi QR Code Creator Xposed". To my surprise, the Pro1 would still not boot with magisk_patched.img flashed back. I got my phone to boot again by flashing the original boot.img, uninstalling some other Xposed modules that were disabled, and flashing magisk_patched.img. This doesn't make sense, because a disabled Xposed module should not get any more disabled by uninstalling it... but it worked! 🙄

How did you uninstall the modules without root?

Share this post


Link to post
Share on other sites
4 hours ago, david said:

Oh, I didn't know you could install the driver and EdXposed together.  And the sources I read said to not install it from the Magisk repository.  So much for those instructions.  Lol

How did you uninstall the modules without root?

Not to install from the Magisk repo might apply to other phones, or the Magisk modules have been fixed since the installation instructions were posted.

Uninstalling Modules only works for Xposed, because Xposed modules are ordinary APKs. It would be cool though, if Magisk and Xposed would let users disable modules without root, and simply defer disabling until when root is available again.

Share this post


Link to post
Share on other sites
6 hours ago, daniel.schaaaf said:

Not to install from the Magisk repo might apply to other phones, or the Magisk modules have been fixed since the installation instructions were posted.

I thought about them being fixed since the instructions were posted, but the versions hadn't changed.  It doesn't matter, since you got them to work on the Pro1.

6 hours ago, daniel.schaaaf said:

Uninstalling Modules only works for Xposed, because Xposed modules are ordinary APKs. It would be cool though, if Magisk and Xposed would let users disable modules without root, and simply defer disabling until when root is available again.

Oh, so the distinction is that you can uninstall Xposed modules without root, since they are APKs, but you can't do that with EdXposed, because the aren't normally installed apps?  So, in this case, you were working with an Xposed module, not EdXposed?

Share this post


Link to post
Share on other sites
14 hours ago, david said:

Oh, so the distinction is that you can uninstall Xposed modules without root, since they are APKs, but you can't do that with EdXposed, because the aren't normally installed apps?  So, in this case, you were working with an Xposed module, not EdXposed?

Yes and no 🙂

Xposed modules are ordinary APKs that can be uninstalled. Some modules are missing a main activity, which makes them "invisible" to your launcher, but they can be uninstalled from within Android settings.

EdXposed Manager and the original Xposed Manager let you disable modules without uninstalling them ... as long as the framework is active. The EdXposed Manager might also let you uninstall modules by tapping on the modules name/icon. Although I am unsure if this works without root.

In essence, "Method 1" from my thread simply lets you uninstall Xposed "modules" that block the boot process. "Method 2" lets you disable Xposed modules, and it lets you disable Magisk modules or the Xposed/Magisk framework itself ...

Share this post


Link to post
Share on other sites
5 hours ago, daniel.schaaaf said:

Yes and no 🙂

Xposed modules are ordinary APKs that can be uninstalled. Some modules are missing a main activity, which makes them "invisible" to your launcher, but they can be uninstalled from within Android settings.

EdXposed Manager and the original Xposed Manager let you disable modules without uninstalling them ... as long as the framework is active. The EdXposed Manager might also let you uninstall modules by tapping on the modules name/icon. Although I am unsure if this works without root.

In essence, "Method 1" from my thread simply lets you uninstall Xposed "modules" that block the boot process. "Method 2" lets you disable Xposed modules, and it lets you disable Magisk modules or the Xposed/Magisk framework itself ...

Is EdExposed active when you don't have root?

I was unable to get to any screens where I could see any modules to disable/uninstall when I flashed back the stock boot image.  However, in my case, it was the hook drivers, and those were installed by downloading a separate file and then pointing at it with Magisk manager, so that may have been the difference. 

Others online also said that it is a catch 22 when you can't boot due to Magisk modules failing, and you have to wipe the phone, because you need root to do it and you don't have root without Magisk being installed.  That is why that work around exists to install Magisk core, which gives you root, but does not enable any Magisk modules:

https://forum.xda-developers.com/pixel-4-xl/how-to/magisk-modules-disabler-booting-magisk-t3990557

I am not seeing how you are running EdXposed manager (a Magisk module), in order to disable EdXposed modules that are preventing boot, without having Magisk running.

 

Edited by david

Share this post


Link to post
Share on other sites

Yes, having a way to retain root and disable Magisk modules is very useful indeed.

"EdXposed Manager" is not a Magisk module. It is an app, just like Xposed Manager, to handle the EdXposed framework (which is a Magisk module) and Xposed modules (which are apps).

  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, daniel.schaaaf said:

 

Also, regarding what you wrote in the other topic for option 1, I believe that using Magisk manager to directly install Magisk is only available if Magisk is already installed.  In other words, it can be used to upgrade the magisk version.  If magisk is not installed (by flashing the stock boot image), then you have to install it by patching the boot image and flashing that patched boot image. 

If you already have a patched boot image, you still have to tell Magisk manager to patch the stock boot image so that it has a backup of the stock boot image.  This is so you can later temporarily disable Magisk through Magisk manager->Uninstall->Restore Images, do an OTA update to Android, and then use Magisk manager to enable magisk again.

Share this post


Link to post
Share on other sites
13 minutes ago, daniel.schaaaf said:

Yes, having a way to retain root and disable Magisk modules is very useful indeed.

"EdXposed Manager" is not a Magisk module. It is an app, just like Xposed Manager, to handle the EdXposed framework (which is a Magisk module) and Xposed modules (which are apps).

Okay, I think I understand our mix up now.  In my case, it was installing the EdXposed framework that caused my boot issue.  It is a Magisk module, so there was no way to get out of that situation, other than to wipe /data or use the Magisk core method.

I never got to the step where I could install EdXposed Manager, so I did not know it was not a Magisk module.

Share this post


Link to post
Share on other sites

I re-read your option 1 again:

Quote

The most obvious way to get around a boot hang is: 1) flash the original boot.img, 2) boot into the UI and uninstall the Xposed module causing the boot halt, and 3) flash "magisk_patched.img" and re-installing Magisk from within the Magisk Manager ("direct install").

If you flash magisk_patched.img, Magisk *is* installed.  I don't think doing the direct install (which would just install the same version over itself) is needed?

Related to this, I am not understanding how your number 2 works.  In my mind, flashing magisk_patched.img over itself isn't changing any state.  The before and after states are identical.  So if it fails to boot, flashing magisk_patched.img over itself will still fail to boot.  What am I missing? 

Does magisk somehow know it was just reflashed and not enable root for several seconds?  If so, how does it know it was reflashed?  /data isn't modified by reflashing magisk_patched.img, so it can't look there.  /system is not supposed to be modified, because Magisk is systemless and doesn't modify /system.  Does Magisk manager keep track of whether the last boot was with/without Magisk and inform Magisk if magisk_patched.img is flashed and booted after stock_boot.img has been booted to disable Magisk?

Edited by david

Share this post


Link to post
Share on other sites
29 minutes ago, david said:

If you already have a patched boot image, you still have to tell Magisk manager to patch the stock boot image so that it has a backup of the stock boot image.  This is so you can later temporarily disable Magisk through Magisk manager->Uninstall->Restore Images, do an OTA update to Android, and then use Magisk manager to enable magisk again.

That's true. And, thank you for reminding me. I forgot doing that the last time 🙂

 

19 minutes ago, david said:

Okay, I think I understand our mix up now.  In my case, it was installing the EdXposed framework that caused my boot issue.  It is a Magisk module, so there was no way to get out of that situation, other than to wipe /data or use the Magisk core method.

I never got to the step where I could install EdXposed Manager, so I did not know it was not a Magisk module.

That's the beauty of "Method 2", re-flashing magisk_patched.img leaves Magisk active and retains root 😉

It doesn't always work, and there is a lot of weird stuff going on, like removing the SIM and/or SD-card helping, but it might be a way to start your phone and disable Magisk modules. In my case, I had a few seconds to do so, before Android crashed and got stuck during the boot process again.

 

5 minutes ago, david said:

If you flash magisk_patched.img, Magisk *is* installed.  I don't think doing the direct install (which would just install the same version over itself) is needed?

I don't know what else the Magisk manager is doing when you install Magisk again with "direct install". The first time I re-flashed magisk_patched.img, some apps had trouble getting root. After re-installing Magisk with "direct install", the root problems were gone.

Share this post


Link to post
Share on other sites
2 minutes ago, daniel.schaaaf said:

I don't know what else the Magisk manager is doing when you install Magisk again with "direct install". The first time I re-flashed magisk_patched.img, some apps had trouble getting root. After re-installing Magisk with "direct install", the root problems were gone.

Maybe that is why the name looks like "magic".  It is using magic. 🙂

Share this post


Link to post
Share on other sites
1 hour ago, daniel.schaaaf said:

That's the beauty of "Method 2", re-flashing magisk_patched.img leaves Magisk active and retains root 😉

It doesn't always work, and there is a lot of weird stuff going on, like removing the SIM and/or SD-card helping, but it might be a way to start your phone and disable Magisk modules. In my case, I had a few seconds to do so, before Android crashed and got stuck during the boot process again.

Sorry, I updated my post while you were replying to a quote of it.  See above for my additional questions/comments about method 2.

Quote

Related to this, I am not understanding how your number 2 works.  In my mind, flashing magisk_patched.img over itself isn't changing any state.  The before and after states are identical.  So if it fails to boot, flashing magisk_patched.img over itself will still fail to boot.  What am I missing? 

Does magisk somehow know it was just reflashed and not enable root for several seconds?  If so, how does it know it was reflashed?  /data isn't modified by reflashing magisk_patched.img, so it can't look there.  /system is not supposed to be modified, because Magisk is systemless and doesn't modify /system.  Does Magisk manager keep track of whether the last boot was with/without Magisk and inform Magisk if magisk_patched.img is flashed and booted after stock_boot.img has been booted to disable Magisk?

 

Edited by david

Share this post


Link to post
Share on other sites
4 hours ago, david said:

Related to this, I am not understanding how your number 2 works.

I don't know either. You are right, it doesn't make sense. All I know is that it works ... sometimes. When I first found out about re-flashing magisk_patched.img I was thrilled because it solved all my problems. Until I had to find out that it only works sometimes. So far I was lucky and always found something to make my Pro1 boot again. Like removing the SIM, which should not have made a difference either.

However ... I wouldn't be surprised if it was all just a big "coinkidinki" and all it takes is rebooting 100 times until the phone randomly starts. Although, the first time I encountered a boot halt, I tried rebooting many times without an effect ...

Share this post


Link to post
Share on other sites
1 hour ago, daniel.schaaaf said:

I don't know either. You are right, it doesn't make sense. All I know is that it works ... sometimes. When I first found out about re-flashing magisk_patched.img I was thrilled because it solved all my problems. Until I had to find out that it only works sometimes. So far I was lucky and always found something to make my Pro1 boot again. Like removing the SIM, which should not have made a difference either.

However ... I wouldn't be surprised if it was all just a big "coinkidinki" and all it takes is rebooting 100 times until the phone randomly starts. Although, the first time I encountered a boot halt, I tried rebooting many times without an effect ...

Oh, so it could even be that the module that was causing it to not boot was just randomly working sometimes and it wasn't related to flashing the patched image at all?

It seems like, as long as it is an EdXposed module and not a Magisk module, your number 1 should always work.  If it is a Magisk module (whether the EdXposed framework or some other Magisk module), your number 2 can be tried, but may or may not work.  And if it doesn't work, then preparing or using a pre-prepared Magisk core-only patched image is guaranteed as a way to get out of it without clearing /data.

Having said all that, although the core-only method *should* guarantee recovering, I am still researching backup methods before I attempt this again.  Titanium Backup does not work on split APKs/App bundles, so it doesn't work on a lot of new apps.  Some people have found that you can install the apps from the Play Store and then restore just the data, but I think I read that doesn't work for everyone.  And I can imagine that if an app version has changed significantly, then the data might not match what the app expects.  I suppose a person could try to find the matching APK online, somewhere else, and install it that way, and then apply the data from TB. 

But, as that may not be foolproof, I am going to keep looking for other options, for a backup backup.  :-)  There aren't a ton of backup options that support split APKs.  I've heard good things about Swift Backup, so I might try that.

Share this post


Link to post
Share on other sites

No, none of the Xposed modules causing a boot halt ever "worked randomly sometimes". They all crashed Android a few seconds after Android finished booting, whenever I managed to get Android to boot up.

One exception might be MyAndroidTools Xposed, which did work when I booted without my SIM. And it continued to work after I put the SIM back in while Android was running.

 

My Pro1 does not pass the SafetyNet checks. Whether that is caused by XPrivacyLUA or by EdXposed itself I don't know. Thankfully I don't have anything running on my phone that requires SafetyNet 🙂 (I have to use an old version of a TAN app for my bank account though)

 

Regarding backups, I use oandbackup and AppWererabbit to backup app data. Restoring data from an older version never was a problem for any of my apps. When you switch phones or upgrade/change Android, some apps detect that they were restored when they compare e.g. the Android ID from the data backup against the new ID. These apps can be fooled with XPrivacyLUA 😉

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

Terms