[Android Software Development] guitardedhero:
Regarding your version of SuperSU supporting script execution, all that matters is a script is able to execute automatically during boot, which you obviously have that currently in place.

If a script in /system/su.d is unable to execute one or more scripts elsewhere in the system partition then one or more of the following is true:

Targeted script does not exist (naming, path).

Targeted script has insufficient permissions (no execute, only owner can execute).

The sh binary variable set by device conditions is incorrect (SH=$SYS/bin/sh, where $SYS is set incorrectly for the root of the system partition. $SH, in this case, relies on two variables to be set correctly by the script).

The above conditions assume that anything other than those listed is error-proof (An error in a script can potentially halt the script indefinitely), that's always a possibility but will hardly be unnoticed.

As for the Sony build properties used in the past and compatibility concerns, I don't see much except for guaranteed SemcMusic FC when using those particular DSHEEX property lines. Only a concern if deciding to install SemcMusic at some point in the future. I am not aware of anything else negatively impacted by those Sony properties.

A stubborn property line that appears in getprop but is unaffected by setprop's attempt to change the value is almost always a "persist" property. It's important to become familiar with persist properties as whatever is originally set will be what is accepted by the system.

To remove a persist property in order to change the value or remove it entirely:

Ensure the persist setprop line has been deleted or edited to include the desired value!

Once the persist property of interest has been determined by the words making up the property, navigate to /data/property and copy the name of the property file name to clipboard.

Then in Terminal:

su
mount -o rw,remount /data
rm -f /data/property/(paste from clipboard) && reboot

Once booted, the result will be one of the two choices made when beginning this procedure: No property, or changed property.

As you might guess, this is the characteristic that makes a build property... persistent. :good:

---------- Post added at 04:23 PM ---------- Previous post was at 04:15 PM ----------

Ah, good eye! I failed to note that those particular Bluetooth codecs were abandoned in favor of the Bluetooth codecs used in the Android O Preview.

Vehicular mobile audio can be the most temperamental of all audio environments, with so many different variables at play. It's nearly impossible to steer you correctly unless inside the environment with you. My first suggestion would be to disable nearly everything in ViPER and make discriminate adjustments at a slow pace and with at least two volumes that amount to the majority of your listening habits. :good:

---------- Post added at 04:33 PM ---------- Previous post was at 04:23 PM ----------

Not the most exciting answer, but cases where satisfaction has yet to be met with multiple modules, I recommend to uninstall a module - or even revert a change in one like that of ICEsound, for example, and focus on the impact this change or uninstallation has on the audio quality.

Modules are intended to enhance the sound, the capability, or just the overall atmosphere. When modules detract from one or more of those three, it can be quite frustrating.

However, don't let that persuade you not to experiment, experimentation is crucial to get the most of all that we offer. I know it can be overwhelming, but have confidence knowing the more time it takes you, the more valuable your experimentation becomes. :good: