[Android Software Development] guitardedhero:
Well, I'm a fan of trying anything at least once. Being worth the effort is often times a one-sided and flawed value.

As with all things in life, I can guarantee you the most tragic scenario is one where nothing is learned from our near limitless supply of potential mistakes. Failure is simply inevitable if any effort is applied. I've been extremely fortunate to not remember having any other outlook on life.

Throughout my entire Android experience, I've learned much, much more from my innumerable failures than I have from my successes, some of which are even quite spectacular for the time.

For instance, I never accepted that ViPER4Android could not function without root and BusyBox. I achieved this through a barrage of nay-sayers rather quite easily. Of course, this was before the Enforcing Mode SELinux era.

But honestly, very little was learned upon achieving a fully functioning ViPER4Android in a root and BusyBox free environment. I knew why root and BusyBox were required, those needs simply needed to be accommodated elsewhere. However, this success did have a very valuable impact:

To tell anyone they cannot do anything is destructive to oneself. I guarantee you, the person being told what they cannot do is nowhere near as afflicted as the one admitting any perceived shortcomings with which they've grown content.

My advice is try anything and everything you can think of, maximizing the knowledge to be gained from not succeeding and celebrating successes briefly. With the right attitude, you'll enjoy almost every step of the way, it's okay to be frustrated or disappointed.

Vivo 2.0 is quite old as Vivo 3.0 has been advertised for quite some time, although I'm unsure if I've even stumbled across it while even seeking it. Vivo 2.0 is a combination of DTS, SRS, and proprietary technologies acquired like BBE's SonicMaximizer, for example. Vivo's collection is not the easiest to prepare as several unassuming libraries are required to satisfy specific prerequisites. This is where the dumpsys utility is as valuable as a volt/ohm meter to an electrician. There is a level of hardware implementation even back then but the software implementation is achievable and can provide positive results, not to mention the knowledge gained from satisfying the prerequisite libraries.

Regarding audio_effects configurations, the simplest way to remember it's purpose is to understand that libraries in /lib/soundfx will not execute. They remain dormant until called upon by a combination of their location path and effect uuid by the appropriate audio_effects configuration:

/vendor/etc/audio_effects.conf over /system/etc/audio_effects.conf

/system/etc/htc_audio_effects.conf over /system/etc/audio_effects.conf

These are just two basic examples of a single audio_effects configuration used when two are available. Two or more are used in some cases but a dominant one is usually obvious in these instances and isn't always the only one that can activate an experimental library effect.

/system/lib and /vendor/lib libraries typically do not require a configuration file to at least start, run, or execute. These libraries are also often times influenced by other libraries in the same directory in how they will behave so you are at their mercy in many cases.

However, libraries in /system/lib and /vendor/lib are still often times called upon audio_effects using its location path and effect uuid, libhuaweiprocessing.so being a good example as well as one of my favorites. The difference here in /system/lib or./vendor/lib is that the library is able to run, start, execute, even fall on its face, while also utilizing a specific effect via its audio_effects entries.

Similarly, a typical /lib/soundfx library behaves differently when outside of /lib/soundfx than its normal, intended use. libbundlewrapper.so, libqcompostprocbundle.so, and libreverbwrapper.so can be used in /system/lib or /vendor/lb while remaining in /lib/soundfx to be activated by audio_effects. This allows a library to behave two different ways, independently from each other.

There are so many possibilities. However, make the dumpsys utility your greatest friend and asset. It will not lie to you. Anything contained in audio_effects WILL appear in the audioflinger output if enough prerequisites are in place:

su
su -c dumpsys media.audio_flinger

Best of luck to ya. :good: