MagiskModuleManager
MagiskModuleManager copied to clipboard
Androidacy
Wishlist
Here is a list of features that have been requested and may or may not be considered.
| Feature | Consideration | Notes |
|---|---|---|
| Share button | Maybe | Will probably be implemented only for Androidacy repo |
| Favorite modules | Yes | In planning phase |
| Backup/Restore modules | No | Improbable due to complications with install scripts |
Please allow modules to use their own update mechanism again.
Modules will use the update JSON when they aren't provided by any repository or the repository has invalid data.
However, unfortunately we've observed abuse of the update JSON API to bypass Repository scanning and restrictions, so allowing update JSON to override a Repository is non-beneficial currently. Another case of a couple bad apples had to ruin it for others.
Perhaps in the future if enough interest is expressed we could also validate the update JSON regularly and permit it to override a Repository in more circumstances, but that would require increased effort and resources on repositories.
Yeah... so I mean I liked Androidacy being an entry-point to finding my modules, but then I want my modules to be allowed to update themselves, as I have intended, and as the app used to work. 🫤
Yeah... so I mean I liked Androidacy being an entry-point to finding my modules, but then I want my modules to be allowed to update themselves, as I have intended, and as the app used to work. 🫤
Updating from our Repository is no different than updating from a URL you provide. We push the exact zip you'd find out on GitHub and make no changes. You are free to verify that yourself.
However, while myself and I'm sure everyone else in the team has immense respect for you especially, we don't currently have the infrastructure in place to monitor external urls, and as such the application prioritizes repository data over developer controlled data, to enforce our policies and the policies of other repos. It's not just our repo the app enforces this for, either.
We had an instance of a developer using update JSON to actively push out malware, once having a legitimate module installed the user would unwittingly update to a malware laced module. That developer is now of course banned but it's not something we take lightly.
I won't rule out making update JSON safer so we can once again allow it to have equal priority but I make no promises. We're also working on allowing developers to integrate with our existing systems for updating themselves but that of course will be limited to our own repository.
I understand the issue of overseeing module repos... The problems are really why John sunsetted the official original...
John said he hoped to establish a suitable body to oversee official repos again at a later time but this hasn't materialised...
Meanwhile, proper issues were opened for an interim solution for pushing updates... I made an initial suggestion about using a Developer set JSON for updates and limited documentation... That was debated but was listened to, and it's what we now have officially...
Personally, I will avoid using solutions that override/bypass supported/intended functions including supported update JSON... Altering any code seems dubious to me, but should at least be done with developer permission and agreement and not replace/dispense with Magisk utility... Doing so otherwise will only alienate developers and users...
The onus for vetting modules for suitability/security in the absence of official oversight now clearly rests with end users/modders, including available updates, but you can police those you host of course, and updates as well...
In the case of 'bad apples', malware will of course be pushed from your repo(s) if you don't catch and remove modules... But you have access to any update JSON being called from modules you host also, so why not simply extend your solution to download and scan updates as soon as a dev pushes changes to JSON? Simple!
If you don't want it to seem "like they're using this 'bad apples' argument to force all downloads to come from their website, and therefore serve more ads", you should listen to this argument.
I understand the issue of overseeing module repos... The problems are really why John sunsetted the official original...
John said he hoped to establish a suitable body to oversee official repos again at a later time but this hasn't materialised...
Meanwhile, proper issues were opened for an interim solution for pushing updates... I made an initial suggestion about using a Developer set JSON for updates and limited documentation... That was debated but was listened to, and it's what we now have officially...
Personally, I will avoid using solutions that override/bypass supported/intended functions including supported update JSON... Altering any code seems dubious to me, but should at least be done with developer permission and agreement and not replace/dispense with Magisk utility... Doing so otherwise will only alienate developers and users...
The onus for vetting modules for suitability/security in the absence of official oversight now clearly rests with end users/modders, including available updates, but you can police those you host of course, and updates as well...
In the case of 'bad apples', malware will of course be pushed from your repo(s) if you don't catch and remove modules... But you have access to any update JSON being called from modules you host also, so why not simply extend your solution to download and scan updates as soon as a dev pushes changes to JSON? Simple!
If you don't want it to seem "like they're using this 'bad apples' argument to force all downloads to come from their website, and therefore serve more ads", you should listen to this argument.
Update JSON would require continuous monitoring, because they can change that file willy nilly. The files we host only get updates when we detect version code changes, which means we can check the file once. We don't remove the update JSON or override it either - we just prefer repo data on AMM.
And your last argument is notwithstanding, because this behavior is enforced for all repos, not just ours
Why don't you make back fox mm and let it at its place and why you put tons of ads on ur website coz github pages exist anyways so no subscrip. so just why not give main dev's github repo urls too for magisk mod
Why don't you make back fox mm and let it at its place and why you put tons of ads on ur website coz github pages exist anyways so no subscrip. so just why not give main dev's github repo urls too for magisk mod
You're right! Why don't we offer a significantly inferior experience and remove every feature that we've worked hard on that requires a backend, and why don't we also remove the entire reason module repos exist, plus let's also write a completely new website and some complicated mess of Actions scripts, so you don't have to see a few ads! Dang, we should put you in charge.
While that was heavily sarcastic, I think you get the point. Your way really isn't beneficial and is harder for all parties involved.
Please note I'm expressing my own opinions, and some comments do not necessarily reflect official Androidacy viewpoints!
I don't like it either, but threatening is not the solution. Just use one of the other ways to do this or other apps that offer the same abilities.
Just FREAKING REMOVE THE TRACKING CRAP AND AD CRAP OR I BREAK YOUR SCREEN
Once you start writing us checks, we'll remove ads forever. Until then, they're here to stay.