[ROM][UNOFFICIAL][12][S]LineageOS 19.1 for z5c (suzuran)

[Berni-0815]

Here's the logcat:

Ok, that's more informative. I see some fatal crashes that shouldn't appear.

01-10 13:09:24.143  7126  7126 F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
01-10 13:09:24.143  7126  7126 F DEBUG   : Abort message: 'terminating with uncaught exception of type St16invalid_argument: stoi: no conversion'

Please be patient, this will take some time.
In the meantime: What mhl adapter are you using?

 

[1ggn3]

The one I'm using is sadly unmarked, it's just a piece of cable with a micro usb port on one side, an hdmi port on the other, and a converter chip with a power input in the middle. I have another MHL cable, but I suspect that this one is broken, I never got it to work (that's why I bought the second one in the first place).

Just for kicks, here is the logcat from my old adaptor (the one I think is broken/incompatible). It converts directly to DVI and I believe it is this one: https://www.delock.com/produkt/65337/dokumente.html

But again, I suspect that the DVI one is broken. Interestingly, it does not freeze with the DVI adapter. But it doesn't show a picture either.

Mozilla Community Pastebin/rvvC5MSP (Plain Text)

 

[Berni-0815]

Interestingly, it does not freeze with the DVI adapter.

But it creates the same fatal error messages...

 

[tomgaga]

Thank for the ROM @Berni-0815 !
Just installed and seems fine but I was wondering if you know of a way to disable the Aurora services without rooting it.

 

[Berni-0815]

If you only want to disable AuroraServices you need to root the device.

 

[petefoth]

I was wondering if you know of a way to disable the Aurora services without rooting it.

Why do you need to do that. Aurora Services will only be used of you chooes it to be the Installation method when you first configure Aurora Store, or in Aurora Services Settings. If you don'twant to use Aurora Services, choose a different intsalltion method.

Disabling doesn't really achieve anything

 

[1ggn3]

I'm using GApps, for reasons, and I just never touch Aurora. If you don't tell it to do something, it just wastes a cm of your screen

Anyway, couldn't you go into recovery, and remove the .apk from /system? That should get rid of it as well, right?

 

[Berni-0815]

At my 1st post you can read how to remove any app.

 

[Berni-0815]

New version out; see 1st post.

• Android security patch level: 5 January 2023

 

[Berni-0815]

@1ggn3 : Please test this version regarding mhl...

 

[1ggn3]

@1ggn3 : Please test this version regarding mhl...

It's... weird. Right now, it works on my TV. I swear that 5 minutes ago, it froze in the exact same setup. On one of my monitors, it displays random noise, and on the other, it worked for two minutes, and then stopped.

I'll have to investigate a bit more, and collect some more data... but thank you so far

 

[dim.on]

Here is a dirty hack for people who have issues with the proximity sensor e.g. in cases where the incallui goes black.

diff --git a/services/sensorservice/SensorDevice.cpp b/services/sensorservice/SensorDevice.cpp index e4efde2448..59de934888 100644 --- a/services/sensorservice/SensorDevice.cpp +++ b/services/sensorservice/SensorDevice.cpp @@ -166,6 +166,12 @@ void SensorDevice::initializeSensorList() { // Don't crash here or the device will go into a crashloop. ALOGW("%s should have a non-zero resolution", sensor.name); } + + // DIM + if (!strcmp(sensor.name, "APDS-9910 Proximity")) { + sensor.maxRange = 4; + ALOGW("-DIM- APDS-9910 Proximity: setting maxRange to 4"); + } } // Sanity check and clamp power if it is 0 (or close)

On my device (Z5) the sensor reports its maxrange as 5.03...cm however the actual distance when nothing is in front of the sensor is reported as 4.9..... cm. The incallui checks if the current proximity value is smaller than maxrange - if true the screen goes dark.

Edit: You might have to change the sensor.name on Z5C devices.

 

[Berni-0815]

The sensor seems to be the same:

SensorService: APDS-9910 Proximity's max range 5.000305175781 is not a multiple of the resolution 0.100708007812 - updated to 5.035400390625

 

[dim.on]

For the crackling audio you might do something like this - however it will increase audio latency.

diff audio_policy_configuration.xml_ audio_policy_configuration.xml 16:32:27 62c62 < <mixPort name="primary output" role="source" flags="AUDIO_OUTPUT_FLAG_FAST|AUDIO_OUTPUT_FLAG_PRIMARY"> --- > <mixPort name="primary output" role="source" flags="AUDIO_OUTPUT_FLAG_DEEP_BUFFER|AUDIO_OUTPUT_FLAG_PRIMARY">

 

[Berni-0815]

Where does this information come from?

 

[dim.on]

Where does this information come from?

android_device_sony_kitakami-common/audio/audio_policy_configuration.xml

or /system/vendor/etc/audio_policy_configuration.xml on device

 

[Berni-0815]

Hmmm. I have to be more precise in my questions:
Where does the information come from that one should use AUDIO_OUTPUT_FLAG_DEEP_BUFFER instead of AUDIO_OUTPUT_FLAG_FAST?

And from where does the "dirty hack" of SensorDevice.cpp come from?

 

[dim.on]

Well, both came out of my mind.

The crackling audio is a buffer underrun, so the audio patch increases the audio buffer size of the primary output .
The dirty hack is a result of looking at the code of incallui and DisplayPowerManager. You could do it cleaner by shiming the sensor hal, but that's substantially more work.

 

[Berni-0815]

The crackling audio is a buffer underrun, so the audio patch increases the audio buffer size of the primary output .

Is that for sure?
AUDIO_OUTPUT_FLAG_DEEP_BUFFER is used in my android_device_sony_kitakami-common/audio/audio_policy_configuration.xml in this sector:

                <mixPort name="deep_buffer" role="source"
                        flags="AUDIO_OUTPUT_FLAG_DEEP_BUFFER">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                             samplingRates="44100,48000" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                </mixPort>

 

[steve8x8]

The sensor seems to be the same:

SensorService: APDS-9910 Proximity's max range 5.000305175781 is not a multiple of the resolution 0.100708007812 - updated to 5.035400390625

So the code rounds up the value, thereby increasing the risk of the actual value being smaller than the threshold? :-(