[Android Software Development] UltraM8:
I see that many people are confused with results they have. Most of the questions were discussed thousand times, but it seems a central post have to be made, which you guys can refer to.

There are 3 major things that need to be taken on a note, while you do any operations with system that are aimed to change audio:

1. Headphones, speakers, music source files - every part of the setup brings an extra cent into the mix of various situations people here have. Some could notice a difference, some are hearing placebo, some couldn't hear a change - relying on anyone's words is a bad idea. It is better to try for yourself, since your setup might be a unique thing. Although, the "big" audiophile world also have tons of weird situations where people claim that different cables give them changes in audio.

2. No one ever could not consider the hearing abilities in any situation, happening around audio. Different people have vastly different hearing abilities, which is why people prefer applications, that are giving them ability to finetune sound. With our aim towards the software & hardware - we don't have that flexibility and ease of use.

3. So the biggest issue with audio modding, is something which takes place with system itself. The dependencies start with how android is configured on the particular device. There are 3 types of sources might be used to compile android:

a) Googles code. This is the most original stuff Google releases when a newer version of android rolls out. Parts we are interested in may vary in their changes and updates, depending on how fresh it is - recent android updates (oreo & pie by the date of this post) have a heavier impact on audio in both quality&fidelity, as well as overall Goggles interest to do something with sound.

b) After Google release their sh*t, SOC manufacturer kicks into the game. And this is where things start to be confusing. See, the chipmaker company has lots of things packed into the soc, including the most precious parts like audio dsp & codec, and to control them they have hell lot's of components. 90% of that stuff is proprietary to SOC producer, you get some sources of course (caf sources by qualcomm for example), but you can't call them "full" if you consider the most intriguing stuff like acdb (audio calibration database) for example (used on Qualcomm chips) is closed by it's balls. Reversing it is a nightmare, since the amount of new stuff they add into the mix is huge and number of dependencies between those files is subject to figure out yet. Consider also, that different soc manufacturers might have absolutely different approach to control their sh*t.

c) The closing part of the list is the device manufacturer. When he gets a & b parts he adds his own stuff on top of that. There are his backends to hardware components liek camera, torch, etc. For us it could result to some files correlating with custom dacs, amplifiers, effects, configs and whatever level of insanity manufacturer has. And again we could be in situation, where are we are cut from full number of components in sources when those are released.

The problem is the number of issues that occur when proprietary to SOC, or device manufacturer stuff has to be reversed. For past several years of development I was constantly checking sources & roms for many devices (total number of dumps I've had around the MKII dev times was about 1.5TB of crap XD). The benefit of comparing&differentiating approach is written in the OP. And now you the biggest issue of this approach - in order to influence the most interesting audio stuff, we have to figure out what is it, how it works & what's it for, how we can patch&modify it. Soc & rom manufacturers left many interesting backend controls for us which we can experiment with. The most important note you need to take here - we are dealing with system, it's also better to take care of kernel too. But, as you can see, not having full number of stuff will lead us to fewer amounts of controls. You still have to use some files that device was originally shipped with, cause those files require some extra sources or tools to custom compile, which we don't have. Rom makers call them "blobs", in some crazy situations you can reverse the code & implement in a special lib - that's called shim & will let some stuff working properly on a custom rom (in most cases it's something simple like torch, that doesn't wanna work without need functions). Unfortunately some device manufacturers are pricks, having proprietary stuff closed - for example LG doesn't have anything on ESS dac in sources. The only way in that case is to reverse kernel, but that is a very time consuming operation, which anyways will end with pseudo code. As you can see it's nearly impossible to predict the results - hell lots of stuff has to be taken on the note, while preparing mod. So the only thing we can do - is experiment with what we have and evolve the mod adding new content, reworking it, or shrinking down components which are absolutely unnecessary or non-working.