[Android Software Development] Zackptg5:
[MENTION=4445176]guitardedhero[/MENTION], this may be a nice addition/reference in the OP :)

So there's been a lot of confusion about unity and aml and that's in large part because I completely overhauled them both without really explaining much about what they are/were so hopefully this will dispel any questions and misconceptions that have been floating around.

What AML and unity used to be:

They used to be a single entity, a framework that a mod used for it to work nicely with other mods that used the aml/unity framework. It worked well, but there were several problems with it.

1)

It was limiting.

A mod had to use the framework which was inconvenient for devs with the frequent updates it received (which ties into the next couple problems) and inconvenient for users because they could only use mods that used this framework

2)

It was complicated.

I put a lot of work into trying to simplify it for any devs who wanted to use it by having the framework have prepared functions and variables but this actually made it more complicated in the long run ironically. This of course all required a lot more scripting and things quickly got out of hand to the point that I kept mixing up my own logic. Frequent updates were needed to fix this and it seemed like a neverending quest

3)

It was time consuming to maintain.

Due to #2, I spent a lot of time on it and I just don't have that time to spare anymore

What they are now:

AML and unity are now completely separate entities so I will briefly explain each.

Unity:

Unity is a simple framework which autodetects root solution, partition layout, etc. that a dev can use to easily make a mod that will install on any device. That's it, just a dev framework. To the users, all this means is that they can use this 1 zip for all of their devices instead of needing a different zip for each (for example, instead of needing a zip for a device using magisk and a different one for a device using supersu, 1 zip will work for both). It makes life easier both on the devs (as they can focus on the mod itself rather than the scripting) and the users (1 zip fits all solution).

Since redoing unity, it's now much simpler and so won't need many maintenance updates (makes life easier for everyone)

AML:

AML is now what the name says it is: Audio Modification Library. It is a standalone magisk module that contains a "library" of audio mods. It will then search the magisk img for any audio mods in it's library and combine all of their effect/policy/mixer files into 1 set allowing them to work together. Due to the complex nature of this, this mod will likely need updated for various bugs/issues and/or improvements I find over time and to add new audio mods to it's database.

Misconceptions:

1)

Only unity modules work with aml:

By separating aml and unity, I solved problem #1. If the audio mod in question is in the supported mod list on the OP of the aml thread, then it'll work with it regardless of the installer. Take v4a for example. You could use the unity one by me and ahrion, the one by shadysquirrel, or some other one, it doesn't matter. V4A isupported by aml so any v4a magisk module will work with it

2)

AML and any audio mods you have need flashed in a specific order:

Order doesn't matter. AML includes a boot script which is bascially a modified version of the installer so if you add/remove/change an audio mod, aml will detect that an incorporate those changes during the next boot. That being said, I prefer to flash aml last because then the boot script doesn't need to do anything which may increase boot speed slightly. Also, it's incredibly satisfying to watch the installer detect everything and stuff :)

3)

I need aml for my audio mod to work with magisk:

You only need aml if you have MORE THAN ONE audio mod. AML won't hurt anything but there's no reason to have it if you only have 1 audio mod since it's the only module containing copies of the effects/policy/mixer files