[Android Software Development] guitardedhero:
Yeah, I left the demo intact to see if anyone had different results than I did lol.

The next Razer updates will lack the mammoth heft this demo brings to the total size.

They are merely options for those interested to see what works, what doesn't work, what sounds great, what sounds pretty awful, what breaks native device features, what keeps everything intact, stability, consistency, etc...

Just because I am the one porting these various systems does not mean that I know more than you guys do as to how everything will sound or play well together on setups, especially those other than stock OP5.

I conduct this entire project as a community effort with equal voice as to where things lie in the final assessment.

Fortunately, Magisk provides the most convenient platform for the user to test as much as desired without any downtime in recovery sessions or restoring roms, so it's logical to encourage you guys to dive right in and steer following moves by providing feedback - good, bad, or indifferent.

The final results here will not be a reduced number of ports. Everything ported that avoids catastrophic disruption will remain, even if only for informative value.

64-bit, unless 32-bit is part of the file name.

No, unless something has happened that I have not noticed.

This may sound silly, and I've spent countless hours brainstorming how best to handle Magisk's allowing of multiple files of the same name and location, but ACDB's best quality is that it is absolutely incompatible with every mod that relies on audio effects configuration right out of the box.

Years ago, with system mods, targeting the configurations to patch was a piece of cake. /system was /system, /system/vendor was /system/vendor, etc...

Today's Android landscape includes so many variables for "What is vendor?", "What is the mountpoint?", and "Which configuration is the one that matters?". Oftentimes, the only real effort in preparing an audio mod relying on audio effects configurations is targeting the appropriate configurations while mounting the correct mountpoints successfully.

ACDB takes advantage of Magisk's much more predictable "mirror" environment by making the initial effort when first installed by gathering the device's stock audio effects configurations into a Magisk module with the appropriate structure to mirror back to system and/or vendor when booting.

So, one could say that the first thing ACDB does is incapacitate any and every module already installed relying on a configuration in its own module, since the very next maneuver by ACDB is to exterminate any configuration found inside a module other than ACDB, of course, and AML as well - because I'm not a **** like that lol.

What may seem like an initial annoyance for dev/user of a crippled audio module is, if intentions succeed, swiftly turned into relief for the following two reasons:

Firstly, the dev has the necessary snippet of code to add to the configuration patching operation in their installation script that merely adds targeting ACDB configurations before the existing operations targeting configurations on the device. The absence of ACDB on a user's device has no effect on the installation and it will perform precisely as it did before adding ACDB targeting first. If ACDB exists, targeting the appropriate configurations couldn't be any easier, and the configuration relied upon will stay until the user deletes the ACDB module.

Secondly, the user is relieved of the habit of having to install a zip to "repair" audio effects configurations after installing any audio module. All a user needs to do in order to utilize ACDB is to simply install it. If ACDB is installed after one or more of my current audio mod zips with ACDB in the name, those modules will "break" as the configurations begin as stock in the ACDB module. However, those acdb audio mod zips can simply be reflashed immediately after the ACDB module without rebooting first. Therefore, a user finding an audio mod not supporting ACDB only needs to inform the dev that the ACDB support code is available in the ACDB zip along with documentation and examples to take advantage of this most convenient, single step update that provides the most stability possible in a Magisk module thus far.

Pretty boring stuff, honestly. You all can wake up now lol.

Much better, thank you!

Unfortunately, this is due to system property values some native device features, such as your camera, rely upon to function. These merely amount to integrity checks so that the feature, camera in your case, can function and perform as intended because it limits those processes to your device.

Elsewhere, your camera would almost certainly underperform at best, and that is exactly what is happening when your camera realizes it is installed in a Razer environment suddenly.

This is a license check for the majority of Dolby Atmos systems today. Fortunately, Axon 9 Pro lacks any license check so no system properties are added and no existing values are changed.

I have a responsibility to label ports that pose this type of risk and I've failed to do that. I'm still stuck in testing mode lol. This will be resolved in all future updates. :good: