• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

Magisk General Support / Discussion

Search This thread

sporc10

Senior Member
Dec 21, 2014
50
13
Sorry but it was really a bad and wrong idea to freeze the Magisk app (pretty sure, it was not suggested in this thread) - specially upon it was repackaged.
Without, you cannot grant root access, etc

And of course, your newly installed Magisk app cannot connect to Magisk because the old (repackaged and frozen one - doesn't matter) is still connected to Magisk DB - three were so many posts here about the same problem when the newly installed Magisk app shows N/A for Magisk because of the forgotten, old, repackaged Magisk mngr/app still installed

First, uninstall that newly installed Magisk app (simply from Settings, Apps)

Then, you must find your old, repackaged (and frozen) Magisk Manager/App and uninstall it, too

Unfortunately, when you did repackaging, the package name was randomized and you don't remember that randomized package name (another reason it should have not been frozen then)

Hopefully, you remember which app name you gave it instead of the Magisk mngr/app - try to find it under that name in Settings, Apps and try to uninstall it there (even since it was frozen)

Or, install an app Package Manager from Google Play, search in that app for the app name of your renamed/repackaged Magisk Manager/App.
You can probably uninstall it from that Package Manager but even if not, you can read there its randomized package name

The other way to find its randomized package name will be to use ADB comnand from PC:
adb shell pm list packages -d

That command lists package names for all your "pm disable-user ..." apps (that is, those apps you 'froze')

Look at the output list and if you see some totally strange/randomized package name, that one should correspond to your (frozen and) repackaged Magisk mngr/app

Once you detect its (randomized) package name, you will be able to 'un-freeze' by ADB:
adb shell pm enable <package-name>

and then you should be able to regularly uninstall it from Settings, Apps (or just open it, go to Settings, and take the Restore option to get it back to the 'normal', not renamed/randomized Magisk mngr/app)

Only then, if neccessry, install the new/updated Magisk app

PS: For all who cannot live without repackaging Magisk app.
Upon repackaging, open the app and take a screenshot - on top, under the App info, after Latest and Installed lines, you will see the line Package showing its randomized package name.
Save the screenshot for your reference - in case you ever 'freeze' it, you will know its randoized package name to un-freeze
Yeah sure in retrospect it was stupid..
Thank you for your very detailed answer.

I uninstalled the new installed Magisk manager from setttings -> ok
In settings under all apps I can see the 'old' App which is just called 'Manager' and is stated as disabled -> ok

One point is still not clear for me:
What do do now? If I uninstall the 'Manager' App will I automatically get the old Magisk manager back? OR should I better use the adb command to reenable the renamed app?
 

zgfg

Senior Member
Oct 10, 2016
5,485
2,819
Yeah sure in retrospect it was stupid..
Thank you for your very detailed answer.

I uninstalled the new installed Magisk manager from setttings -> ok
In settings under all apps I can see the 'old' App which is just called 'Manager' and is stated as disabled -> ok

One point is still not clear for me:
What do do now? If I uninstall the 'Manager' App will I automatically get the old Magisk manager back? OR should I better use the adb command to reenable the renamed app?
You can do either one

If you uninstall, then just install again the newest Magisk app - you will not loose anything (modules, etc), just make sure that you enable MagiskHide again.
You can also repackage then the newly installed Magisk app

Otherwise, use the adb command to re-enable your old repackaged Magisk App or Mngr (depending how old it was)

In the first case you assure that you would have the latest Magisk app.
In the second case you may need to update (upon being re-enabled)!your Magisk app/mngr if you want (and that could possibly fail if you try to update from the repackaged app/mngr)

I would go for the first option, and then also update the Magisk itself (unless you have some old device where Magisk update/installation might fail)

Edit - maybe you have an option in Settings/Apps to enable the disabled/frozen old Magisk mngr/app, in that case you don't need to use adb command for the option (2)
 
Last edited:

sporc10

Senior Member
Dec 21, 2014
50
13
You can do either one

If you uninstall, then just install again the newest Magisk app - you will not loose anything (modules, etc), just make sure that you enable MagiskHide again.
You can also repackage then the newly installed Magisk app

Otherwise, use the adb command to re-enable your old repackaged Magisk App or Mngr (depending how old it was)

In the first case you assure that you would have the latest Magisk app.
In the second case you may need to update (upon being re-enabled)!your Magisk app/mngr if you want (and that could possibly fail if you try to update from the repackaged app/mngr)

I would go for the first option, and then also update the Magisk itself (unless you have some old device where Magisk update/installation might fail)

Edit - maybe you have an option in Settings/Apps to enable the disabled/frozen old Magisk mngr/app, in that case you don't need to use adb command for the option (2)
I went for the first option. I uninstalled the renamed package and installed the newest App.
It detects magisk again, thank you!
So it says the Magisk version is 21.1, if I want to update with the direct installation method it says "unable to detect target image". Any hints on this one?
 
  • Like
Reactions: J.Michael and zgfg

zgfg

Senior Member
Oct 10, 2016
5,485
2,819
I went for the first option. I uninstalled the renamed package and installed the newest App.
It detects magisk again, thank you!
So it says the Magisk version is 21.1, if I want to update with the direct installation method it says "unable to detect target image". Any hints on this one?
Can you post the screenshot showing your Magisk main window to see the versions

Are you on Stable?
And sorry, you probably posted but what is your phone and ROM?

You could try patching your image but maybe it would also fail (might be that v23 does not install to your phone)
 

sporc10

Senior Member
Dec 21, 2014
50
13
Can you post the screenshot showing your Magisk main window to see the versions

Are you on Stable?
And sorry, you probably posted but what is your phone and ROM?

You could try patching your image but maybe it would also fail (might be that v23 does not install to your phone)
Magisk:
Installed: 21.1 (21100), A/B: Yes, Ramdisk: No, SAR: Yes
App:
Newest: 23.0(23000)
Installed: 23.0 (23000)

I am using an PH-1 with an Android 11 Rom (Build: RQ1A.201205.010)

The main 'problem' I had is solved. I have Magisk back and so far everything is working.
If I get some sparetime I will have a look on patching the boot.img. Until then I will go with the actual setup. So once again thank you for the great support!
 
  • Like
Reactions: zgfg and J.Michael

pndwal

Senior Member
Magisk:
Installed: 21.1 (21100), A/B: Yes, Ramdisk: No, SAR: Yes
App:
Newest: 23.0(23000)
Installed: 23.0 (23000)

I am using an PH-1 with an Android 11 Rom (Build: RQ1A.201205.010)

The main 'problem' I had is solved. I have Magisk back and so far everything is working.
If I get some sparetime I will have a look on patching the boot.img. Until then I will go with the actual setup. So once again thank you for the great support!
Nice / interesting device.

Is 11 ROM modified pixel ROM?

Did you install from custom recovery originally?

"unable to detect target image" (both from custom recovery or App direct Install) is often due to fstab not containing the info where the boot block device is, or missing symlinks with proper names, making it impossible to detect where your boot image partition is. (Could be messed up vendor partition, or other.)

I'm not sure this is your problem as you did get it installed (unless pre-rooted?), but patching image manually should overcome it if it is. PW
 
Last edited:

pndwal

Senior Member
Magisk:
Installed: 21.1 (21100), A/B: Yes, Ramdisk: No, SAR: Yes
App:
Newest: 23.0(23000)
Installed: 23.0 (23000)

I am using an PH-1 with an Android 11 Rom (Build: RQ1A.201205.010)

The main 'problem' I had is solved. I have Magisk back and so far everything is working.
If I get some sparetime I will have a look on patching the boot.img. Until then I will go with the actual setup. So once again thank you for the great support!
A bit further; - I did a little digging into this because I was surprised to see a report of an A/B device w/ Ramdisk = No.

I hadn't seen (factory boot) ramdisk status change before, and I'm pretty sure it isn't meant to.

Clearly, your PH-1 is SAR by Google's definition (legacy SAR by John Wu's.) See this:
https://topjohnwu.github.io/Magisk/boot.html
and is a Type II device with a recovery ramdisk in boot partition.

Devices with any type of ramdisk in boot partition should show Ramdisk = Yes, ie. all types I, II & IV.

Type III are the ONLY type that have no ramdisk in stock (factory) boot partition! ... And these often (but not always) lack bootloader support even for manually added ramdisk in boot partition. See table here:
https://topjohnwu.github.io/Magisk/boot.html#piecing-things-together

So it seems to me there's something peculiar (messed up?) with your device, perhaps related to TWRP which resides in boot partition on Type II devices if you have this and Magisk has patched the already TWRP patched boot image. Or perhaps related to a pre-built modded boot image, Android 11 ROM (seems to be a custom port?), device tree used, etc, etc.

Anyway, I'm betting that those on stock images (including the recovery part of boot.img) w/ Magisk patched boot.img only, have Ramdisk = Yes in Magisk App...

Root guide here:
https://forum.xda-developers.com/t/guide-rooting-your-essential-ph-1.3701976/

Incidentally, I noticed here that @ipdev has PH-1 also. Perhaps he can help with configuration, Ramdisk status, etc. 😜 PW
 
Last edited:

ipdev

Recognized Contributor
Feb 14, 2016
1,440
1
1,683
Google Nexus 10
Nexus 7 (2013)
Magisk:
Installed: 21.1 (21100), A/B: Yes, Ramdisk: No, SAR: Yes
App:
Newest: 23.0(23000)
Installed: 23.0 (23000)

I am using an PH-1 with an Android 11 Rom (Build: RQ1A.201205.010)

The main 'problem' I had is solved. I have Magisk back and so far everything is working.
If I get some sparetime I will have a look on patching the boot.img. Until then I will go with the actual setup. So once again thank you for the great support!
What ROM are you using?
Are you porting/bringing up a rom?

Let me know and I will give it a try. :)

A bit further; - I did a little digging into this because I was surprised to see a report of an A/B device w/ Ramdisk = No.

I hadn't seen (factory boot) ramdisk status change before, and I'm pretty sure it isn't meant to.

Clearly, your PH-1 is SAR by Google's definition (legacy SAR by John Wu's.) See this:
https://topjohnwu.github.io/Magisk/boot.html
and is a Type II device with a recovery ramdisk in boot partition.

Devices with any type of ramdisk in boot partition should show Ramdisk = Yes, ie. all types I, II & IV.

Type III are the ONLY type that have no ramdisk in stock (factory) boot partition! ... And these often (but not always) lack bootloader support even for manually added ramdisk in boot partition. See table here:
https://topjohnwu.github.io/Magisk/boot.html#piecing-things-together

So it seems to me there's something peculiar (messed up?) with your device, perhaps related to TWRP which resides in boot partition on Type II devices if you have this and Magisk has patched the already TWRP patched boot image. Or perhaps related to a pre-built modded boot image, Android 11 ROM (seems to be a custom port?), device tree used, etc, etc.

Anyway, I'm betting that those on stock images (including the recovery part of boot.img) w/ Magisk patched boot.img only, have Ramdisk = Yes in Magisk App...

Root guide here:
https://forum.xda-developers.com/t/guide-rooting-your-essential-ph-1.3701976/

Incidentally, I noticed here that @ipdev has PH-1 also. Perhaps he can help with configuration, Ramdisk status, etc. 😜 PW

Essential PH-1 (mata) is basically a sister to Pixel 2/XL.
Save for PH1's bootloader not having a boot option.
- You could flash taimen's system image on mata and everything normally worked.


I haven't fired mine up in a while, normally just use it for testing. ;)

---

Installed the current lineage 18.1 nightly...
Using lineage's recovery.

- Patched the boot image with Magisk canary.
- Flashed the patched image and booted.
- Direct install worked fine.

Cheers. :cowboy:

PS.
When PH-1 was supported, before Essential closed their doors, all the official builds had a ramdisk in boot.
It is what I used to pull the monthly fingerprint and security patch date from.

PPS.
The l18.1 boot image boots AOSP Android 10 GSI on mata. ;)
“We don't make mistakes, just happy little accidents.” - Bob Ross.
 

Attachments

  • Screenshot_20210618-185728_Settings.png
    Screenshot_20210618-185728_Settings.png
    167.2 KB · Views: 52
  • Screenshot_20210618-185746_Settings.png
    Screenshot_20210618-185746_Settings.png
    96.3 KB · Views: 53
  • Screenshot_20210618-185814_Settings.png
    Screenshot_20210618-185814_Settings.png
    102.2 KB · Views: 52
  • Like
Reactions: sporc10 and pndwal

pndwal

Senior Member
What ROM are you using?
Are you porting/bringing up a rom?

Let me know and I will give it a try. :)

Essential PH-1 (mata) is basically a sister to Pixel 2/XL.
Save for PH1's bootloader not having a boot option.
This made me think, but guess meant Fastboot option!?
- You could flash taimen's system image on mata and everything normally worked.

I haven't fired mine up in a while, normally just use it for testing. ;)
---
Installed the current lineage 18.1 nightly...
Using lineage's recovery.

- Patched the boot image with Magisk canary.
- Flashed the patched image and booted.
- Direct install worked fine.

Cheers. :cowboy:

PS.
When PH-1 was supported, before Essential closed their doors, all the official builds had a ramdisk in boot.
It is what I used to pull the monthly fingerprint and security patch date from.

PPS.
The l18.1 boot image boots AOSP Android 10 GSI on mata. ;)
Many thanks for info, especially confirmation A11 (LOS 18.1) works as expected on PH-1. 👌
“We don't make mistakes, just happy little accidents.” - Bob Ross.
🤩 PW
 
Last edited:
  • Like
Reactions: ipdev

ipdev

Recognized Contributor
Feb 14, 2016
1,440
1
1,683
Google Nexus 10
Nexus 7 (2013)
This made me think, but guess meant Fastboot option!?

Many thanks for info, especially confirmation A11 (LOS 18.1) works as expected on PH-1. 👌

🤩 PW
There are a few oddities/drawbacks with Essential PH-1 (mata).

Not being able to fastboot boot is one of them.
Broken touch in recovery is another.

You can not temporarily boot a boot or recovery image.
Only option is to flash it using fastboot.

Taught us mata users how to work around some things. ;)

Cheers. :cowboy:
 
  • Like
Reactions: pndwal

pndwal

Senior Member
There are a few oddities/drawbacks with Essential PH-1 (mata).

Not being able to fastboot boot is one of them.
Ah yes:
Unlike the Pixel devices, Essential has disabled fastboot boot so there is no way to temporarily boot TWRP to perform an installation.
https://twrp.me/essential/essentialph1.html

Broken touch in recovery is another.
FWIW, seems that issue only occurs if using Official pre-built TWRP (link above) w/ post Sept 2018 ROMs as it hasn't been updated since Sept 10 2018.

Simply replacing Official "initial copy of TWRP" with this TWRP patched boot image should fix touch:
https://drive.google.com/file/d/1YxJJj96Web0ikHXdHf_zboZT_KSYl7Nj/view
according to:
https://forum.xda-developers.com/t/guide-rooting-your-essential-ph-1.3701976/

Next, updating your system by patching boot images for later builds with the TWRP Installer "will allow touch to work flawlessly".

Still, compatibility should be considered using such an old TWRP build.

Additional Information:

I saw this in 2nd post from link above:
No Touch in TWRP

Some day you may end up with a firmware that doesn’t play well with twrp. Either no touch screen, or no data decryption.

One quick way to flash a zip in this situation is to put the device in sideload mode via an adb command:
adb shell twrp sideload

then flash your zip using adb sideload:
adb sideload myawesomezip.zip

No Touch when moving from 8/2018 -> 9/2018 Pie builds

Read this post.

TL;DR: Basically essential updated two firmware files byp and rpm. These two images were left out of the September fastboot.zip and the older versions from August 2018 and prior are incompatible September going forward.

Simply fastboot flash both of these images to the byp and rpm partitions respectively.
https://mata.readthedocs.io/en/latest/

Nb. seems correct partitions are hyp & rpm.

So sideload can be used to patch active slot boot.img with TWRP Installer zip despite broken touch in initial TWRP (in inactive slot)... Or a TWRP patched boot image from a post Sept. ROM build should fix touch (for initial boot only) as it will be compatible with later hyp and rpm files... Or a mouse and OTG adapter can work... Or you could even obtain old hyp and rpm images from pre Sept. 2018 ROM and replace newer ones in inactive slot with these to get Official initial pre-built TWRP working.... 😜
https://forum.xda-developers.com/t/official-twrp-3-2-3-0-for-essential-ph-1.3840931/post-77597383

Taught us mata users how to work around some things. ;)
Yup, "Necessity is the mother of invention".

I agree with that much from Plato... Alfred Whitehead and Agatha Christie can have their opinions. 😬 PW
 
Last edited:
  • Like
Reactions: ipdev

Joingoin

New member
Jun 19, 2021
4
2
Redmi K20 / Xiaomi Mi 9T
Hey im having trouble installing Magisk and im now searching Help here!

I already installed Magisk once and already faced troubles back then. To sum them up:
I own a Xaomi Mi 9T and have to flash to Recovery, back then i got it to work with an image i patched with Canary-Branch of Magisk.
After an Update of my Phone i have to reinstall.

Reinstall with Canary or Normal Branch Magisk Patched Recovery-Image didnt work, it always boots back to Fastboot.
What i´ve tried so far:
Patch Image with different Magisk Versions.
Use different Images.
Remove any remaining Magisk Modules using TWRP.

Attached is the only usefull Log i could find, i hope its usefull to you.
Last_Log

Thanks for all your answers in advance!
 

zgfg

Senior Member
Oct 10, 2016
5,485
2,819
Hey im having trouble installing Magisk and im now searching Help here!

I already installed Magisk once and already faced troubles back then. To sum them up:
I own a Xaomi Mi 9T and have to flash to Recovery, back then i got it to work with an image i patched with Canary-Branch of Magisk.
After an Update of my Phone i have to reinstall.

Reinstall with Canary or Normal Branch Magisk Patched Recovery-Image didnt work, it always boots back to Fastboot.
What i´ve tried so far:
Patch Image with different Magisk Versions.
Use different Images.
Remove any remaining Magisk Modules using TWRP.

Attached is the only usefull Log i could find, i hope its usefull to you.
Last_Log

Thanks for all your answers in advance!
For Xiaomi Mi 9T:
- extract boot img from your recovery/zip firmware (or from tgz/fastboot firmware) or use boot.emmc.win from your TWRP backup)
- then patch that boot.img (Recovery option must be disabled by default)
- then flash the patched img to Boot partition

Yes, that is the procedure - although Magisk app says Ramdisk No, nevertheless patch the boot.img (not recovery.img) and everything will be ok

On Recovery, keep the stock recovery or use the latest official twrp-3.5.2_9-0-davinci.img
 

Joingoin

New member
Jun 19, 2021
4
2
Redmi K20 / Xiaomi Mi 9T
For Xiaomi Mi 9T:
- extract boot img from your recovery/zip firmware (or from tgz/fastboot firmware) or use boot.emmc.win from your TWRP backup)
- then patch that boot.img (Recovery option must be disabled by default)
- then flash the patched img to Boot partition

Yes, that is the procedure - although Magisk app says Ramdisk No, nevertheless patch the boot.img (not recovery.img) and everything will be ok

On Recovery, keep the stock recovery or use the latest official twrp-3.5.2_9-0-davinci.img
Thanks alot for your reply.

The installation worked now, sadly Wifi doesnt seem to be working now.
I flashed the boot image a second time already since google said so ;D.

Any other ideas?
 

zgfg

Senior Member
Oct 10, 2016
5,485
2,819
Thanks alot for your reply.

The installation worked now, sadly Wifi doesnt seem to be working now.
I flashed the boot image a second time already since google said so ;D.

Any other ideas?
Disable all Magisk modules you may have, reboot and try again

When I used to be on stock (EEA, MIUI 10-12, Android 9-10) I never had a problem with WiFi

For the last 6-7 months I'm on Xiaomi.eu weekly MIUI 12.6, Android 11 builds, also no problem with WiFi (or anything)
 
  • Like
Reactions: J.Michael

Joingoin

New member
Jun 19, 2021
4
2
Redmi K20 / Xiaomi Mi 9T
Disable all Magisk modules you may have, reboot and try again

When I used to be on stock (EEA, MIUI 10-12, Android 9-10) I never had a problem with WiFi

For the last 6-7 months I'm on Xiaomi.eu weekly MIUI 12.6, Android 11 builds, also no problem with WiFi (or anything)
Nah still no luck., ive turned of Magisk Hide and my Saftey-Net fix both.
To specifiy: I cant turn on the Wifi, it instantly turns itself off again!
 
  • Like
Reactions: J.Michael

zgfg

Senior Member
Oct 10, 2016
5,485
2,819
Nah still no luck., ive turned of Magisk Hide and my Saftey-Net fix both.
To specifiy: I cant turn on the Wifi, it instantly turns itself off again!
Are you sure that problems started when you installed Magisk

Disable Mobile Data and test if WiFi stays connected then

Generally, check if similar problem was reported on the Mi 9T forum or ask there (particularly for your firmware, you didn't say are you on Global, EEA, China, Russia or India and what is your particular MIUI and Android version, like V12.0.5.0.QFJEUXM, V12.1.2.0.RFJMIXM, etc):
 
Last edited:
  • Like
Reactions: J.Michael

Joingoin

New member
Jun 19, 2021
4
2
Redmi K20 / Xiaomi Mi 9T
Are you sure that problems started when you installed Magisk

Disable Mobile Data and test if WiFi stays connected then

Generally, check if similar problem was reported on the Mi 9T forum or ask there (particularly for your firmware, you didn't say are you on Global, EEA, China, Russia or India and what is your particular MIUI and Android version, like V12.0.5.0.QFJEUXM, V12.1.2.0.RFJMIXM, etc):
Yeah, im 100% sure it started when i installed magisk.
The problem is not that i cant connect to a network, i cant even turn on Wifi to even at least scan for networks.
Mobile Data seems to connect but doesnt provide internet!

Im on Global MIUI 12.0.5.0


EDIT: I Downloaded the offical ROM from Xaomis Site and Patched and Flashed it and its still not working :/
 
Last edited:
  • Like
Reactions: J.Michael

pndwal

Senior Member
Yeah, im 100% sure it started when i installed magisk.
The problem is not that i cant connect to a network, i cant even turn on Wifi to even at least scan for networks.
Mobile Data seems to connect but doesnt provide internet!

Im on Global MIUI 12.0.5.0


EDIT: I Downloaded the offical ROM from Xaomis Site and Patched and Flashed it and its still not working :/
Just checking, Recovery mode is unchecked when patching? PW
 
  • Like
Reactions: J.Michael

J.Michael

Senior Member
Jan 20, 2018
748
564
Samsung Galaxy Tab A series
Yeah, im 100% sure it started when i installed magisk.
The problem is not that i cant connect to a network, i cant even turn on Wifi to even at least scan for networks.
Mobile Data seems to connect but doesnt provide internet!

Im on Global MIUI 12.0.5.0


EDIT: I Downloaded the offical ROM from Xaomis Site and Patched and Flashed it and its still not working :/
When you flash official ROM, before trying to install Magisk, does wifi work?
 

Top Liked Posts

  • 2
    If the GApps install to Boot, then they were no more in your boot.img you extracted from the OS zip

    If you had TWRP, you could have backed-up your Boot partition (with the GApps already installed) and then patch that boot.emmc.win (TWRP back-up) instead of the extracted boot.img (with no GApps)
    🤔 I'm confused here; does GApps ever install to boot partition? ... Or do you mean Play Services (only) can install there? ...

    My understanding is that GApps is (always?) in /system w/ parts in /data !? 🙃 PW
    2
    I'm attempting to install magisk on a oneplus 5T with lineageOS 18.1 and openGApps pico. I think I've followed the instructions correctly: I installed lineageOS and openGApps and everything was working, and then I extracted the boot.img from the lineageOS zip, patched it and flashed it. This broke the installed GApps (none of the could find google play services) and I had to reinstall lineageOS and the GApps. Is this is a known issue? Did I follow the instructions wrong? Help much appreciated.
    I'd say it's unusual.

    Assuming you are 100% sure you patched / flashed boot image from exact LOS build you are currently using (which failure often affects/breaks network/data access, incl. Play services access) ie. you didn't muddle image files on PC etc, I have the following questions:

    Did you notice issue with initial Magisk installation w/ MagiskHide disabled? (could give clues 😉)

    Also, just in case, you didn't manually add any Google App processes to MagiskHide list (especially in Google Play services) did you?

    Did you have data/internet access?

    Did you try clearing data for Google Play services?

    But seems all went well after you reinstalled. Do you now have Magisk / root?

    If so, what did you do differently? (Changed flash order? Clean install? No reboots between flashes? Other?) PW
    2
    I'm attempting to install magisk on a oneplus 5T with lineageOS 18.1 and openGApps pico. I think I've followed the instructions correctly: I installed lineageOS and openGApps and everything was working, and then I extracted the boot.img from the lineageOS zip, patched it and flashed it. This broke the installed GApps (none of the could find google play services) and I had to reinstall lineageOS and the GApps. Is this is a known issue? Did I follow the instructions wrong? Help much appreciated.
    Could have just been a bad install/update.
    The core of GApps needs to be compatible versions.
    If one is out of sync with the other(s) you will have issues.


    What version (and dates) of GApps and Lineage are you using?
    My dumpling is running l18 (personal build), OpenGApps (personal build, need to check the date) and Magisk (canary).​

    Backup what you want to save and store it off device.
    Copy it to your computer, cloud storage, USB, ...


    Try again with a complete clean flash.

    Instead of flashing the magisk patched image, test by just booting it.
    fastboot boot magisk_patched-VersionNumber_SomeThing.img

    If Magisk is active, you can use the Direct Install option in Magisk.
    or reboot back into bootloader and flash the patched boot image.

    Cheers. :cowboy:
    2
    OK. Now I am going to study the new knowledge of android phone about "how to extract .img from a payload". Using android phone is great, it teaches you android knowledge that becomes useless every few months.

    Actually that knowledge gets used often as has been around for more than 6 months, and will be around 6 months from now :)

    And to help you, in my sig (and here) is an easy (if youre running windows x64) tool to extract the boot image from payload.bin (inside the ROM zip).

    1) download payload_dumper-win64.zip and extract
    2) extract payload.bin from ROM and put in payload_dumper-win64\payload_input folder
    3) run payload_dumper.exe
    4) monitor payload_output folder - once theres more than boot.img in there, you can kill the process if yuo liek to avoid extracting all the images
    5) copy boot.img file to device
    6) patch with magisk
    7) move magisk_patched.img back to PC
    8) flash with fastboot flash boot <magisk_patched.img>
    9) reboot with fastboot reboot

    Holler if you are not using windows, theres a tool for every OS...

    Some ROM devs will include a boot.img file separately (like ABC ROM), some wont. But now you have the knowledge, and a tool for those
    2
    1. A Pixel 2 phone that had LOS 17 running with magisk rooted.
    2. Successfully upgraded to latest LOS 18.1 and everything runs well except that I lost root, with only the Magisk app still installed on the phone (as expected).
    3. Followed the "patch image method" from Magisk guide:
      1. ) Extract boot.img from google factory downloads, as magisk app showed I have ramdisk.
    You need to patch boot image matching your current ROM!... I don't think Google supplies images for custom LineageOS! 😉

    Extract boot.img from current LOS package, or take TWRP backup incl. boot partition, locate and patch that (either as .win or renamed to .img file).
    👍 PW.
  • 9

    Latest @vvb2060 Magisk Alpha build (July 18, 2021) changelog:​

    Chinese Translated:

    alpha update log​

    Magisk (1eb83ad8-alpha-19)​

    • Based on 1eb83ad8, please refer to the upstream update log for related modifications
    • Properly process any data from magiskd
    • Support SharedUserId
    • Delete the backup file after restoring the boot image
    • Built-in current version update log
    • Use the local version when the stub cannot be downloaded, now Magisk can be used completely offline
    • Support bootimg v4 format
    • Support bootconfig
    • Detect /data/adb/magisk/ not updated and prompt to repair
    • Remove the disabled and pending deletion marks when upgrading the module, and it is not allowed to mark as pending deletion before restarting
    • Fix that it cannot be flashed in some TWRP
    • Modify the search order of the module sepolicy location and fix the problem that some devices do not load the module sepolicy
    • Listen to the PACKAGE_FULLY_REMOVED broadcast to remove completely uninstalled apps from magiskhide
    • Display a modal waiting pop-up window when hiding/restore the Magisk application
    Edit: The following are new commits:
    • App adapted to Android 12
    • Android 12+ super user hides the screen overlay when the window pops up
    https://github.com/vvb2060/Magisk/b...73bce50fe5e/app/src/main/res/raw/changelog.md

    My earlier notes:
    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85098469

    Current notes:

    magisk_files repo is now updated! Check 'earlier notes' for installation method / details.

    Alpha build users won't yet see Update button notice in Magisk App for this build as VersionCode has (again) NOT changed from 23001.

    I'm not sure if this behaviour will be addressed, but users will observe the 'Latest' version (1eb83ad8-alpha-19) now differs from 'Installed' (1eb83ad8-alpha).

    Package is now also uploaded to Telegram group.
    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85229385

    Interestingly, in Magisk Documentation, @vvb2060 has updated "Internal Details" and "Deployment" since John did.
    https://github.com/vvb2060/Magisk/tree/alpha/docs

    😛 PW
    8
    @pndwal and @ipdev

    I saw you guys did some testing on the mysterious reinstallation of an uninstalled Magisk app on a reboot. I present you with the changelog for Magisk v16.6:
    [Daemon] Check whether a valid Magisk Manager is installed on boot, if not, install stub APK embedded in magiskinit
    :p
    8
    reddit link shared by John Wu:
    reddit post

    Especially interesting a comment by the leader of the Android Security team:
    (I lead the Android Hardware-backed security team, so while this response isn't official, it's informed. Do keep in mind that I am a programmer, not a lawyer, and I have not consulted with legal, so don't rely on this as any sort of legal advice. Nor did I run this by PR, so if I put my foot in my mouth, it's totally on me. This is not an official Google communication, and I may get my hand slapped for it. Probably not, but it's happened to me in the past :) ).

    I know of no legal issues here. AFAIK, you're free to do what you like with your device. Doing these sorts of things may invalidate your warranty, depending on the details, but I'm guessing you already know that and have decided you're fine with it.

    What I do know is that if you've found a vulnerability, Google would not only like to hear about it, Google may pay you for it. If you're compromising the TEE or kernel on a Pixel device, the reward could be up to $250,000. If you're compromising the Titan M, up to $1,000,000. Even if your current exploit isn't on a Pixel device, if you can make it work on a Pixel you would qualify. Alternatively, your device manufacturer may have their own bug bounty program and you should look.

    Obviously, if you report the vuln, what we're going to do is to fix it, so you'll lose your SafetyNet bypass. The same will happen if you publish it for others to use. Vulnerabilities that allow SafetyNet bypass typically compromise far more than just SafetyNet, which is why Google is willing to pay so much money to identify and fix them. Also, we really believe that app developers should be able to find out if they're running on a "stock" device, with all of the security and functionality guarantees that implies, so fixing SafetyNet bypasses is important in and of itself.

    It's not that we don't like custom ROMs or rooting, in fact we find a lot of the innovation that takes place in the community very interesting and eagerly adopt good ideas we find there, but our primary focus is on protecting the 99.9% of Android users who run stock Android, and the developers who serve them. It's an unfortunate but unavoidable reality that this sometimes disadvantages ROM users. I, personally, have been holding regular meetings with various leaders in the modding community for seven years now, to get their feedback and to give them a heads up on security features we implement that might pose problems for them. My goals are to both serve the main Android userbase of some 3B people and to avoid harming the modding community. Sadly, sometimes those goals conflict, and the modders obviously lose in those cases.

    I also want to address the comments about John Wu joining Google. He is perfectly capable of communicating his own intentions and goals so I won't try to do that. I'll just say that I have no interest in shutting down Magisk. To the degree that it enables people to bypass Android security guarantees, that just shows that we have work to do, indeed it helps us to identify where we need to do that work. It's not like Magisk can somehow create vulnerabilities (it's not magic). If vulns exist, they're certain to be found and exploited by people with nefarious goals, so it's better for everyone if there's a healthy "white hat" community focused on finding problems and reporting or publishing them. I see the Magisk community as part of that white hat community, and John as a valuable contributor to Android security even before he started working for Google.
    7
    Tried using https://raw.githubusercontent.com/topjohnwu/magisk_files/canary/app-debug.apk after it was already rooted with Magisk, but adb said [INSTALL_FAILED_VERSION_DOWNGRADE]
    Just use Magisk/Canary button on Magisk GitHub home page to get app. Opens
    This is latest 23001

    Nb. Your link (where did you get that??) is to latest Canary in old archived magisk_files repo (note '_', not '-') so it's fetching 22003, ie. you would be trying to downgrade from 23000, and to downgrade you need to uninstall 23000 first, as with any app downgrade. 😜

    Nb. Regular app installation from device should work fine, then Direct install to update (or downgrade) Magisk should be available / work.
    Well golly, the whole reason I was trying to use canary was to file a bug report, but if nobody is maintaining it, then there's no point. Thanks for letting me know!
    Wouldn't say no point however.

    Magisk contributors (there are 201) like @osmosis (especially) and @vvb2060 are still distilling / fixing issues, and responding to many issues, as are other informed / experienced users. Many workarounds / non-integrated solutions have been supplied.

    Further, as has been noted, many fixes from topjohnwu Magisk Issues have been incorporated in vvb2060's Alpha builds (seems these go back at least to Dec 2018. Archived builds from Dec 2020 are available on his GitHub & Telegram) before merging in John Wu's.

    I doubt this will change, and vvb2060 has produced several builds since John's last ones already! This is the beauty of such an open source project. Links, latest etc:
    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85226785

    It would be a misunderstanding to say only John is supplying fixes for Magisk Issues, just as he is not (any longer at least) its sole developer!
    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85127113

    Nb. John already pretty much turned over current App design / fixes to @diareuse so he could concentrate on Magisk Mask itself:
    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-83637567

    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-83771409

    Clearly the issue of official builds continuing (in present form or other) is up-in-the-air atm, but a healthy / active / interested community still exists. 🙂 PW
    7

    Early Notice:​

    Latest @vvb2060 Magisk Alpha build (July 23, 2021) changelog:​

    Skipped a few due to rapid-fire! (This guy's a bit like Jorrit!)

    Chinese Translated:

    alpha update log​

    Magisk (1eb83ad8-alpha-23)​

    • Based on 1eb83ad8, please refer to the upstream update log for related modifications
    • Properly process any data from magiskd
    • Support SharedUserId
    • Delete the backup file after restoring the boot image
    • Built-in current version update log
    • Use the local version when the stub cannot be downloaded, now Magisk can be used completely offline
    • Support bootimg v4 format
    • Support bootconfig
    • Detect /data/adb/magisk/ not updated and prompt to repair
    • Remove the disabled and pending deletion marks when upgrading the module, and it is not allowed to mark as pending deletion before restarting
    • Fix that it cannot be flashed in some TWRP
    • Modify the search order of the module sepolicy location and fix the problem that some devices do not load the module sepolicy
    • Listen to the PACKAGE_FULLY_REMOVED broadcast to remove completely uninstalled apps from magiskhide
    • Display the modal waiting pop-up window when hiding/restore the Magisk application
    • App adapted to Android 12
    • Android 12+ super user hides the screen overlay when the window pops up
    Edit: New changes since 1eb83ad8-alpha-19
    • For devices supported by the kernel, MagiskSU uses proprietary devpts to bypass some application detection
    • Rewrite MagiskSU's pty opening logic, no additional sepolicy rules are needed
    • Fix incorrect signal sending in MagiskHide
    • Add untrusted_app_30
    https://github.com/vvb2060/Magisk/b...e147e578c92/app/src/main/res/raw/changelog.md

    My earlier notes:
    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85098469

    Current notes:

    Check 'earlier notes' for installation method / details.

    Alpha build users won't yet see Update button notice in Magisk App for this build as VersionCode has (again) NOT changed from 23001.

    I'm not sure if this behaviour will be addressed, but users will observe the 'Latest' and 'Installed' version suffix now differs.

    This build has not been uploaded at the time of this post. Watch this space!

    Latest in GitHub magisk_files repo is 1eb83ad8-alpha-20

    Latest available from Telegram group is
    1eb83ad8-alpha-22
    https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85229385

    Interestingly, in Magisk Documentation, @vvb2060 has updated "Internal Details" and "Deployment" since John did.
    https://github.com/vvb2060/Magisk/tree/alpha/docs

    🤠 PW
  • 1056
    This is the place for general support and discussion regarding "Public Releases", which includes both stable and beta releases.
    All information, including troubleshoot guides and notes, are in the Announcement Thread
    156
    Hello, I haven't given much support on XDA lately. It can be resulted from
    • University started and I have limited free time. In fact, I mostly develop during midnight
    • I live in Taiwan, which has large time zone differences between my European/American contributors/testers, which usually forces me to stay up late at night to discuss/test stuffs.
    • The new version is about to come, I don't want to spend effort on supporting old releases
    The planned update is delayed again and again, to some point I think I'll shed some light about what has been happening lately, also along with some announcements.

    New Forum!
    As you might have already discovered, Magisk got its own subforum on XDA! Many thanks to all the support you gave me, and much more information/features/support is about to come!
    **For developers supporting all the devices that are not using standard Android boot format, feel free to create threads in this section (actually, PLEASE do so) for your favorite devices after v7 is out. As I currently know, Asus devices require signing the boot image before flashing, and is model dependant; Sony devices seems to use ELF kernel that is unpatchable, or some has two ramdisks (inner + outer), both requires different workarounds; LG bootloader locked devices has to manually "BUMP" the boot image after flashing Magisk..... and there may be lots of other crazy boot image formats that haven't come up to my attention yet.
    It is impossible for me to support all these non-standard boot images, and I hope the community can collaborate to make Magisk running across all the devices. Overall, community collaboration is what XDA about :D

    The Pixel Phone
    Some of you might already know this news, that the next Pixel Phone right around the corner seems like it does not have ramdisk in boot image, which pretty much wrecked Magisk in all ways. However, it pretty much doomed root itself too. Kernel modifications is inevitable IMO, so I'll try to migrate my scripts to C programs that could possibly be included into the kernel itself. Note that I'm not familiar with linux kernel, I'm not even sure if my idea and concept is correct or not. But once the device is available, I think developers will find a way to bypass all the difficulties, and I'll do my best to learn things ;)

    Current Progress
    In the past month, I've spent quite some time learning SELinux, so that I can avoid using SuperSU's sepolicy patches. Thanks to the helps and tips from @phhusson and @Chainfire, I finally have a much clearer understanding of how SELinux works. The Magisk core parts (the scripts, boot image patches, new features, more supports) are actually done some time ago. What is causing all the delays is the Magisk Manager.
    To be completely honest, although I can code in Java without much issues, Magisk Manager is actually my first Android application, I had to reach out for assistance, and fortunately awesome developers like @DVDandroid and @digitalhigh contributed a lot, which makes the current Manager awesome.
    After the repo system and module management is mostly done, I was about to do some adjustments and release, but what we really done is decided to add another feature: auto-unroot with per-app settings. I decided to wait for it to be finished, and then do my adjustments. Due to reasons that'll be mentioned later, this feature will likely not be available for the next release (should come in future updates)

    Safety Net Disaster
    Those who are using Magisk for Safety Net bypass purposes must have known that Google recently updated the detection method of my Systemless Xposed. I still have no idea what Safety Net is detecting, so currently I cannot fix it on my side (also because I'm busy working on the next update). However, suhide developed by @Chainfire is able to hide Xposed and worked fine.
    However, only my Systemless Xposed v86.2, which is based on SuperSU's su.d, is supported using that method. v86.2 and v86.5 (latest, Magisk based) have nearly identical binaries, and the only difference is the path where the binaries are stored.
    I'm still not sure what's the real issue for it not being supported, I just hope it is not done intentionally.

    Conclusion
    Due to the fact that my Safety Net bypass is not 100% perfect now, I do not want to spend any more time waiting for auto-unroot to be polished. What I'm doing now is finishing up all the things I'd like to change in Magisk Manager (it has been a while since I last contributed to Manager, my fellow developers are doing all the heavy job), which might take a little more time, after that, packed with tons of information to be announced in Magisk Section, I'll release the long awaited update.

    Hope this lengthy post gives you the idea of the whole situation, and again thanks for all your support!!
    121
    Ah, some Chainfire bashing, I hope it is not too late for me to exercise additional villainy.

    First, let me make clear I have nothing against @topjohnwu, nor against Magisk. Magisk is an interesting project and it certainly displays @topjohnwu ingenuity and persistence. I don't doubt we will see more interesting things from his hands.

    -------------------------

    What has happened here is not all that dark and complicated, from either end. I returned from holidays, and someone pointed me at Magisk. My first thought: interesting!

    Among other things, the thread lists some issues with SuperSU, which in combination with the phrase The developer also requests users to not bug Chainfire with compatibility requests for SuperSU with Magisk from the portal article, raised my left eyebrow by nigh half an inch. The popular systemless xposed mod is apparently now based on it, and apparently it now no longer works with SuperSU, and apparently I'm not supposed to fix that, nor any of the other found issues. I found that a bit weird. So yes, I have told @topjohnwu that I was a bit surprised he was posting about issues with SuperSU without notifying me about them (I can't fix or help fix issues I'm not aware of, after all).

    He's also spreading a modified version of the SuperSU package, which is not all that uncommon, nor necessarily a problem. I have not looked into what he modified, I only ran a few quick tests on one of my devices, and found some commonly used commands run as root to be broken. I have informed him of this as well.

    It appears the tool of choice for Magisk is phh's Superuser, because of some of the mentioned issues with SuperSU. That's fine by itself, but fixing issues in that superuser by incorporating SuperSU's binaries into it is a somewhat questionable practise. After all, SuperSU is a commercial closed-source package that helps pay for my dinner, and superuser is a direct competitor. I have informed him that I was surprised he did this without asking for permission. I have expressed similar surprise on him spreading a modified version of LiveBoot (which helps pay for a snack now and then).
    @topjohnwu has also stated that Magisk's scripts are largely influenced by mine (I have not checked). Scripts based on mine are used all over the place on XDA, some people have crafted amazing things based on them, I have never made an issue of this (otherwise I would have just made them binaries). But yes, I have also stated to him that I don't think it's very nice to base something on one program, and then using that to (almost exclusively) push something directly competing with that program.

    tl;dr Towards @topjohnwu, I have:
    - expressed surprise he has issues getting Magisk to work with SuperSU, and has chosen not to inform me about those
    - expressed surprise he is using SuperSU binaries in a competing superuser without permission
    - expressed surprise he is posting a modified LiveBoot without permission
    - informed him of issues with the modified SuperSU he has posted
    - let him know I thought it wasn't very nice to be applying my scripts to benefit seemingly exclusively that same competing superuser

    To be crystal clear:
    - I have not asked for an apology
    - I have not asked for Magisk to be abandoned, neither the root hiding nor systemless module parts, and certainly not systemless xposed
    - I have not made an issue of any of this anywhere, until this post
    - I have not even specifically asked for anything to be taken down (though obviously in my opinion the other superuser package mixed with SuperSU's binaries, as well as the LiveBoot package, should go)
    - I have not reported this thread to XDA moderators for copyright violations or otherwise

    While my conversation with @topjohnwu may not win any awards for being friendly (though it may win some for brevity), I think all things considered my response has been rather mild. To be perfectly honest, until the apology post, I thought this was over with already. I think the apology post was triggered because I haven't replied to his last PM for a while - I was in the zone, it happens.

    To emphasize again, I have nothing against @topjohnwu, Magisk, or systemless xposed, and it is certainly not my goal to see any of them go. If it can be made to work together with SuperSU, great.

    I get it though: you think of something, you want to see if you can make it work, you finally get it to work, you publish it, it takes off - enthusiasm gets the better of you. Maybe in the rush some mistakes are made. That doesn't mean you have to just drop it and run. None of my stuff would make it past 0.1 if I stopped at the first big mistake :)

    Aside from said being in the zone coding, I usually regret actually responding to these sort of things the day after, which has made me hesitant to reply. Surprise me.
    76
    Thread temporarily closed so everyone sees this.

    The flood of "SafetyNet isn't working for me either!" posts are not helpful, at all. Please refrain from posting further, it will be looked into. Please do not forget that not passing SafetyNet is 100% NORMAL AND INTENDED when you have an unlocked booloader or running custom firmware. These are workarounds and they will be worked around in turn.

    The Flash
    Forum Moderator

    EDIT: Thread is reopened... I will be cleaning any SafetyNet posts for a while to keep the thread clean for real issues.
    75
    Hello everyone!

    I am aware that Google has updated Safety Net that makes Magisk itself a no go for Android Pay. In fact, I witnessed the change live while I am developing the new magiskhide, which should hide all Magisk modules and Magisk installed root.

    Google is serious about Safety Net now, clearly hunting down all possibility to run Xposed with Safety Net passed. I spend quite some time examining the new security measures last midnight, and fortunately it seems that it is possible to run Magisk and root along with Safety Net if no Xposed is running. I'm glad I removed the old root toggle at the right time lol, that is no longer feasible with the latest detection.

    So stay tuned for the next update, it will come with bug fixes, along with the new magiskhide to bypass that Safety Net.

    Google, how will a few systemless mods do any harm :p:p