[Galaxy S3 Neo Original Android Development] helloyello:
Thanks for the update on this. Unfortunately, yesterday I took the decision to go back on stock and today I was using the old Nokia BH-108 for more than 2 hours without any issues.

It's definitely something wrong with the driver/chipset (indeed it's the same combo chip for both WiFi&Bluetooth (& I believe also for radio FM)) on LOS16. Again, the BT connection remains preserved, LOS16 doesn't disconnect it, it's just the audio functionality that gets interrupted, could be because of some glitch in the driver / PhoneApp. I don't know how to check the exact chip type without opening the phone, I'm using a Samsung GT-I9301I Galaxy S3 Neo and now I'm already back on stock ROM now.

I'm also not that crazy to greenify system apps or apps related to Android subsystems functionalities. :eek: I'm greenifying crap like Calendar, Camera, Calculator .. etc and my own Apps that don't need to stay resident while the phone is in standby. Finally, greenify will freeze them after a clear and fixed amount of time, after the screen turns off and not randomly, meaning the suspicion has no point whatsoever.

On the Signal Messenger issue - corrupting video - I tested it today on stock ROM with a few parties and learned that it's caused by the lack of bandwidth. Signal doesn't really adapt the video (like Skype/Whatsapp) on the available bandwidth and requires at least 1-1,5Mbit/s for proper video calls. It turns out that due to this COVID-19 crap, the networks are pretty overwhelmed and uplink bandwidths seriously affected. I could observe in OpenVPN (it shows live traffic stats) that the incoming bandwidth from the correspondents with which I had video glitches was under 1Mbit/s and around 2-3 Mbit/s for the ones with which I had no video issues. Meaning, it's not LOS16 related.

On the performance side of Apps under LOS16. I can confirm what other users reported that the phone will overheat pretty bad in some circumstances under LOS16. Even in my case, where I disabled the overclocking, I have one video surveillance App that display a video wall with 12 live cameras and even under stock ROM it almost kills the phone, warming it up a little - actually it warms up pretty fast and pretty high. On LOS16 this App turned the phone really hot, dangerously hot, and I was always afraid to let the app running, fearing I'll destroy the phone.

Under stock ROM I'm able now to play youtube videos inside Firefox, in full-screen mode with 1080p resolution without any glitches. Not that I need 1080p, the display is not capable and I'm usually setting the quality on 720p. It's just that on LOS16 I was only able to use 480p in Firefox.

OpenVPN for Android - latest version handles the expected 25Mbit/s under stock ROM.

Finally, I checked the compilation parameters on the binaries for both stock ROM and LOS16 and learned that the binary code is OK and in neither case HardFloat was used, which is really stupid, armv7 SoCs are all fitted with a HW VFP, it's ARMv8/v9 that had it optional.

Conclusion, there is some other cause for the overhead/low performance of apps in LOS16.

Here are the results - i took the binaries out of LOS16 and stock ROM and copied them on a full fledged Linux distribution where I used the readelf utility to check the compilation parameters for the binary code:

-readelf outputs (snippets):

- LOS16

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "cortex-a9"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv4
Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
Tag_ABI_PCS_GOT_use: GOT-indirect
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_FP_HP_extension: Allowed
Tag_ABI_FP_16bit_format: IEEE 754
Tag_DIV_use: Allowed in v7-A with integer division extension
Tag_Virtualization_use: TrustZone

- Stock ROM (KitKat)

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM v7"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: Deprecated
Tag_ABI_optimization_goals: Aggressive Debug
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed

- own HardFloat compilation (full fledged Linux distro) - note the "Tag_ABI_VFP_args: VFP registers" confirming the code is HardFloat

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6

More info about the floating options:

https://embeddedartistry.com/blog/2017/10/11/demystifying-arm-floating-point-compiler-options/

https://wiki.debian.org/ArmHardFloatPort#GCC_floating-point_options

Finally, I'll stick now with stock ROM and maybe try LOS17.1 when it will be available. Honestly, the lack of patching the connectivity (WiFi/BT&co) with the appropriate firmware blobs (& drivers?) was the major issue that influenced me to revert to stock ROM and consider LOS16 useless (in my case).