shoey63
Recognized Contributor
Does anyone know if there is a way to switch slots on the device itself, as opposed to jumping on the PC to change via fastboot?
Magisk General Support / Discussion
- Thread starter topjohnwu
- Start date
If you have a custom recovery like TWRP, it allows change of slots.
Hey there,
apologies, if this has been addressed, but it didn't came up after a lengthy search. (At least not with a solution that worked).
Anyway, I want to run GrapheneOS on a Pixel 7a, rooted with Magisk and a unlocked bootloader for now.
I did flash GrapheneOS and booted it afterwards.
Then I took the boot.img included in the same factory image zip and patched it on device with the latest Magisk app.
I flashed the patched boot.img from fastboot (fastboot flash boot boot.img, I even tried with "--slot all"), but after rebooting the Magisk app shows "Installed N/A".
It simply looks like it doesn't get installed, but every step finishes successful without any error.
Did I miss anything? What else could I try?
apologies, if this has been addressed, but it didn't came up after a lengthy search. (At least not with a solution that worked).
Anyway, I want to run GrapheneOS on a Pixel 7a, rooted with Magisk and a unlocked bootloader for now.
I did flash GrapheneOS and booted it afterwards.
Then I took the boot.img included in the same factory image zip and patched it on device with the latest Magisk app.
I flashed the patched boot.img from fastboot (fastboot flash boot boot.img, I even tried with "--slot all"), but after rebooting the Magisk app shows "Installed N/A".
It simply looks like it doesn't get installed, but every step finishes successful without any error.
Did I miss anything? What else could I try?
Probably not the answer you're looking for, and this is from an Asus thread, but this may apply to some other devices, such as my Pixel:
There is also another method mentioned in that post (details there):
I don't know specifically about GrapheneOS, or the 7a for that matter, but on the Pixel 7 and 7 Pro, init_boot.img is what needs patched with Magisk to get root, not boot.img.
shoey63
Recognized Contributor
Thanks
I have Rog 3 (with latest TWRP) and P6 so I have a few options to try.
Unfortunately I use everyones of the apps you listed which is why i never rooted my zfold 3. The one think Knox gives you is adhell 3 and other similar apps. You can use the Knox firewall as a pretty effective adblocker and to disable system apps/remove permissions and receivers.There's no problem relocking on Samsung either...
You will lose special Samsung secure 'business platform' B2B (Business to Business) features (+ device enrollment for Knox solutions) incl. use of the Knox Security Container when Knox fuse (warranty bit) is blown.
Several Samsung apps and utilities use Knox Security so these will be also be broken including:
- Samsung pay*
- Samsung Pass
- Samsung Health
- Samsung Secure Folder
*Nb. There should be no issue for G Pay/Wallet.
I believe warrant may still be intact depending on local law, but in many lands the warranty will be voided.
Basically:
Likely most users never use the Knox enterprise features and might not need S Pay, S Health etc but need to realise that those features will be lost by flashing custom mods (not simply by unlocking bootloader)... Otherwise they can simply re-lock if and continue using device as before if they wish.
PW
Ooohh, will try that, thanks.
I would therefore need to
fastboot flash init_boot <patched_init_boot.img>correct?
You're welcome! That is exactly correct.
I must say that I totaly hate that warranty bit. No idea why, when relocking the device and wiping the device completely that bit is not reverted to 0x0 to allow the full experience. It's one of the biggest things that I dislike about Samsung devices as I like to root my devices and make roms for themThere's no problem relocking on Samsung either...
You will lose special Samsung secure 'business platform' B2B (Business to Business) features (+ device enrollment for Knox solutions) incl. use of the Knox Security Container when Knox fuse (warranty bit) is blown.
Several Samsung apps and utilities use Knox Security so these will be also be broken including:
- Samsung pay*
- Samsung Pass
- Samsung Health
- Samsung Secure Folder
*Nb. There should be no issue for G Pay/Wallet.
I believe warrant may still be intact depending on local law, but in many lands the warranty will be voided.
Basically:
Likely most users never use the Knox enterprise features and might not need S Pay, S Health etc but need to realise that those features will be lost by flashing custom mods (not simply by unlocking bootloader)... Otherwise they can simply re-lock if and continue using device as before if they wish.
.
Does anybody know what (actually, why it) happened to magisk --path?
AFAIK, it used to point to /dev/<something> but now, with Canary 26102 it points to /debug_ramdisk
Indeed, I can execute the following (commands and responses) on Magisk Delta 25210:
Ie, you see the path to /dev and that I can write to the subfolder
However, on Magisk 26102 it responds with a different path and eventually the subfolder is read-only:
---
I'm asking because I cannot make AML module to work.
It installs but doesn't create and/or populate it's folders with audio conf and xml patched files from eg V4A:
/data/adb/aml
/data/adb/modules/aml/system
It's because its post-fs-data.sh and service.sh scripts at zillion places try to write to the (now) read-only path:
$(magisk --path)/.magisk/modules/aml/system
Even worse, post-fs-data sh strictly assumes it is on /dev/<something>, hence it looks for:
and therefore it obtains a complete b...sht - path to the not-existing folder:
where it cannot read nor write to
Today I tried to adapt the AML scripts and got my modded AML module creating the folders, picking up audio conf and xml files but it breaks me then the V4A
---
Actually, I wanted to install JamesDSP (alongside with V4A and AML) - JamesDSP is also broken on Magisk v26 (reported in the JDSP thread by several users)
Unfortunately, JamesDSP does not have scripts but the logic is in the Java JDSP manager app and I assume (both modules are from the same developer and btw he had disabled reporting of Issues to GitHub
) that it must be a similar problem with the now changed magisk --path on Magisk v26 (JDSP also works fine with Magisk Delta)
However, JamesDSP fails to work on Magisk v26 even if installed as the single/only audio module (hence, without the need for AML)
It creates /data/adb/modules/ainur_jamesdsp/system but doesn't populate with the patched audio files, and when you try to run JDSP manager app, it immediately crashes
---
If some power users could try please the quoted code on their Magisk v26, and maybe also on Alpha v26 (assuming, the wind of change was blowing again from that direction)
And/or, please try AML and JamesDSP modules on your Canary and Alpha v26
Edit:
Script attached for easier testing. Run the script in Terminal, with root privileges
AFAIK, it used to point to /dev/<something> but now, with Canary 26102 it points to /debug_ramdisk
Indeed, I can execute the following (commands and responses) on Magisk Delta 25210:
<cmd>
su
magisk --path
<resp>
/dev/gpjeftludcwoxhw
<cmd>
cd $(magisk --path)/.magisk/modules
pwd
<resp>
/dev/gpjeftludcwoxhw/.magisk/modules
<cmd>
touch MY-TEST-FILE_TO-BE-DELETED
ls MY*
<resp>
MY-TEST-FILE_TO-BE-DELETED
<cmd>
rm MY*
su
magisk --path
<resp>
/dev/gpjeftludcwoxhw
<cmd>
cd $(magisk --path)/.magisk/modules
pwd
<resp>
/dev/gpjeftludcwoxhw/.magisk/modules
<cmd>
touch MY-TEST-FILE_TO-BE-DELETED
ls MY*
<resp>
MY-TEST-FILE_TO-BE-DELETED
<cmd>
rm MY*
Ie, you see the path to /dev and that I can write to the subfolder
However, on Magisk 26102 it responds with a different path and eventually the subfolder is read-only:
<cmd>
su
magisk --path
<resp>
/debug_ramdisk
<cmd>
cd $(magisk --path)/.magisk/modules
pwd
<resp>
/debug_ramdisk/.magisk/modules
<cmd>
touch MY-TEST-FILE_TO-BE-DELETED
<resp>
Read-only file system
<cmd>
ls MY*
<resp>
ls: MY*: No such file or directory
su
magisk --path
<resp>
/debug_ramdisk
<cmd>
cd $(magisk --path)/.magisk/modules
pwd
<resp>
/debug_ramdisk/.magisk/modules
<cmd>
touch MY-TEST-FILE_TO-BE-DELETED
<resp>
Read-only file system
<cmd>
ls MY*
<resp>
ls: MY*: No such file or directory
---
I'm asking because I cannot make AML module to work.
It installs but doesn't create and/or populate it's folders with audio conf and xml patched files from eg V4A:
/data/adb/aml
/data/adb/modules/aml/system
It's because its post-fs-data.sh and service.sh scripts at zillion places try to write to the (now) read-only path:
$(magisk --path)/.magisk/modules/aml/system
Even worse, post-fs-data sh strictly assumes it is on /dev/<something>, hence it looks for:
[ -d "/sbin/.magisk" ] && MAGISKTMP="/sbin/.magisk" || MAGISKTMP="$(find /dev -mindepth 2 -maxdepth 2 -type d -name ".magisk")"
MODPATH=$MAGISKTMP/modules/aml
MODPATH=$MAGISKTMP/modules/aml
and therefore it obtains a complete b...sht - path to the not-existing folder:
<cmd>
echo "$MODPATH"
<resp>
/modules/aml
echo "$MODPATH"
<resp>
/modules/aml
where it cannot read nor write to
Today I tried to adapt the AML scripts and got my modded AML module creating the folders, picking up audio conf and xml files but it breaks me then the V4A
---
Actually, I wanted to install JamesDSP (alongside with V4A and AML) - JamesDSP is also broken on Magisk v26 (reported in the JDSP thread by several users)
Unfortunately, JamesDSP does not have scripts but the logic is in the Java JDSP manager app and I assume (both modules are from the same developer and btw he had disabled reporting of Issues to GitHub
) that it must be a similar problem with the now changed magisk --path on Magisk v26 (JDSP also works fine with Magisk Delta)However, JamesDSP fails to work on Magisk v26 even if installed as the single/only audio module (hence, without the need for AML)
It creates /data/adb/modules/ainur_jamesdsp/system but doesn't populate with the patched audio files, and when you try to run JDSP manager app, it immediately crashes
---
If some power users could try please the quoted code on their Magisk v26, and maybe also on Alpha v26 (assuming, the wind of change was blowing again from that direction
)And/or, please try AML and JamesDSP modules on your Canary and Alpha v26
Edit:
Script attached for easier testing. Run the script in Terminal, with root privileges
Attachments
Last edited:
Not the answer but have you tried the rootless jamesdsp apk? You can use that with or without magisk and can switch between the 2Does anybody know what (actually, why it) happened to magisk --path?
AFAIK, it used to point to /dev/<something> but now, with Canary 26102 it points to /debug_ramdisk
Indeed, I can execute the following (commands and responses) on Magisk Delta 25210:
<cmd>
su
magisk --path
<resp>
/dev/gpjeftludcwoxhw
<cmd>
cd $(magisk --path)/.magisk/modules
pwd
<resp>
/dev/gpjeftludcwoxhw/.magisk/modules
<cmd>
touch MY-TEST-FILE_TO-BE-DELETED
ls MY*
<resp>
MY-TEST-FILE_TO-BE-DELETED
<cmd>
rm MY*
Ie, you see the path to /dev and that I can write to the subfolder
However, on Magisk 26102 it responds with a different path and eventually the subfolder is read-only:
<cmd>
su
magisk --path
<resp>
/debug_ramdisk
<cmd>
cd $(magisk --path)/.magisk/modules
pwd
<resp>
/debug_ramdisk/.magisk/modules
<cmd>
touch MY-TEST-FILE_TO-BE-DELETED
<resp>
Read-only file system
<cmd>
ls MY*
<resp>
ls: MY*: No such file or directory
---
I'm asking because I cannot make AML module to work.
It installs but doesn't create and/or populate it's folders with audio conf and xml patched files from eg V4A:
/data/adb/aml
/data/adb/modules/aml/system
It's because its post-fs-data.sh and service.sh scripts at zillion places try to write to the (now) read-only path:
$(magisk --path)/.magisk/modules/aml/system
Even worse, post-fs-data sh strictly assumes it is on /dev/<something>, hence it looks for:
[ -d "/sbin/.magisk" ] && MAGISKTMP="/sbin/.magisk" || MAGISKTMP="$(find /dev -mindepth 2 -maxdepth 2 -type d -name ".magisk")"
MODPATH=$MAGISKTMP/modules/aml
and therefore it obtains a complete b...sht - path to the not-existing folder:
<cmd>
echo "$MODPATH"
<resp>
/modules/aml
where it cannot read nor write to
Today I tried to adapt the AML scripts and got my modded AML module creating the folders, picking up audio conf and xml files but it breaks me then the V4A
---
Actually, I wanted to install JamesDSP (alongside with V4A and AML) - JamesDSP is also broken on Magisk v26 (reported in the JDSP thread by several users)
Unfortunately, JamesDSP does not have scripts but the logic is in the Java JDSP manager app and I assume (both modules are from the same developer and btw he had disabled reporting of Issues to GitHub
However, JamesDSP fails to work on Magisk v26 even if installed as the single/only audio module (hence, without the need for AML)
It creates /data/adb/modules/ainur_jamesdsp/system but doesn't populate with the patched audio files, and when you try to run JDSP manager app, it immediately crashes
---
If some power users could try please the quoted code on their Magisk v26, and maybe also on Alpha v26 (assuming, the wind of change was blowing again from that direction
And/or, please try AML and JamesDSP modules on your Canary and Alpha v26
No I didn't
I have root and I'm not interested in rootless solutions
(And I'm interested to see how/why some things are constantly changed in Magisk in a way that one thing is fixed but the other changed and introducing troubles to the other modules - we are experiencing that since Canary v25207
Although, troubles are dragged here by the code in the AML scripts)
Last edited:
The rootless jamesdsp apk works either with root or adb so it is also a root app. I meant try it to see if it works with magisk or not, if it works at least you can use the module until magisk issue is resolved and you can easily switch back from within the app itselfNo I didn't
I have root and I'm not interested in rootless solutions
(And I'm interested to see how/why some things are constantly changed in Magisk in a way that one thing is fixed but the other changed and introducing troubles to the other modules - we are experiencing that since Canary v25207
Although, troubles are dragged here by the code in the AML scripts)
"New magisk tmp dir: /debug_ramdisk"
Magisk - [GitHub] - commit
Example: Pixel 3a Lineage 19.1
Not sure if it helps but, that was the change.
¯\_(ツ)_/¯
Cheers.
Edit: Seems I've misunderstood the members meaning here (as pointed out in next post), sorry!
FWIW however, you can both re-lock B/L and use stock ROM again and you will have Android like other devices. Samsung just disable their proprietary special knox-based features after device is tampered...
Old Sammy devices did work that way, but now soc makers include e-fuses that utilise physical burn-in on the substrate... I put info on use of q-fuses (Qualcomm) here:
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85146255
Samsung says
I put a number of links here (incl. ref. above):
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85755893
Yup... It's a choice... Much like Google's device integrity APIs and key attestation models really... They're doing that because they must compete in the secure Mobile OS arena in today's climate, and are loosing to IOS in the enterprise/corporate marketplace because of the (justified) perception that Android is largely insecure...It's one of the biggest things that I dislike about Samsung devices as I like to root my devices and make roms for them
Samsung want to position themselves as a credible alternative to IOS/iPhone and as the leading manufacturer of property secure Android devices in this market too as the (somewhat outdated) links above show...
The difference in these approaches (ie. Google doesn't penalise modders by making the restoration of some device features impossible while Samsung does) may indicate that Google is more supportive of the modding community than is Samsung... I don't know if Sammy encourage custom modders in any way other than allowing B/L unlock... But it's still far more generous that what IOS will offer you!
PW
Last edited:
What I said was once you root something's will never work again which isStill, you said
which is just not true. You can both re-lock B/L and use stock ROM again and you will have Android like other devices. Samsung just disable their proprietary special knox-based features after device is tampered...
Old Sammy devices did work that way, but now soc makers include e-fuses that utilise physical burn-in on the substrate... I put info on use of q-fuses (Qualcomm) here:
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85146255
Samsung says
I put a number of links here (incl. ref. above):
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-85755893
Yup... It's a choice... Much like Google's device integrity APIs and key attestation models really... They're doing that because they must compete in the secure Mobile OS arena in today's climate, and are loosing to IOS in the enterprise/corporate marketplace because of the (justified) perception that Android is largely insecure...
Samsung want to position themselves as a credible alternative to IOS/iPhone and as the leading manufacturer of property secure Android devices in this market too as the (somewhat outdated) links above show...
The difference in these approaches (ie. Google doesn't penalise modders by making the restoration of some device features impossible while Samsung does) may indicate that Google is more supportive of the modding community than is Samsung... I don't know if Sammy encourage custom modders in any way other than allowing B/L unlock... But it's still far more generous that what IOS will offer you!
CORRECT. Of course you can relock bootloader but it won't fix the apps that will never work again and that was my point ffsAh... Sorry.What I said was once you root something's will never work again which is
I'd read
to mean you 'can't relock bootloader and go back to stock on Sammy once you trip Knox, and that's something that will never ever work again' rather than 'If you relock bootloader and go to back stock on Sammy, once you trip Knox some things will never ever work again'!...
I probably should have asked you to clarify that, sorry mate... PW
Last edited:
https://forum.xda-developers.com/t/...r-root-pixel-7-pro-cheetah-safetynet.4502805/
VERY IMPORTANT - On the Pixel 7/Pro, we use Magisk to patch init_boot.img, NOT boot.img AND we flash the patched init_boot to the init_boot partition - do not flash it to the boot partition.
Apparently, there was also a change in the $MAGISKTMP variable (available during the Installation of Magisk modules):"New magisk tmp dir: /debug_ramdisk"
Magisk - [GitHub] - commit
Example: Pixel 3a Lineage 19.1
Not sure if it helps but, that was the change.
¯\_(ツ)_/¯
Cheers.
In Magisk v26 it points to magisk --path (the new path), in the older Magisk versions it pointed to the subfolder .magisk of the old magisk --path
Nevertheless, I made the modifications that both AML and JamesDSP modules can now work also on Magisk v26 (zip installations attached in the quoted post):
https://forum.xda-developers.com/t/jamesdsp-audio-manager-mmt-ex.3607970/post-88598223
Attachments
Similar threads
Top Liked Posts
-
4
That's not the point. The point is it was an obvious thing to check, I never thought of it, @iruiz2 did, and I would have liked to be able to paste glitter and unicorns all over his post to express how much I Liked it.
You, on the other hand, can expect coal in your stocking.1
Just to make sure... Did you test your SIM card is working on another phone, and that another SIM card is not working on yours?1
Yes I literally walked into a T MOBILE store and the employee put the same sim card into a display phone and it worked normally, even that same phone showing up on my T-Mobile account1
How "did nothing"?
If "did nothing", how "completed uninstall"?
And what then is "unrooted"?
I will grant you that factory reset almost certainly removed the remnants about which I was concerned.
Maybe instead of wasting more time trying to get you to explain what you did, just follow the instructions you have been given repeatedly:
- flash the stock ROM
- confirm that the SIM related functions work
- install a Magisk manager app
- patch the boot image (and please make sure that it is the boot image from the stock ROM; and if your device/ROM is one where you need to patch something other than boot.img, patch the right thing, don't patch or flash the wrong thing; remember to uncheck the Recovery option if you have one)
- flash the appropriate patched file
- test the SIM related functions
And please stop saying that your phone is "locked". Unless you have relocked your bootloader. In which case, I'm done.1
If Restore Images "did nothing", I suspect Complete Uninstall, which includes Restore Images, will have failed with errors also...
Please say if you did anything more to restore unpatched images because it isn't clear...
Despite 'losing root', before concluding your device is properly returned to stock in the event that Uninstall options don't work, you need to (properly) flash back boot.img or full ROM via fastboot or similar 'download' mode... PW -
8
I miss the days when I could just use adb to dump the data partition into an image file and flash it back. 😿️<SNIP>
Since it's not available without unlocking, 'anyone who dumps partitions / performs nandroid' has to agree to modify the device by unlocking which changes original product features including disabling security functions and other features... Then they generally install a custom (modified) recovery...
<SNIP>
Better yet, when I could wipe system, install a different OS version and leave userdata alone.
[The original Clean/Dirty flash install.] 🙃️
As for the Cat and Mouse game...
My money is on the Mice. 😜️
"Look, sorry - are we talking about the little white furry things with the cheese fixation and women standing on tables screaming in early sixties sit coms?"
Slartibartfast coughed politely.
"These creatures you call mice, you see, they are not quite as they appear. They are merely the protrusion into our dimension of vast hyperintelligent pandimensional beings. The whole business with the cheese and the squeaking is just a front."
― Douglas Adams, The Hitchhiker's Guide to the Galaxy
Cheers all.
PS.
I miss FlashFire. 😥️8
Yeah... And Microsoft should have stayed with DOS, and maybe Windows as a DOS add-on!...
That's certainly NOT their intention...
There's a lot to be said for new innovations and OEM requirements both in the mart of competitive commerce and for the value -added benefits to general Android users...
Just as a few examples,
• SAR/2SI enhancements allow for A/B partitioning and 'seamless' (streamed) delta OTA updates,
• Shared blocks architecture allows for dynamic sup-super partitions which may be RO but are resizable with no unused space, upgradable to larger /system etc in future and space optimised/saving etc,
• Project Treble (Android 8+)
https://www.xda-developers.com/goog...ze-android-so-oems-can-update-devices-faster/
modularised Android so that OEMs can serve Android updates more quickly by reducing OEM dependence on SoC vendors for every single OS update and introduced a new 'vendor interface' and Vendor Test Suite (VTS)... It also facilitated
• The GSI Project (Android 9+)
https://developer.android.com/topic/generic-system-image
which allows app developers to install and run the latest Android Generic System Images to perform app testing on a variety of existing Android devices, and use GSIs from different Android OS release stages... Extra benefits include:
- Broader test coverage on a greater set of real devices
- More time to fix app compatibility issues
- More opportunities to fix compatibility issues in Android that are reported by app developers
• Project Mainline (Android 10+)
https://www.xda-developers.com/android-q-project-mainline-security/
(modules
https://www.xda-developers.com/android-project-mainline-modules-explanation/
expands on Treble's modularisation to further address fragmentation, adding Android Pony EXpress update packages to allow updating system modules (APEX includes all needed libraries, ART, HALs and precompiled code on addition to apps) through Google Play in Android 10 and 25 new modules with A11, as well as reducing how dependent Google is on OEMs for delivering security updates to key OS components. It also facilitated
• The GKI Project (Android 11+)
https://source.android.com/docs/core/architecture/kernel/generic-kernel-image
with its Generic Kernel Image is an essential change aimed addressing the issue/costs of fragmentation which "has several negative effects on the Android community". GKI/Mainline reductions in fragmentation thus:
- Make security updates less labor intensive
- Allow merging Long-Term Supported updates
- Removes factors that Inhibit Android platform release upgrades
- Allows easier contribution of kernel changes back to upstream Linux
So Treble and Mainline, with their GSI and GKI changes/requirements, are initiatives to facilitate easier updates for vendors, give incentive to support devices much longer, etc.
Google is in the business of promoting it's mobile OS and producing development milestones that reduce costs, improve efficiency, lifecycle, specs etc for OEMs and end users in order to stay competitive, relevant, innovative and appealing... And they make major architectural changes for these reasons...
They aren't in the game of "making it more and more difficult to get TWRP and OrangeFox working"; they appreciate these efforts but (quite reasonably) have the (different) priorities mentioned above...
Just as with Magisk injection, there is much pressure on Dee's Troy and team (and other custom recovery teams) to get TWRP functioning properly, let alone to mount and decrypt user data with an ever changing Android architecture, but there are clearly more complex considerations than for simple Magisk injection... Even so, Google allows and even supports such custom mod efforts...
Moreover it's not Google's fault that community projects like TeamWin find it difficult to devote the time, conscript the Devs or otherwise overcome obstacles needed to properly support new Android iterations... They actually supply clear documentation as part of AOSP for these changes to benefit all Android devs, whether OEMs, app makers or custom modders...
I don't really know why TWRP has not progressed past Oct 2022 3.7.0 A12 base builds at this time despite the fact that 'Android 13 development had started' already, but the difficulty they have keeping up is not new... I note that everything there is still © 2014 to 2022, also that:
https://twrp.me/about/
and that, just as when Dees Troy lamented that 'real life' was preventing TWRP keeping pace, the four base team members are still appealing for volunteers:
-----
Despite the difficulty the TWRP four have keeping up with the Google juggernaut, apparently many devices running A13+ have at least unofficial TWRP support with working decryption. Some won't allow permanent flashing but temp booting TWRP works nonetheless, and some have other issues...
Re devices launched with Android 13:
Just on Thursday, Dev @Nebrassy posted a TWRP build for OnePlus 11 which is apparently working despite some niggles:
https://forum.xda-developers.com/t/recovery-12-unofficial-teamwin-recovery-project.4625181/
This device has dedicated /recovery_a and /recovery_b partitions and Qualcomm SoC, and the Dev doesn't even own the device...
For Pixel 7 series, the delay getting TWRP w/ decryption working seems to be Tensor SoC / device tree syncing and possibly StrongBox / KeyMint / Titan chip implementation(?) rather than general Android Architectural changes and initiatives.
However, just yesterday @Wishmasterflo posted a test build of OrangeFox recovery (this is "synced with the latest Teamwin changes", and originally from a Dev who later joined LineageOS) for the Pixel 7a:
https://forum.xda-developers.com/t/...g-thats-being-worked-on.4532237/post-88986509
Nb. The Dev cannot test ATM as his device is still locked...
Pixel 7a users: If someone tests and this works, I'm sure custom recovery support for Pixel 7 series devices will gain momentum...
Takers?
-----
... FWIW, some modders will experiment/toy with the latest devices / Android versions as soon as they arrive... Others will stay with old tech because of affordability but migrate ASAP... Still others will refrain as long as possible, whether out of nostalgia or for other reasons...
Similarly, some car drivers will migrate to EVs quickly... Others will when the price point is more agreeable... Still others will refrain as long as possible, and some will hanker for the ICE age with the smell of petrol and the roar of engines long after it's gone!
Personally, despite not being able to afford a Tesla yet, I think auto makers in general have not moved to new tech nearly fast enough!...I expect them to continue to "enhance" transportation options as time goes on however... And I cannot be unhappy when phone market leaders adapt, innovate and move with the times either...
Just might be able to get me a 2nd hand P7Pro now that the P8's in the wind, and wire a fast-charge outlet into the dash of the ol Ford Perfect... PW4
Actually, full nandroid backups are quite helpful for non-modders, as well.
Consider the following ...
A typical non-modding Android user on a standard, factory, non-rooted ROM on a standard Android-approved device applies standard, approved OTA updates when they are offered.
But after one such OTA is successfully applied, the user then realizes that the system has been modified in one or more ways that he or she doesn't like, and the user therefore wants to roll back the OTA update.
If there was a utility which would have allowed the user to have taken a full nandroid-like backup right before initiating the OTA update, he or she could then easily and relatively quickly use that utility to restore the system back to the exact state it was in right before the OTA.
Again, I'm not saying that Google SHOULD offer a such nandroid-like backup/restore utility, but it certainly would be nice to have. And if such a standard Android utility was offered by Google, this would save countless person-hours of development efforts for the creation of numerous versions of TWRP and OrangeFox for all the various device/OS-version combinations out there.
But this is little more than a pipe dream, given that Google is extremely unlikely to ever offer such a thing.4
I never said that I believe that to be intentional.
It's just one of the unintended consequences of Google's continued "improvements" (ha ha!) of Android coupled with the increased usage by more and more developers of root-blocking and mod-blocking technologies.
Yes, Google is in business to make money with its advertising dissemination and with devices and OS's and services which facilitate that. They have a right to make money in this way and in countless other ways that they might choose. And developers have the right to choose how to make money with their own apps, as well.
It's just that Google's and many developers' Android-related products and services continue to grow increasingly unappealing to me.
I still find Android to be less onerous than iOS, but the undesirability gap between them continues to get narrower and narrower for me.4
Yeah... in Australia you should be sure to meet Gumtree electronics vendor in the middle of a busy shopping mall!... In Asian countries this is even more imperative... PW -
1100This 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 Thread156Hello, 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
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
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!!121Ah, 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.76Thread 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.75Hello 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
