whatawurst / android_device_sony_yoshino-common Goto Github PK

@shank03 I and other users have issues using VoLTE (see https://forum.xda-developers.com/t/rom-lineageos-17-1-18-1-unofficial-update-2021-09-18.4308295/page-10#post-85850807). The setting isn't even shown although the IMS settings are enabled in XPeriaParts:

• IMS Features: On
• modem: amss_fsg_lilac_telefonica_germany_volte_vilte_vowifo_tar.mbn

I found the check in Enhanced4gLtePreferenceController.java: getAvailabilityStatus and printed the values:

• subid: valid
• isVolteEnabledByPlatform: true
• isVolteProvisionedOnDevice: true
• isImsServiceStateReady: false
• KEY_HIDE_ENHANCED_4G_LTE_BOOL: false
• is4gLtePrefEnabled: false

So the only wrong value is isImsServiceStateReady.

Any ideas/suggestions on how to debug this? Asking you because you implemented the IMS toggle and might know where to look for issues.

Logcat is showing

E UsbDeviceManager: failed to write to /sys/class/android_usb/android0/f_rndis/ethaddr

And indeed the folder /sys/class/android_usb/android0/f_rndis is missing.

I see chown system system /sys/class/android_usb/android0/f_rndis/ in init.usb.rc so I guess that file is supposed to be there.

Any idea why it is not? Anything missing in the kernel?

The option doest work

With last update while signing build with the command sign_target_files_apks an error occurred:

"Error: could not load context file from out/target/product/poplar/obj/ETC/file_contexts.bin_intermediates/file_contexts.device.tmp"

A temporary fix provided by @jw96 is to comment line 106 of the file sepolicy/vendor/file_contexts

line 106: #sys/devices/virtual/graphics/fb([0-3])+/idle_state u:object_r:sysfs_graphics:s0

Is it necessary to comment out this line of code or can it be solved differently?

Seemingly some (pre-treble) devices try to do something to the /system partition causing this denial:

avc: denied { relabelfrom } for comm="init" name="modules" dev="sda66" ino=1179683 scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0 tclass=dir permissive=0 ppid=0 pcomm="swapper/0"

Adding allow init system_file:dir relabelfrom; is not possible as it violates a neverallow rule in system/sepolicy/public/domain.te:

# Nobody should be doing writes to /system & /vendor
# These partitions are intended to be read-only and must never be
# modified. Doing so would violate important Android security guarantees
# and invalidate dm-verity signatures.
neverallow {
    domain
    with_asan(`-asan_extract')
    recovery_only(`userdebug_or_eng(`-fastbootd')')
} {
    system_file_type
    vendor_file_type
    exec_type
}:dir_file_class_set { create write setattr relabelfrom append unlink link rename };

Should we care about this? Maybe add an ignore rule to init.te.

Aperture shows the camera preview in a mini-windows. Switching 4:3 to 16:9 doesn't affect the screen, but affects the photos taken.
Might be upstream and/or resolution problem.

A user reported issues with APNs:

On 17.1, the defaults for my carrier (T-Mobile US) include a bunch of irrelevant MVNOs, one of which includes a DUN profile so it can't be edited or deleted. Because that also claims to be an IMS profile, it was overriding the proper one. So the radio would just reset repeatedly if WiFi or LTE was available.

He linked https://sourceforge.net/projects/lineageos-for-x2/files/Mods%20and%20Tweaks/APNs%20Update%20from%20Google/ which is basically using the Google APN list: https://sourceforge.net/projects/lineageos-for-x2/files/Mods%20and%20Tweaks/APNs%20Update%20from%20Google/

Would it make sense to use that directly or merge it with ours?

However I don't really understand this APN stuff. I though the APN is selected based on the current MCC & MNC but the apns-conf.xml contains many duplicated entries for the same MCC/MNC combination.
So when merging the APN configs, which ones would I need to omit if duplicates seemingly are allowed?

2800669
leads to a warning:

build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/lilac/system/product/etc/apns-conf.xml'

build/make/core/base_rules.mk:510: warning: ignoring old commands for target `out/target/product/lilac/system/product/etc/apns-conf.xml'

Judging from the code this can be avoided by setting something like: CUSTOM_APNS_FILE := $(PLATFORM_PATH)/configs/telephony/apns-conf.xml in the board config which will make the lineage build scripts handle the copy so we can be sure the right file is taken.

HOW TO USE THE VOLTE like China telecom CMCC China Unicom in SOV36

Getting things like this: avc: denied { execmod } for comm="com.whatsapp" path="/apex/com.android.runtime/lib64/bionic/libc.so" dev="loop3" ino=91 scontext=u:r:untrusted_app:s0:c247,c256,c512,c768 tcontext=u:object_r:system_lib_file:s0 tclass=file permissive=0 ppid=746 pcomm="main" pgid=746 pgcomm="main" app=com.whatsapp

I'd say an allow untrusted_app apex_mnt_dir:file execmod; would allow this and still be "safe".

Thoughts?

I've seen lilac devices setting the minimum brightness to 34 not to 1 as it should.

Following that is quite hard, enabling some debug output I got this:

01-08 13:50:47.946  1440  1904 V LightsService: setLight #0: color=#ff030303: brightnessMode=0)
01-08 13:50:47.948   869   869 D illumination-service: 'backlight': Color ff030303, BrMode 0, OnMS 0, OffMS 0, Mode 0
01-08 13:50:47.948     0     0 D qpnp_wled_set_level: brightness=48 level=48
01-08 13:50:47.949     0     0 D level   : 48
01-08 13:50:48.328  1440  1904 V LightsService: setLight #0: color=#ff020202: brightnessMode=0)
01-08 13:50:48.330   869   869 D illumination-service: 'backlight': Color ff020202, BrMode 0, OnMS 0, OffMS 0, Mode 0
01-08 13:50:48.329     0     0 D qpnp_wled_set_level: brightness=34 level=34
01-08 13:50:48.331     0     0 D level   : 34
01-08 13:50:49.109  1440  1904 V LightsService: setLight #0: color=#ff010101: brightnessMode=0)
01-08 13:50:49.111   869   869 D illumination-service: 'backlight': Color ff010101, BrMode 0, OnMS 0, OffMS 0, Mode 0

I.e. a color of #ff020202 still works, but yields a brightness level of 34 while the lowest possible brightness color gets stuck in the illumination-service. That is extracted from stock at https://github.com/whatawurst/android_device_sony_lilac/blob/920e87e6d8a212246d22ec51c3cde15d984d9b6d/proprietary-files-vendor.txt#L828

Why do we copy that and lights.default.so from stock instead of using e.g. the module at https://github.com/whatawurst/android_device_sony_yoshino-common/blob/lineage-18.1/hardware/qcom-caf/display/liblight/lights.c or use a HIDL service implementation such as https://github.com/sonyxperiadev/device-sony-common/tree/fc6d709db9b4f44e8bfb410d8c7e7e67ca292a6a/hardware/liblights ?

I'm having trouble building 19.1 and was wondering if you can help as I think it should be the same issue in 20

So trouble is caused by https://github.com/whatawurst/android_device_sony_yoshino-common/blob/lineage-20/platform/dependencies.mk#L52-L53

With the error

Error: /repo19/soong/.intermediates/device/sony/yoshino-common/hardware/ims/ims-ext-common_system/android_common/aligned/ims-ext-common_system.jar contains class file org.codeaurora.ims.internal.ICrsCrbtController, whose package name "org.codeaurora.ims.internal" is empty or not in the allow list build/soong/scripts/check_boot_jars/package_allowed_list.txt of packages allowed on the bootclasspath.

It refers to this class in a build rule generated by https://github.com/LineageOS/android_build_soong/blob/lineage-19.1/java/boot_jars.go checking the package names against regexs in https://github.com/LineageOS/android_build_soong/blob/lineage-20.0/scripts/check_boot_jars/package_allowed_list.txt and that contains only "org.codeaurora.ims" & "org.codeaurora.internal" which doesn't match "org.codeaurora.ims.internal"

So the error is expected in 19.0, 19.1 and 20.0. How do you avoid it?

BTW: The correct entries are used in other distributions, see e.g. https://gerrit.pixysos.com/c/PixysOS/build_soong/+/23279/2/scripts/check_boot_jars/package_allowed_list.txt

Charging current mAh when charging device, seems to get gradually low as the battery percentage increases. This behavior is seemed to be same/similar as when battery care is enabled on stock.

This has been present since Android 10 (or maybe even before). This issue is confirmed by many people (including users from poplar and maple) and some have even known to report it as charging not properly.

What exactly is the issue ?

Taking Lilac as reference device:

STOCK
The current on stock locks at 20xx mAh when normal charging and it doesn't fluctuate when using device while charging.
When battery care is enabled, the charging current starts from 19xx mAh and gradually decrease with increase in percentage as it meant to work.

Custom ROM
When the battery is low, the current goes up-to 19xx mAh and drops to 7xx mAh when using the device. However, as the battery reaches about 30% - 50%, the current become unstable, fluctuating between 19xx mAh - 7xx mAh and at about 50% - 60% it drops to 7xx mAh and gets lower as the percentage increase. Thus, this behavior seems (most probably is) same like battery care

My assumption

Seems like battery care is enabled by default in /sys/../.. path and maybe a service needs to be run to modify those values.

Logs doesn't say anything.

What is to be fixed

The current should be stable 19xx mAh when device is not in use or idle; throughout the charging session. The gradual decrease in current at higher battery percentage makes the device take more time to charge fully. However, the current drop of 7xx mAh seems to be battery friendly.

I hope this issue is small and easy to fix (not judging, just hope :P)

Hey.
From what I read the CPU should be the same when using .mbn files from other devices. Some phones with Snapdragon 835 support Volte for Yettel Bulgaria (formerly Telenor). Do you think it would work to add it in Modem switcher?
I can find the mbn if it would.

Hello, I built Pixel Experience Plus with latest device trees for maple. But after I booted up, it couldn't detect SIM card and said Unknown Baseband version. I have tried to revert 0e50911 but nothing changed. Here's my logcat:https://del.dog/tolataleve
I noticed Could not find '[email protected]::IRadio/slot1' for ctl.interface_start from pid: 636 (/system/bin/hwservicemanager) and Could not find '[email protected]::ISecureElement/SIM1' for ctl.interface_start from pid: 636 (/system/bin/hwservicemanager)

For some reason when booting the OS since the last update, the animation stops, the screen goes black, then the animation starts again until the phone finally boots.
Not a big issue, but it might be useful to note, who knows.

LOS 19
In file included from device/sony/poplar_kddi/Android.mk:20: In file included from device/sony/yoshino-common/Android.mk:21: In file included from device/sony/yoshino-common/hardware/Android.mk:19: device/sony/yoshino-common/hardware/qcom-caf/Android.mk:6: error: hardware/qcom-caf/msm8998/audio/Android.mk: No such file or directory 13:34:00 ckati failed with: exit status 1

And indeed it's missing (exist on older branch like 18.1 nor 17) or deprecated.
on 18.1 it's a symlink so I'm not sure if this is required.

Dirty-flashing from 1.2, charging seems to be extremely slow. The current is around 700mA when charging rapidly and the phone heats up very fast.
It took me 4 hours and a half to get from 10% to 100%.
Perhaps it's somehow connected to the Battery Care feature.
#3 - this is a good report on how the current should behave.

A user noted that e.g. the lilac phone supports 24bit 192kHz audio output but not on our LOS ROMs: https://forum.xda-developers.com/t/rom-lineageos-17-1-18-1-unofficial-update-2021-09-18.4308295/page-11#post-85879703

So far I found the audio_policy_configuration.xml to be responsible for that. Android 9 had the audio*.conf files while Android 10+ has the audio_policy_configuration.xml, so I'd guess something went wrong in the "translation"

@cryptomilk @derfelot How was audio_policy_configuration.xml created exactly? And shouldn't that be a device specific file instead of yoshino-common?

With some experiments I was able to get 24/192 output working: https://forum.xda-developers.com/t/rom-lineageos-17-1-18-1-unofficial-update-2021-09-18.4308295/post-85905893 But basically just pure Trial&error. This is the file I'm using:
audio_policy_configuration.xml.txt

Any input/ideas here?

There is a race condition in the network switcher:

• Network switcher delays next actions
• User unlocks phone
• Network switcher switches to 3G and registers listener for ACTION_USER_UNLOCKED as isFileEncryptedNativeOrEmulated is set

-> Network stays at 3G forever

@shank03 What exactly is that encrypted check protecting? Is there another way to check if that is available yet?

Solutions I can think of:

• Register receiver in create and set bool if unlocked, this can then be checked skipping the wait for unlock part
• Check if already unlocked, depends on what it is required for. https://github.com/aosp-mirror/platform_packages_apps_settings/blob/060bf953e39b3310c04a0440acf702aeb691207c/src/com/android/settings/deviceinfo/StorageWizardMigrateConfirm.java#L101-L102 could maybe be used here?

Pick commit below to fix: RedSTARO@a841385

After patched blobs are in the PR here: whatawurst/android_vendor_sony_yoshino-common#5

With an LOS 19.1 build I see

avc: denied { read } for comm="android.hardwar" name="u:object_r:default_prop:s0" dev="tmpfs" ino=2501 scontext=u:r:hal_graphics_composer_default:s0 tcontext=u:object_r:default_prop:s0 tclass=file permissive=0 ppid=1 pcomm="init" pgid=1 pgcomm="init"

Don't you have that too?

I traced that to the property sdm.disable_hdr_lut_gen from hardware/qcom/display/msm8998/sdm/libs/core/display_base.cpp see also LineageOS/android_device_fxtec_pro1@e5e856d

So I guess we have to label that too.
Other properties potentially read by hardware/qcom/display/msm8998/sdm/* are:

debug.egl.swapinterval
debug.gralloc.enable_fb_ubwc
debug.gralloc.gfx_ubwc_disable
hw.hdmi.resolution
persist.hwc.blit.comp
persist.metadata_dynfps.disable
ro.vendor.extension_library
sdm.boot_anim_layer_count
sdm.composition_simulation
sdm.debug.disable_avr
sdm.debug.disable_partial_split
sdm.debug.disable_rotator_split
sdm.debug.disable_scalar
sdm.debug.disable_skip_validate
sdm.debug.downscale_external
sdm.debug.rotator_disable_ubwc
sdm.debug.rotator_downscale
sdm.disable_decimation
sdm.disable_hdr_lut_gen
sdm.external_action_safe_height
sdm.external_action_safe_width
sdm.external.mixer_stages
sdm.fb_size_height
sdm.fb_size_width
sdm.hdmi.s3d_mode
sdm.idle_time
sdm.idle_time.inactive
sdm.max_external_layers
sdm.max_upscale
sdm.mixer_resolution
sdm.perf_hint_window
sdm.primary.mixer_stages
sdm.video_mode_panel
sdm.virtual.mixer_stages
sys.disable_ext_ani

BTW: Is there an easy way to find the name of the property for which SELinux denied access when it isn't labeled? I label all unlabeled properties with numbered names to find the one.

Also can I find which of those above properties are not labeled yet?