In the past couple years, magisk has come a long ways to the point that it's the de-facto root solution. I have been developing and maintaining the Unity template for the past couple years but it's now reached a point where there's no longer a need for it - it's simply not worth the effort anymore. There are very few use cases where someone would want to stay rootless and still install a bunch of mods and every other root solution is pretty much deprecated at this point. So I switched gears from Unity to a magisk only template.
Consider this the spiritual successor of the Unity Template
So what is Magisk Module Template Extended (MMT-Ex)?
MMT-Ex is just as the name describes - it's the magisk module template but with the best features of Unity added to it
What does this mean?
This means that MMT-Ex is an easy way to make a magisk module regardless of how basic or advanced it is.
Where do I start?
Follow the readme on the main repo here and you'll be setup in no time
Questions?
Post them here, I'll try to help out when I have the chance but hopefully you won't have any
So much for the smooth release. Small bug fix pushed
@Zackptg5 I write here since there's no issue section in the repo, but there are two uninstall.sh files, one in common and the other one in the main directory, I think that's a bit confusing.
My ideas would be:
-merge the two files;
- rename the one in common in remove.sh , MMT-exuninstall.sh or similar names
MarcAnt01 said:
@Zackptg5 I write here since there's no issue section in the repo, but there are two uninstall.sh files, one in common and the other one in the main directory, I think that's a bit confusing.
My ideas would be:
-merge the two files;
- rename the one in common in remove.sh , MMT-exuninstall.sh or similar names
Click to expand...
Click to collapse
I could do a better drop explaining things in the wiki
The one in root gets copied as is to modpath and will uninstall any files outside modpath if removed via magisk manager
The one in common is like the old unity_uninstall one. The only reason I had the common ones named unity_whatever back in the day is because one of the past magisk module templates unzipped everything with the -j option (ignores directories) and so files would overwrite each other if they had the same name
I disabled issues on most of my repos because noobs would post stupid stuff on it so I redirected all support to here instead
Zackptg5 said:
I could do a better drop explaining things in the wiki
The one in root gets copied as is to modpath and will uninstall any files outside modpath if removed via magisk manager
The one in common is like the old unity_uninstall one. The only reason I had the common ones named unity_whatever back in the day is because one of the past magisk module templates unzipped everything with the -j option (ignores directories) and so files would overwrite each other if they had the same name
I disabled issues on most of my repos because noobs would post stupid stuff on it so I redirected all support to here instead
Click to expand...
Click to collapse
So far so good here.
@Zackptg5 it appears system.prop and sepolicy.rule still need to be placed in the root of the mod, and not in common in order to propagate on-device.
Which is fine, as i know thats how to fix it. But wasnt sure if that was your intent, it sounds like you want everything running script-wise out of common (which makes sense). Attached my magisk log, and my mod has a new sepolicy.rule and system.prop. I tried this the way i maentioned above and every loads as it should.
Hello, if I develop a Module with your template, I will be able to install it on my device. But I don't think it will be accepted as a valid module submission here (https://github.com/Magisk-Modules-Repo/submission/issues) because it does not respect the new module format.
Can you confirm?
aer0zer0 said:
@Zackptg5 it appears system.prop and sepolicy.rule still need to be placed in the root of the mod, and not in common in order to propagate on-device.
Which is fine, as i know thats how to fix it. But wasnt sure if that was your intent, it sounds like you want everything running script-wise out of common (which makes sense). Attached my magisk log, and my mod has a new sepolicy.rule and system.prop. I tried this the way i maentioned above and every loads as it should.
Click to expand...
Click to collapse
Common folder scripts should copy over but I've seen this issue in another module. I'll look into it later this week when I'm off work
lapwat said:
Hello, if I develop a Module with your template, I will be able to install it on my device. But I don't think it will be accepted as a valid module submission here (https://github.com/Magisk-Modules-Repo/submission/issues) because it does not respect the new module format.
Can you confirm?
Click to expand...
Click to collapse
mmtex is the new template with some modifications so you shouldn't have any problems there
DELETED
lapwat said:
I don't understand because on the Developer Guides there isn't any common folder anymore: https://topjohnwu.github.io/Magisk/guides.html
Click to expand...
Click to collapse
That's on of the modifications I made although there appears to be a bug with it that I'll need to work out
Zackptg5 said:
That's on of the modifications I made although there appears to be a bug with it that I'll need to work out
Click to expand...
Click to collapse
If I was to guess it would be something in lines 208-214 of the functions.sh. but I'm way to stoned to be of any actual assistance.
Edit: Clearly too stoned. I meant to reply to the system.prop not being applied when in common not what I actually replied to lol
Found the problem real quick. Seems I mixed up Unity with MMT-Ex logic:
The main boot scripts and such (service.sh, post-fs-data.sh, sepolicy.rule, and system.prop) should all be in root of installer like with regular template. Any extras can go into common. I'll push an update to the wiki on that shortly
Zackptg5 said:
Found the problem real quick. Seems I mixed up Unity with MMT-Ex logic:
The main boot scripts and such (service.sh, post-fs-data.sh, sepolicy.rule, and system.prop) should all be in root of installer like with regular template. Any extras can go into common. I'll push an update to the wiki on that shortly
Click to expand...
Click to collapse
That was my second guess!
Zackptg5 said:
Found the problem real quick. Seems I mixed up Unity with MMT-Ex logic:
The main boot scripts and such (service.sh, post-fs-data.sh, sepolicy.rule, and system.prop) should all be in root of installer like with regular template. Any extras can go into common. I'll push an update to the wiki on that shortly
Click to expand...
Click to collapse
that did the trick, much appreciated.
Updated MMT-Ex to v1.1! Been pushing some fixes for a while now and I feel like it's good to go for the next version. See the wiki for changelog: https://github.com/Zackptg5/MMT-Extended/wiki/Changelog
Subscribed. Appreciate your efforts!
Minimun Magisk version?
panchogg said:
Minimun Magisk version?
Click to expand...
Click to collapse
It follows official magisk template so 19 is minimum currently
MMT-Ex has been updated to v1.2! I anticipate this being the last update for a while unless something comes up - think I got it at a good state.
Changelog can be found same place as always: https://github.com/Zackptg5/MMT-Extended/wiki/Changelog
Some notable changes are:
MMT-Ex now has the same behavior as mainstream magisk module template - it always uninstalls/installs Furthermore, to simplify things, it'll only work in magisk manager. If you flash it in TWRP, it'll trigger automatic removal - this was kept in as a save from a module causing a bootloop
common/uninstall and upgrade scripts are gone now - no need for them anymore. There are very few instances where you'd need custom uninstall logic now since MMT-Ex handles all file removal automatically but if you do have something, you can place it in the TOP of the uninstall file at root of installer
ORIGVEN variable is gone - turns out that original vendor is always $ORIGDIR/vendor so you can just use that
Zackptg5 said:
MMT-Ex has been updated to v1.2! I anticipate this being the last update for a while unless something comes up - think I got it at a good state.
Changelog can be found same place as always: https://github.com/Zackptg5/MMT-Extended/wiki/Changelog
Some notable changes are:
MMT-Ex now has the same behavior as mainstream magisk module template - it always uninstalls/installs Furthermore, to simplify things, it'll only work in magisk manager. If you flash it in TWRP, it'll trigger automatic removal - this was kept in as a save from a module causing a bootloop
common/uninstall and upgrade scripts are gone now - no need for them anymore. There are very few instances where you'd need custom uninstall logic now since MMT-Ex handles all file removal automatically but if you do have something, you can place it in the TOP of the uninstall file at root of installer
ORIGVEN variable is gone - turns out that original vendor is always $ORIGDIR/vendor so you can just use that
Click to expand...
Click to collapse
Took you a while to find a proper avatar..
Related
[TERMINAL] DEBLOATER
Debloat your phone Systemlessly! Debloating can sometimes be device specific. OEM apps can sometimes be a trash to a user but not to the other. So I decided to make a module to Customize the uninstallation of a system app (in Magisk) with a UI in Terminal emulator. So you can help yourself in uninstalling your own bloat![/SIZE]
How to use:
Flash in a recovery
Go to Terminal emulator or adb shell (use -nc, refer below)
Type su and enter
Code:
debloat
or use the command line for ease of use or other stuff
Select the apps to uninstall (systemless!). But remember that the names of the apps won't be accurate (like Velvet which is actually the Google app) if you have no aapt in your system.
** Use the options
Enter
Code:
debloat -h
and it will be pretty easy to understand.
** How to debloat multiple apps
Enter multiple numbers. That's it.
For example, enter 1 18 25 24 56. That would debloat the apps with the corresponding number in the listed apps shown to you in the menu.
** If you have a blank list of apps, or want to use ADB Shell, use -nc.
Code:
debloat -nc
** Uploading logs
Go to the menu and type `logs`, this will upload the log files of this module and will generate a link. Send that
Alternatively, Send `/cache/terminal_debloater-verbose.log` here. I'll examine it for problems and will try to fix it.
Short video guide:
Download here or at Magisk Manager
GitHub
Changelogs
Telegram Channel
Notification Channel
DONATE? If you want to (ﾉ･ω･)ﾉﾞ
LIST OF ALL SH*TTY APPS BY OEMs
All ****ty LG apps
by @popy2006
All ****ty T-Mobile LG apps
by @famewolf
Give me a list to be posted here ?
F.A.Q
Q. How does this work?
A. To put it simply, debloat is a script magic mounted in /system/bin ($PATH variable) so that it can be executed directly in Terminal Emulator and present you with a "UI" that you can interact with to uninstall System Apps.
Q. Are the apps frozen or uninstalled?
A. They're uninstalled. To put it simply, the apk files in /system are replaced by a blank file, which basically removes/uninstalls them from /system.
Q. How does the Reinstall option work?
A. It removes the blank files used to replace to apk files in /system. Which brings the apk back after a reboot. Basically the same thing that happens when you disable/uninstall a Magisk module. Q. Some kind of error popped out, what do I do?
A. Type logs in the menu then send the link generated or send me these files: /cache/terminal_debloater.log and /cache/terminal_debloater-verbose.log ; so I can look for the bug :good:
Q. I accidentally uninstalled an important system app (e.g. System UI) and got in a bootloop, what do I do?
A. Simple, mount magisk from here. Then delete the app folder of the system app you've uninstalled in /sbin/.core/img/terminal_debloater/system/app or /sbin/.core/img/terminal_debloater/system/priv-app then that should undo it
Q. Apps are still in the app drawer after debloating...
A. You can then uninstall them like a normal user app.
Here's a little video tutorial on how to use this module by @Truant_Luce
Nice! One for the repo, I'd say!
Should probably warn the user a bit clearer that the list won't always accurately reflect the name of the app they're looking for... You'll probably get a lot of questions about it anyway (taking into account the average users indisposition towards reading instructions), but still.
Didgeridoohan said:
Nice! One for the repo, I'd say!
Should probably warn the user a bit clearer that the list won't always accurately reflect the name of the app they're looking for... You'll probably get a lot of questions about it anyway (taking into account the average users indisposition towards reading instructions), but still.
Click to expand...
Click to collapse
Thanks. Should have probably added that from the beginning.
I'll submit it to the repo soon
@veez21 check lines 99 and 126:
mktouch $MODDIR${app[$(($app))]}/.replace
mktouch $MODDIR${privapp[$((privapp))]}/.replace
crusader727 said:
@veez21 check lines 99 and 126:
mktouch $MODDIR${app[$(($app))]}/.replace
mktouch $MODDIR${privapp[$((privapp))]}/.replace
Click to expand...
Click to collapse
There was supposed to be something else in there ( a difference between another variable) and i removed it. But it still works like that. Try it and tell me if there are errors
veez21 said:
There was supposed to be something else in there ( a difference between another variable) and i removed it. But it still works like that. Try it and tell me if there are errors
Click to expand...
Click to collapse
I was wondering if someone would make a debloater. Great job!
Great think, gonna test it tomorrow
Thank you very much !!
Would you be able to create a module to hide apps (user/system) from the pixel launcher?
If yes, would it be much work to do?
Gratefully
Blade
BIade said:
Great think, gonna test it tomorrow
Thank you very much !!
Would you be able to create a module to hide apps (user/system) from the pixel launcher?
If yes, would it be much work to do?
Gratefully
Blade
Click to expand...
Click to collapse
I don't know. But I'll look into it
Screenshots please!
Can someone post some screenshots of the module in action?
Thank you. Can I debloat them and install some of them back as the user app from the play store..?
min9ox2 said:
Thank you. Can I debloat them and install some of them back as the user app from the play store..?
Click to expand...
Click to collapse
Yes you can
Git link added in the OP!
Added git link and submitted it to the repo. Hope it gets accepted soon
https://github.com/veez21/terminal_debloater_magisk
I keep getting this when I try it. Anything I'm not doing right? The app does have root permissions. But not too familiar with working with terminals.
Great module, was thinking of making one myself.
What about incorporating something of the functionality of App Inspector so that the terminal display shows both display name and package name?
Telperion said:
Great module, was thinking of making one myself.
What about incorporating something of the functionality of App Inspector so that the terminal display shows both display name and package name?
Click to expand...
Click to collapse
Its actually in the next version I'll update in just a sec
Truant_Luce said:
I keep getting this when I try it. Anything I'm not doing right? The app does have root permissions. But not too familiar with working with terminals.
Click to expand...
Click to collapse
Did you type su before debloat_magisk? If not then type su first
Updated to v2! Changes are significantly related to UX.
CHANGELOG:
UI Improved a bit
Now shows the name of the app! (if aapt binary is present in /system)
Now hides uninstalled apps!
Added Reinstall Apps (but not working just yet don't try it for now)
Code Optimizations
Download here or in the OP
Git - later
Note: Updating removes all the files in the module, so all the uninstalled apps will be reinstalled. That's a magisk problem
THIS PROJECT IS NO LONGER SUPPORTED.
# MagicGApps
## Copyright (C) 2017-2018, VR25 @ xda-developers
### License: GPL v3+
---
#### DISCLAIMER
This software is provided as is, in the hope that it will be useful, but without any warranty. Always read/reread this reference prior to installing/upgrading. While no cats have been harmed, I assume no responsibility under anything which might go wrong due to the use/misuse of it.
A copy of the GNU General Public License, version 3 or newer ships with every build. Please, read it prior to using, modifying and/or sharing any part of this work.
To prevent fraud, DO NOT mirror any link associated with this project.
---
#### DESCRIPTION
- This module installs a regular open_gapps-* zip (except aroma variant) systemlessly. When it's disabled, Google Play Services are automatically disabled on the next boot as well. This prevents continuous, disturbing gms crashes.
---
#### PRE-REQUISITES
- Any open_gapps-* zip, except aroma variant
- Custom recovery
- Magisk
---
#### SETUP STEPS
0. Make sure an open_gapps-* zip (except aroma variant) exists somewhere in /sdcard or /external_sd directories or subdirectories (max directory depth must be 3 -- i.e., /sdcard/Download/OpenGApps).
1. Optional -- run `touch /data/r` to
reinstall open_gapps-* zip (or `touch
/data/u` to uninstall the module).
2. Optional -- set up a gapps-config.txt file (removal lists work as pseudo-removal lists -- systemless debloat).
3. Install from custom recovery (i.e., TWRP).
---
#### LINKS
- [Facebook Support Page](https://facebook.com/VR25-at-xda-developers-258150974794782)
- [Git Repository](https://github.com/Magisk-Modules-Repo/MagicGApps)
- [XDA Thread](https://forum.xda-developers.com/apps/magisk/module-systemless-beansgapps-mini-7-1-x-t3611362)
- [webview_packages: fix incorrect signatures]( https://github.com/LineageOS/android_vendor_cm/commit/a3a76f5d1cc233ad8024ffdc74bb3a786e1605c3)
---
#### LATEST CHANGES
**2018.9.23 (201809230)**
- Max OpenGApps search directory depth set to 3 for faster speed.
- Support for latest Magisk versions
- Updated documentation
- Use /dev/urandom over /dev/random.
- Use Magisk imgtool over make_ext4fs and resize2fs.
**2018.8.12 (201808120)**
- Added GMS Manager script -- automatically enables/disables Google Play Services when MagicGApps is enabled/disabled; self-remove when MagicGApps is uninstalled
- Updated module description
**2018.8.11 (201808110)**
- Fixed GApps runtime permission issues
- Fixed "make_ext4fs not found" (devices running Android P)
- Let Open GApps installer use the real /persist
- Major optimizations & cosmetic changes
- Removed `gp` executable
- Updated documentation
Archive
Reserved
++Reserved++
Hey! thanks for all your Magisk mods, I noticed you posted a few in the Collection of Magisk Mods v2 thread.
I'm curious about this one though. What is it for? No offense, I just don't understand why you'd need or want Beans core Gapps to be systemless.
Especially since A) they usually always occupy that space on /system, 2) the /system partition has plenty of room for the mini Gapps (and often much larger packages) after clean installing a ROM, and thirdly I thought the whole point of Magisk and systemlessness was to have an intact and "normal" /system.
Being able to hide root is one of the coolest things about Magisk, closely followed by installing modules "systemlessly", where they don't actually take up space on your system partition but act like they do.
In essence, I think my point is that I assumed Magisk systemlessness is designed for quite the opposite purpose of this mod. Why have empty room on your system partition (where the Gapps usually reside) AND have the ability to use systemless mods -- which inherently don't utilize the system partition, by design?
tl;dr:
If you're using Magisk for "systemlessness", why leave unused space on the system partition? If the Gapps are stored on /data, you have less usable space on the device.
Again, I mean no offense. The more I think about it the less sense it makes to me. Please explain why you made this and what its advantages are! I would love to understand.
Sent from my Nexus 6P using Tapatalk
borxnx said:
Hey! thanks for all your Magisk mods, I noticed you posted a few in the Collection of Magisk Mods v2 thread.
I'm curious about this one though. What is it for? No offense, I just don't understand why you'd need or want Beans core Gapps to be systemless.
Click to expand...
Click to collapse
First of, thanks for the questioning. I thought somebody would feel confused at some point... and here we go. I just added my reasoning to the main post. You'll love it at best and like it at worst. Guaranteed.
Sorry for OT but, how do you make backup for magisk.img? ?
xkhen0017 said:
Sorry for OT but, how do you make backup for magisk.img? ?
Click to expand...
Click to collapse
The file is located in /data. Use a file manager with root access to copy it to a desired location for future use. I personally use TWRP's built in file manager.
No offense. Some people prefer the Nova launcher instead of the Pixel launcher, so I hope you don't add the pixel launcher
Dope concept and module. Will I be able to manually update Gapps from the Nightly updates, or do I have to wait for you to push from your end?
aocboe said:
No offense. Some people prefer the Nova launcher instead of the Pixel launcher, so I hope you don't add the pixel launcher
Click to expand...
Click to collapse
Thanks for your suggestion. I'll add Nova Launcher in the next version. Now I remember it is actually better than Pixel Launcher anyway.
Mecca EL said:
Dope concept and module. Will I be able to manually update Gapps from the Nightly updates, or do I have to wait for you to push from your end?
Click to expand...
Click to collapse
You either wait or just integrate app updates into system, systemlessly using Titanium Backup. That's the magic of this. However, to be honest, I'm more into it for the other modifications, since apps are updated from Pay Store anyway. Although they aren't integrated into Magisk automatically, you don't really need to worry about that too much.
Two questions:
First, can I just install this module instead of flashing gapps?
Second, can I add app I want systemized to the zip and install it?
Breno Spangler said:
Two questions:
First, can I just install this module instead of flashing gapps?
Second, can I add app I want systemized to the zip and install it?
Click to expand...
Click to collapse
One answer for both: yes.
Note: some apps may not work as system apps, unless you include libraries with them (extra space -- wasteful)
This includes some user apps. I'm open for suggestions.
Edit: I'm working on a script to batch install user apps added to the zip.
Edit 2: @Breno Spangler, the script is ready! Download
Just add your apps to the /data/app folder, remove the PLACEHOLDER file, enjoy.
Can i update the module just by installing new version or do i need to uninstall the old version first? I'm asking because i know that name changes can make software go crazy.
Shished said:
Can i update the module just by installing new version or do i need to uninstall the old version first? I'm asking because i know that name changes can make software go crazy.
Click to expand...
Click to collapse
Yes, you're right about name changes. This name won't change anytime soon without notice. I did change it at first without notice though.
Anyway, only flash without removing the previous version if the names match.
VR25 said:
Thanks for your suggestion. I'll add Nova Launcher in the next version. Now I remember it is actually better than Pixel Launcher anyway.
Click to expand...
Click to collapse
I got nova launcher as default launcher on my rom. Won't it conflict if I install this module? Doesn't it better if you remove it and we can use any launcher we want?
khnoizer said:
I got nova launcher as default launcher on my rom. Won't it conflict if I install this module? Doesn't it better if you remove it and we can use any browser we want without added launcher if we don't use it?
Click to expand...
Click to collapse
Yes it may conflict. You can open the zip, go to system/priv-app directory, and delete NovaLauncher folder.
I'll evaluate your suggestion for the next version.
Edit: @khnoizer, module updated. Check the new info in the main post.
VR25 said:
Yes it may conflict. You can open the zip, go to system/priv-app directory, and delete NovaLauncher folder.
I'll evaluate your suggestion for the next version.
Edit: @khnoizer, module updated. Check the new info in the main post.
Click to expand...
Click to collapse
Nice
stupid question: If flash a ROM that already has GAPPS bundled, that would cause a conflict with this module? Does one or the other win or do things just break.
[deleted]
0xE2 said:
I'm currently working on a way to inject multiple different bootanimations on Samsung phones (because they support both .qmg and .mp4 for some reason). Now to use the video as a bootanimation I need to first get rid of the original bootanimation in /system/media/bootsamsung.qmg by either deleting it or renaming it. This needs to happen at the post-fs stage if I understood the documentation correctly.
Is there a way to do that or is this not possible using Magisk?
Click to expand...
Click to collapse
How Magisk works is that there is no need to remove or rename any files. If you would like to replace the current files, add the files to the replace section of the config.sh file. My module, MidnightCore, supports Samsung's .qmg format, what i do is simply replace the existing file by placing the bootanimation in /system/media. Magisk takes care of the rest. Basically don't remove or rename anything:good:
The thing about bootanimations though is that they need to be loaded much earlier in the boot process. This is done with a post-fs-data script. you can take a look at the one in my module to see what I did. Credits got to @osm0sis though, i got it from there.
Sent from my OnePlus5T using XDA Labs
[deleted]
0xE2 said:
I'm currently working on a way to inject multiple different bootanimations on Samsung phones (because they support both .qmg and .mp4 for some reason). Now to use the video as a bootanimation I need to first get rid of the original bootanimation in /system/media/bootsamsung.qmg by either deleting it or renaming it. This needs to happen at the post-fs stage if I understood the documentation correctly.
Is there a way to do that or is this not possible using Magisk?
Click to expand...
Click to collapse
You can bind mount over the existing one by placing your animation at /cache/magisk_mount/system/media/bootsamsung.qmg. But since it is post-fs mode, you can not delete or rename it, That can only be done at post-fs-data mode.
MCMotherEffin' said:
You can bind mount over the existing one by placing your animation at /cache/magisk_mount/system/media/bootsamsung.qmg. But since it is post-fs mode, you can not delete or rename it, That can only be done at post-fs-data mode.
Click to expand...
Click to collapse
This is what i was referring to @0xE2:good:
Sent from my OnePlus5T using XDA Labs
@OldMid, just to make you aware, there's a plan right now to move the /cache/magisk_mount stuff to /data/adb and have it run at post-fs-data instead of post-fs (which should still be early enough; that's when the bind runs with SuperSU). It hasn't been implemented yet, but probably in the next Magisk beta or so. :good:
osm0sis said:
@OldMid, just to make you aware, there's a plan right now to move the /cache/magisk_mount stuff to /data/adb and have it run at post-fs-data instead of post-fs (which should still be early enough; that's when the bind runs with SuperSU). It hasn't been implemented yet, but probably in the next Magisk beta or so. :good:
Click to expand...
Click to collapse
Hi @osm0sis,
I was planning to create a one single module, say a 'Systemless system modifier', which will let users manage /system and /vendor systemlessly via Magisk. Currently only CLI, I'm not yet mastered the GUI and Java, etc. Is there a plan of shipping such an app along with Magisk to allow users use it rather than creating their own modules ?? Would you recommend I go ahead with my plan ??
MCMotherEffin'
MCMotherEffin' said:
Hi @osm0sis,
I was planning to create a one single module, say a 'Systemless system modifier', which will let users manage /system and /vendor systemlessly via Magisk. Currently only CLI, I'm not yet mastered the GUI and Java, etc. Is there a plan of shipping such an app along with Magisk to allow users use it rather than creating their own modules ?? Would you recommend I go ahead with my plan ??
MCMotherEffin'
Click to expand...
Click to collapse
Well, you can already do that with the /cache/magisk_mount functionality (which will eventually switch to /data/adb as I said). Doesn't need a UI because all you need is a file explorer.
osm0sis said:
@OldMid, just to make you aware, there's a plan right now to move the /cache/magisk_mount stuff to /data/adb and have it run at post-fs-data instead of post-fs (which should still be early enough; that's when the bind runs with SuperSU). It hasn't been implemented yet, but probably in the next Magisk beta or so. :good:
Click to expand...
Click to collapse
That sounds like a step forward. For instance, on my device, there is no cache partition so I'm unable to change my boot animation systemlessly as I've done previously on other devices. I just wanted to know if there's a workaround for it:
oreo27 said:
So I've run into an issue that I can't seem to get past.
I used to replace my old device's boot animation systemlessly by placing a modified version of it in /cache/magisk_mount/system/media/bootanimation.zip but as mentioned in the readme:
- https://github.com/topjohnwu/Magisk/blob/master/docs/details.md#simple-mount-details
And this is exactly the case as my new device is utilizing the A/B partition scheme. However, the readme doesn't state how one can get around this.
In my personal mod (This is not published anywhere except Github) - https://github.com/0reo27/mia1module
0. I've tried as described above (by placing a modified version of it in /cache/magisk_mount/system/media/bootanimation.zip)
1. I've tried replacing the boot animation by simply placing it in the path.
2. I've also tried adding the file into config.sh like so:
Code:
REPLACE="
/system/media/bootanimation.zip
"
However, as far as I understand, this is only for entire directories.
Perhaps someone can point me in the right direction?
Click to expand...
Click to collapse
DELETED
osm0sis said:
@OldMid, just to make you aware, there's a plan right now to move the /cache/magisk_mount stuff to /data/adb and have it run at post-fs-data instead of post-fs (which should still be early enough; that's when the bind runs with SuperSU). It hasn't been implemented yet, but probably in the next Magisk beta or so. :good:
Click to expand...
Click to collapse
Interesting, appreciate the heads up!
Sent from my OnePlus5T using XDA Labs
Root Explorer & AutoRun Receiver modification How to? (Going from SuperSu to Magisk)
I'm old school, using SuperSu, looking at a new phone will have to use Magisk. I understand it is systemless still unsure if i can do what I did prior with SuperSu like running root explorer and making changes to the system partition files does not appear to be as simple as it was with SuperSu. A thread mentioned that a module is needed. Can someone explain to me in detail what is required to make a change to a system file and if my understanding is correct I can't just fire up Root Explorer and make the changes on the fly?
This also ties to other apps like AutoRun which I use to manage all the receivers for all the apps and system apps. How can this be achieved with Magisk which is systemless root?
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
..
Didgeridoohan said:
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
Click to expand...
Click to collapse
Thanks for that explanation, coming from SuperSu and reading the different threads and articles really does cause confusion.
So if I understand correctly, if I buy an S10, root it per the instructions i can use Root Explorer and Autorun & AdAway for example to make changes to system files and it will behave the same as SuperSu on older platforms?
You mentioned the benefits of systemless modifications is easy to revert, i guess for those that don't document changes or make a backup this is a benefit but i do both so it wouldn't make much sense for me.
But you touched on something important about sticking across system updates. If I manually edit the system files like I do in SuperSu, doesn't that render system updates obsolete because the phone is now rooted and system files have been modified and OTA updates no longer work? I assume by updates you mean manual updates and not OTA so I just want to confirm.
Another question regarding manually changing system files how does that affect SafetyNet checks and Magisk ability to Hide root from banking apps. Would these still work if I use root explorer, AutoRun & Adaway for example?
Thanks a lot
Correct, I'm talking about manual updates, not OTA (which won't work with a modified /system).
Most system edits you do will still make it possible to pass SafetyNet, but that all depends on what kind of edit you do. I don't have an example of any kind of edit that would trigger it though, so generally you should be safe.
There's actually another very good reason to start doing systemless modifications... From what @topjohnwu has been telling me it's actually going to be impossible to do manual modifications of /system starting from Android Q. I'm not even going to pretend to understand it all, but that's what he's apparently found while looking into rooting the Pixel 3/3XL on Q. It might not happen on all devices updating to Q (and knowing Samsung they'll likely come up with some sort of hybrid solution of their own), but that seems to be the future of Android modding.
arf8 said:
Thanks for that explanation, coming from SuperSu and reading the different threads and articles really does cause confusion.
So if I understand correctly, if I buy an S10, root it per the instructions i can use Root Explorer and Autorun & AdAway for example to make changes to system files and it will behave the same as SuperSu on older platforms?
You mentioned the benefits of systemless modifications is easy to revert, i guess for those that don't document changes or make a backup this is a benefit but i do both so it wouldn't make much sense for me.
But you touched on something important about sticking across system updates. If I manually edit the system files like I do in SuperSu, doesn't that render system updates obsolete because the phone is now rooted and system files have been modified and OTA updates no longer work? I assume by updates you mean manual updates and not OTA so I just want to confirm.
Another question regarding manually changing system files how does that affect SafetyNet checks and Magisk ability to Hide root from banking apps. Would these still work if I use root explorer, AutoRun & Adaway for example?
Thanks a lot
Click to expand...
Click to collapse
Generally speaking if you touch (actual) system files you'll not pass SafetyNet anymore. Neither will be able to do OTA updates. Besides that you'll have to reapply all your changes if you update system manually.
That's where Magisk comes. During boot Magisk builds a new system and apply the changes (with modules) that you want on it, not touching the actual device system files. This is the "systemless" concept.
For instance on Magisk there's an option (a module) that will let edit hosts file systemless. That way you can use AdAway without problems, its hosts file will be replacing Magisk system hosts, but not the actual device system hosts.
In a nut shell and simple words it is this way:
device boots.
Magisk gets the actual system and clone it.
Magisk apply the changes you want - modules that you have installed or manually written on appropriate folder - to this system clone only.
You never touch actual device system.
Magisk this way can hide whole root and system changes to Google and other apps.
You can update OTA or manually with no worries. All your changes will be always reapplied by Magisk over whatever actual system you have.
If you want to change system files ( systemless) you can:
write a module and add it to Magisk Manager app
or with a file manager manually put some files on a specific folder of Magisk (same place that modules do)
or use some of the already available modules that let's you do some generic stuff (for instance edit props, debloat, systemize apps,...)
But if you really want to change your actual system (NOT systemless) sure you can. You can do that under recovery. Or you can do that with regular root file manager on a specific Magisk folder that is a link (mirror) to actual system.
All those folders and how to deal with them are explained on Magisk Github readme. Search there for file structure.
Didgeridoohan said:
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
Click to expand...
Click to collapse
Didgeridoohan said:
Correct, I'm talking about manual updates, not OTA (which won't work with a modified /system).
Most system edits you do will still make it possible to pass SafetyNet, but that all depends on what kind of edit you do. I don't have an example of any kind of edit that would trigger it though, so generally you should be safe.
There's actually another very good reason to start doing systemless modifications... From what @topjohnwu has been telling me it's actually going to be impossible to do manual modifications of /system starting from Android Q. I'm not even going to pretend to understand it all, but that's what he's apparently found while looking into rooting the Pixel 3/3XL on Q. It might not happen on all devices updating to Q (and knowing Samsung they'll likely come up with some sort of hybrid solution of their own), but that seems to be the future of Android modding.
Click to expand...
Click to collapse
Thanks again, very useful information.
The edits will be to XML files to tweak and mod the usual CSC open up hidden features, etc so hopefully that does not trigger SafetyNet.
I did read a little about Q on and Pixel 3. I believe he achieved root on Pixel 2. If this is the case it is a sad day for those of us who like to do mods the old fashion way.
With respect to doing these mods via systemless, i understand that modules have to be created. I assume this is a straight forward process? I've never dabbled in Magisk or its modules, if i want to make a simple change to an XML file is there a tutorial on how to do so and how the modules have to be loaded?
Thanks
arf8 said:
With respect to doing these mods via systemless, i understand that modules have to be created. I assume this is a straight forward process? I've never dabbled in Magisk or its modules, if i want to make a simple change to an XML file is there a tutorial on how to do so and how the modules have to be loaded?
Thanks
Click to expand...
Click to collapse
It's quite easy to make modules, yes. @topjohnwu has it laid out pretty well in the docs:
https://topjohnwu.github.io/Magisk/guides.html
And it's all pretty well explained in the template files as well:
https://github.com/topjohnwu/magisk-module-installer
Basically you place the files in the same directory structure as you'd find them on your device's /system partition and Magisk will do the rest. And, this community is generally very helpful so if you ever need help getting a module together it's just a matter of asking. :good:
wilsonhlacerda said:
Generally speaking if you touch (actual) system files you'll not pass SafetyNet anymore. Neither will be able to do OTA updates. Besides that you'll have to reapply all your changes if you update system manually.
That's where Magisk comes. During boot Magisk builds a new system and apply the changes (with modules) that you want on it, not touching the actual device system files. This is the "systemless" concept.
Click to expand...
Click to collapse
I thought based on the response from Didgeridoohan that touching some system files does not trigger safetynet?
wilsonhlacerda said:
For instance on Magisk there's an option (a module) that will let edit hosts file systemless. That way you can use AdAway without problems, its hosts file will be replacing Magisk system hosts, but not the actual device system hosts.
In a nut shell and simple words it is this way:
device boots.
Magisk gets the actual system and clone it.
Magisk apply the changes you want - modules that you have installed or manually written on appropriate folder - to this system clone only.
You never touch actual device system.
Magisk this way can hide whole root and system changes to Google and other apps.
.
Click to expand...
Click to collapse
Thanks this makes sense, but how does one create a module for an application that modifies countless files. I get AdAway modifies the hosts file and changing xml files is easy enough to change because you know what file changed. But for a program like AutoRun Manager which changes countless program receivers, how do you make a module out of that? The application itself modifies countless files based on the changes made in the application. I don't assume everything can be done through a Systemless module or am I wrong?
wilsonhlacerda said:
You can update OTA or manually with no worries. All your changes will be always reapplied by Magisk over whatever actual system you have.
If you want to change system files ( systemless) you can:
write a module and add it to Magisk Manager app
or with a file manager manually put some files on a specific folder of Magisk (same place that modules do)
or use some of the already available modules that let's you do some generic stuff (for instance edit props, debloat, systemize apps,...)
Click to expand...
Click to collapse
Understand on the updates if changes are done via systemless.
So if i copy a system file and place it in the specific folder of Magisk is there more required to make this a module. You will have to excuse my Magisk ignorance. I'll have to look at those modules to see how they made them and see if i can apply the same to the mods I want to do on single files but the bigger issue is on applications itself that modify multiple files like Autorun, Tasker, VPN clients etc.
wilsonhlacerda said:
But if you really want to change your actual system (NOT systemless) sure you can. You can do that under recovery. Or you can do that with regular root file manager on a specific Magisk folder that is a link (mirror) to actual system.
All those folders and how to deal with them are explained on Magisk Github readme. Search there for file structure.
Click to expand...
Click to collapse
Thanks I read through the readme at Github but I had more questions than answers.
Didgeridoohan said:
It's quite easy to make modules, yes. @topjohnwu has it laid out pretty well in the docs:
https://topjohnwu.github.io/Magisk/guides.html
And it's all pretty well explained in the template files as well:
https://github.com/topjohnwu/magisk-module-installer
Basically you place the files in the same directory structure as you'd find them on your device's /system partition and Magisk will do the rest. And, this community is generally very helpful so if you ever need help getting a module together it's just a matter of asking. :good:
Click to expand...
Click to collapse
I will have to keep reading and looking at examples to make sure I understand. It seems pretty easy the way you put it by copying the file in the same directory structure but it seems like there is more to it than that?
My question is how do you apply systemless changes when it is not just a single file for example AutoRun manager that manages the Receivers of every single application in the phone which could be hundreds including system files. How do you make a module or systemless change at this point? Perhaps I should stick with what I know from the SuperSu days and let the application do its job and not upgrade to Q. Mind you I'm on a rooted S6edge with SuperSu on PingPong exploit so I'm very familiar with this phones file systems and documented all my changes but I also rely on many applications to do the changes through their front end.
arf8 said:
I will have to keep reading and looking at examples to make sure I understand. It seems pretty easy the way you put it by copying the file in the same directory structure but it seems like there is more to it than that?
Click to expand...
Click to collapse
No, that's basically it. Put the files in the proper place in the zip, flash it in the Manager or recovery and you're good to go. Or, you could even do it manually while booted by creating the module directory under /data/adb/modules_update. There you can then place the module.prop file (so that the module is recognised by the Manager) and a /system (and/or /system/vendor) directory where you put all the files you want to replace with your own. Reboot, and voila.
My question is how do you apply systemless changes when it is not just a single file for example AutoRun manager that manages the Receivers of every single application in the phone which could be hundreds including system files. How do you make a module or systemless change at this point? Perhaps I should stick with what I know from the SuperSu days and let the application do its job and not upgrade to Q. Mind you I'm on a rooted S6edge with SuperSu on PingPong exploit so I'm very familiar with this phones file systems and documented all my changes but I also rely on many applications to do the changes through their front end.
Click to expand...
Click to collapse
Does the app in question actually edit the system and/or vendor partitions? Or is it simply updating system settings that are found elsewhere? If it's the latter it doesn't really matter...
Didgeridoohan said:
No, that's basically it. Put the files in the proper place in the zip, flash it in the Manager or recovery and you're good to go. Or, you could even do it manually while booted by creating the module directory under /data/adb/modules_update. There you can then place the module.prop file (so that the module is recognised by the Manager) and a /system (and/or /system/vendor) directory where you put all the files you want to replace with your own. Reboot, and voila.
Does the app in question actually edit the system and/or vendor partitions? Or is it simply updating system settings that are found elsewhere? If it's the latter it doesn't really matter...
Click to expand...
Click to collapse
It sounds very simple the way you put it. I looked for some examples on XDA to see if I understand the changes but what threw me off for example on this one below is that the changes are being made to the build.prop file but I don't see a build.prop in any of the folders? instead there is a system.prop?
https://github.com/Magisk-Modules-Grave/voenabler
That is a great question, i don't know to be honest, I do know the app does require root to function in making changes to system files so lets assume the former instead of the latter. Does that mean Magisk can no longer "hide root" if this app is used?
How about Ti backup or more specifically flash fire? Currently I have flashfire backups for any major change I make so if something goes south i recover the entire phone using this tool. Its a beautiful tool for creating snapshots and full recovery, no config needed. I don't suppose it will work any longer with systemless option?
This is just my ignorance as I read more I have more questions, but supersu for example exploited vulnerabilities to achieve root. Is Magisk actually exploiting any vulnerabilities or simply taking advantage of the fact the bootloader is unlocked and therefore it mimics various system partitions to give you a faux root? I'm trying to understand if there is no actual vulnerability to exploit like PingPong in Lollipop for example how can I make changes manually to the system files using Root Explorer? On my S6 Edge it has a locked bootloader, but I still have root access with SuperSu via an exploit, I don't think this is possible with Magisk b/c the bootloader is locked so is Magisk really root?
thanks again for your patience but I'm sure this will come up for anyone doing from SuperSu to Magisk
arf8 said:
It sounds very simple the way you put it. I looked for some examples on XDA to see if I understand the changes but what threw me off for example on this one below is that the changes are being made to the build.prop file but I don't see a build.prop in any of the folders? instead there is a system.prop?
https://github.com/Magisk-Modules-Grave/voenabler
Click to expand...
Click to collapse
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
That is a great question, i don't know to be honest, I do know the app does require root to function in making changes to system files so lets assume the former instead of the latter. Does that mean Magisk can no longer "hide root" if this app is used?
Click to expand...
Click to collapse
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
How about Ti backup or more specifically flash fire? Currently I have flashfire backups for any major change I make so if something goes south i recover the entire phone using this tool. Its a beautiful tool for creating snapshots and full recovery, no config needed. I don't suppose it will work any longer with systemless option?
Click to expand...
Click to collapse
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
This is just my ignorance as I read more I have more questions, but supersu for example exploited vulnerabilities to achieve root. Is Magisk actually exploiting any vulnerabilities or simply taking advantage of the fact the bootloader is unlocked and therefore it mimics various system partitions to give you a faux root? I'm trying to understand if there is no actual vulnerability to exploit like PingPong in Lollipop for example how can I make changes manually to the system files using Root Explorer? On my S6 Edge it has a locked bootloader, but I still have root access with SuperSu via an exploit, I don't think this is possible with Magisk b/c the bootloader is locked so is Magisk really root?
thanks again for your patience but I'm sure this will come up for anyone doing from SuperSu to Magisk
Click to expand...
Click to collapse
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Didgeridoohan said:
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
Click to expand...
Click to collapse
Makes sense, i was looking for build.prop
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
Click to expand...
Click to collapse
understand
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
Click to expand...
Click to collapse
This is probably the most disheartening to hear as I'm not sure what other alternative there is to make a complete snapshot. I assume TWRP but i'm not familiar enough with it and it does not work with the S10.
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Click to expand...
Click to collapse
Again my ignorance is getting the better of me here so bear with me. SuperSu used the PingPong kernel exploit in Lollipop to achieve root, regardless if it had a locked/unlocked bootloader. How does Magisk actually achieve root on the S10 and provide elevated privileges if it is not exploiting a known vulnerability? Or is it exploiting a vulnerability? Is my assumption not correct that because the bootloader is unlocked, it is simply (over simplifying) make a copy of the system partitions and than gives you the impression you have root?
Very enlightening information.
Upon further reading, it looks like Magisk zip contains the su binary which gives you root access without having to exploit a vulnerability so it only works with unlocked bootloader.
arf8 said:
Again my ignorance is getting the better of me here so bear with me. SuperSu used the PingPong kernel exploit in Lollipop to achieve root, regardless if it had a locked/unlocked bootloader. How does Magisk actually achieve root on the S10 and provide elevated privileges if it is not exploiting a known vulnerability? Or is it exploiting a vulnerability? Is my assumption not correct that because the bootloader is unlocked, it is simply (over simplifying) make a copy of the system partitions and than gives you the impression you have root?
Very enlightening information.
Click to expand...
Click to collapse
arf8 said:
Upon further reading, it looks like Magisk zip contains the su binary which gives you root access without having to exploit a vulnerability so it only works with unlocked bootloader.
Click to expand...
Click to collapse
Mornin'.
Correctamundo... No exploits, no vulnerabilities, just old-fashioned root.
Besides the su binary, Magisk also needs to modify the boot image, or in the S10's and some other modern devices case the recovery image. That's why we need to have the bootloader unlocked, to flash the modified file to the boot/recovery partition.
Didgeridoohan said:
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Click to expand...
Click to collapse
Didgeridoohan said:
Mornin'.
Correctamundo... No exploits, no vulnerabilities, just old-fashioned root.
Besides the su binary, Magisk also needs to modify the boot image, or in the S10's and some other modern devices case the recovery image. That's why we need to have the bootloader unlocked, to flash the modified file to the boot/recovery partition.
Click to expand...
Click to collapse
Thanks as usual for the confirmation.
To summarize & correct me if I'm wrong, but the take away for anyone else coming from SuperSu to Magisk who read this thread, is that you will still be able to modify the system files the same old fashion way with apps like Root Explorer, caveat pre-Q (upcoming Android OS), but you give up the ability to Hide Root, which is one the key features what Magisk is known for. Otherwise you can go the modules route which is "systemless" and maintain the ability to hide root.
Does that sound right?
For those like me who are used to the old fashion way of tweaking it will take some getting used to modules and creating them. The problem or issue becomes older style apps which can't be adopted to modules is where the issue arises for systemless conversion. I learned a lot so I appreciate your feedback. If you ask me some of this info should be sticky'd somewhere.
You've almost got it... Even with most old-fashioned system modifications you should be able to hide root. The problem arises if you do some kind of edit that apps looking for root usually look for, like installing Busybox. But that specific case shouldn't be an issue, since there's a Busybox module available in the Magisk repo.
Actually, many if the things you'd normally edit after having rooted can be done through Magisk modules already available.
Debloating - use Debloater.
Systemising apps - use App Systemizer.
Editing build.prop and other prop values- use MagiskHide Props Config.
Hosts adblocking - use the built-in systemless hosts module (Manager settings) and AdAway (or your hosts editor of choice).
Etc...
Thanks, I do have busybox installed so I will use the Module for sure and all the other modules you mentioned. The concern is applications themselves like AutoRun for example and I'm sure more. But good to know the option is there to manually make changes like the old fashion way if you are not concerned about hiding or passing safetynet. I personally don't have anything I want to hide, using this method will trip knox so samsung pay on the phone is out the door. Setting up Samsung Pay on a Gear watch is a different story so that will be beneficial.
In regards to adblocking, are you saying you can use the built-in systemless hosts module and also install the Adaway apk like you normally would? Does it require a modified version of the Adaway app or the regular apk for F-Droid for example will work fine?
One final question since we touched on this earlier. Since FlashFire will not work and TWRP is not an option. What is an alternative for taking a complete snapshot of your phone for backup and recovery?
arf8 said:
In regards to adblocking, are you saying you can use the built-in systemless hosts module and also install the Adaway apk like you normally would? Does it require a modified version of the Adaway app or the regular apk for F-Droid for example will work fine?
Click to expand...
Click to collapse
Yup. Enable the option in the Magisk Manager and reboot. After that Adaway (the regular one from F-Droid) will not touch /system.
One final question since we touched on this earlier. Since FlashFire will not work and TWRP is not an option. What is an alternative for taking a complete snapshot of your phone for backup and recovery?
Click to expand...
Click to collapse
I'm assuming you mean to get the Exynos version of the S10 (since you won't be able to unlock the bootloader otherwise), so: https://twrp.me/samsung/samsunggalaxys10.html
But, I'm not the right person to ask about full snapshot backups... I never do that (haven't for years), but instead make sure that any important data (photos, etc) always is backed up to the cloud. The rest is easy to set up again after a reset (and a reset is good to do once in a while).
Hello !
I'm trying to create simple as fk module... I edited system app and would like to replace already existing system app with it via magisk. I want to utilize magic mount to replace apk every time phone boots.
I tried reading guide on how to make module and the magic mount section says that everything is already in place for doing exactly this , I just need to place files inside module's system folder and everything is supposed to work but the first attempt went rly bad :
https://forum.xda-developers.com/attachments/ha-zip.5410919/?hash=036cbc145f7ed9195b564f943507950f
It didn't even get past unzipping no matter what I did - i made sure to keep all files in root of the folder , used various zip apps and levels but nothing...
Copying zip to temp directory
! Unzip error
So I obviously fled something up by creating module form ground up... Went and downloaded template from here :
GitHub - gedoor/magisk-module-template: template
template. Contribute to gedoor/magisk-module-template development by creating an account on GitHub.
github.com
Added my files to system folder , update description and edited the config.sh to add REPLACE="
/system/app/PowerKeeper
"
Zipped it and more errors... At least it unzips it alright now but idk what this error means during install :
- Copying zip to temp directory
- Installing Ha2.zip
/data/user/0/com.topjohnwu.magisk/cache/flash/update-binary: line 146: /data/magisk/sepolicy-inject: not found
/data/user/0/com.topjohnwu.magisk/cache/flash/update-binary: source: line 167: config.sh: not found
Archive: /data/user/0/com.topjohnwu.magisk/cache/flash/install.zip
inflating: config.sh
! Installation failed
I realize the template that I've downloaded might be broken ... If anyone could look into my first link that I've shared or the file that I've attached that would be great! I'm not sure what or where to start from in order to get this working...
Ty!
You've got everything you need, but the update-binary and updater-script files need to be in the META-INF directory tree, see here for details on what the installer needs to look like:
https://topjohnwu.github.io/Magisk/guides.html#magisk-module-installer
The template you found failed because it's 4 years old. A lot has happened since then and Magisk's internals are very different nowadays.
Didgeridoohan said:
You've got everything you need, but the update-binary and updater-script files need to be in the META-INF directory tree, see here for details on what the installer needs to look like:
https://topjohnwu.github.io/Magisk/guides.html#magisk-module-installer
The template you found failed because it's 4 years old. A lot has happened since then and Magisk's internals are very different nowadays.
Click to expand...
Click to collapse
Thanks a lot !!!
I see you help other people too years ago , I was hoping you'd help me out too but didn't really think pming you based on some years old thread is the best idea and here you are lmao o:
It installed well now ! I'll go reboot , fingers crossed I don't end up in some bootloop (• ▽ •
Ty again!
Usually, the best way to summon me is to turn off the lights and say my name three times into the mirror. But posting in the Magisk forum works too (this is pretty much my home here on XDA and I always keep a close eye on what's going on here)...
Glad I could help and good luck with the modules.
Didgeridoohan said:
Usually, the best way to summon me is to turn off the lights and say my name three times into the mirror. But posting in the Magisk forum works too (this is pretty much my home here on XDA and I always keep a close eye on what's going on here)...
Glad I could help and good luck with the modules.
Click to expand...
Click to collapse
Ah can u help w bootloop now xD
Safe mode doesnt get magisk to disable module gotta delete it now... How though?
Idk if I wanna mess with magisk module uninstaller or if uninstalling whole magisk gets rid of module...
Will going to /data/adb/module and removing module fodler from there fix it ?
Rstment ^m^ said:
Ah can u help w bootloop now xD
Safe mode doesnt get magisk to disable module gotta delete it now... How though?
Idk if I wanna mess with magisk module uninstaller or if uninstalling whole magisk gets rid of module...
Will going to /data/adb/module and removing module fodler from there fix it ?
Click to expand...
Click to collapse
Ha ha! Not uncommon when testing modules you've made...
Removing the module from /data/adb/modules is almost always a surefire way of fixing things.
Interesting that Safe Mode didn't work... You had the Magisk patched boot image installed still?