* Google has been tightening up mutexes by disallowing calling
pthread_mutex_destroy on an already destroyed mutex in P
* This normally isn't an issue, but Qualcomm, in their infinite
wisdom, decided to destroy a mutex in a loop in isp_module_stop_session
when they were freeing some related memory allocations
* This results in a SIGABRT in mm-qcamera-daemon from a
__fortify_fatal call in HandleUsingDestroyedMutex in libc
* To work around this, phtread_mutex_destroy and phtread_cond_destroy
moved outside of the loop so they only calls 1 time
* ASM instructions
before:
.text:00007662 LDR R6, [SP,#0x40+ptr]
.text:00007664 ADD R5, R9
.text:00007666 SUBS R7, #1
.text:00007668 BNE loc_7606
.text:0000766A ADD.W R0, R6, #0x146000
.text:0000766E ADD.W R0, R0, #0x5A0 ; mutex
.text:00007672 BLX pthread_mutex_destroy
after:
.text:00007662 MOVS R0, R0
.text:00007664 MOVS R0, R0
.text:00007666 MOVS R0, R0
.text:00007668 MOVS R0, R0
.text:0000766A ADD.W R0, R6, #0x146000
.text:0000766E ADD.W R0, R0, #0x5A0 ; mutex
.text:00007672 BLX pthread_mutex_destroy
Change-Id: I36dfab9f3afb8c9e010da8c6b02c2d9eff856c07
Unless the device crashes few times at the first boot
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: I0d48eeaf4b434280657b00753b4bf287b160f2f7
writepid command usage to join a cgroup has been deprecated in favor
of a more flexible approach using task_profiles. This way cgroup path
is not hardcoded and cgroup changes can be easily made. Replace
writepid with task_profiles command to migrate between cgroups.
Bug: 191283136
Test: build and boot
Refers to:
https://review.lineageos.org/c/LineageOS/android_device_xiaomi_gauguin/+/324467
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: I0005d141f15713f277d1de3be46fd3c25de8deef
To fix the error below:
E ashmem : memfd: ro.vndk.version not defined or invalid (), this is mandated since P
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: Id019485ed9432d7780e64bacf8781656fb595248
This service got uprev'd in hardware/samsung project.
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: I59705292f45bd76cd76355fd345d6a3495ece62f
This resolves the absence of the following symbol:
_ZN7android23sp_report_stack_pointerEv
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: I04538953f867bcf057511240429b09cbcffbbfde
Google's prebuilt cgroups.json and task_profiles.json for products
launched with previous API levels only covers
ro.product.first_api_level >= 28. [1]
gts3l were launched with Nougat (API level 24), so schedtune and
task groups are completely broken. Since the system also checks
/vendor/etc for vendor profiles, make a copy of cgroups_28.json
and task_profiles_28.json and ship them to /vendor/etc. Profiles
for previous API levels are all the same anyway.
Test: boot and check /dev/stune/
[1] system/core/libprocessgroup/profiles/
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: I2d57d7d0c35357d1f4fd30fb2d6f99a83ee01e84
This change replaces the '/system/lib64/libsurfaceflinger.so' pin, as
the file was removed in ag/12524602. The updated pin relies on
go/aog/1552085, as system_service needs read access to SurfaceFlinger.
Bug: 176197656
Test: adb shell dumpsys pinner (coral)
- shows that /system/bin/surfaceflinger is successfully pinned
adb logcat | grep PinnerService (coral)
- no longer shows a file-not-found error in PinnerService
This commit refers:
https://review.lineageos.org/c/LineageOS/android_device_samsung_gts4lv-common/+/320761/1
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: I58a9abaa556a41aed4710daa16989e781191e324
Reffered:
https://review.lineageos.org/c/LineageOS/android_device_samsung_s3ve3g-common/+/317701
"""
Shipping API level less than 24 corresponds to legacy FCM version.
This addresses the following build warning:
Warning: Shipping FCM Version is inferred from Shipping API level. Declare Shipping FCM Version in device manifest directly.
Change-Id: Ib230c345ff7deb552597824838b8809ceefbbe8a
"""
Signed-off-by: Deokgyu Yang <secugyu@gmail.com>
Change-Id: I7bb701d895c6e7772abeb50b2f9254c1a74d8142
Camera HAL includes a check for "service.bootanim.exit" property to
discern boot status and avoid notifying display HAL that a camera
session is active during the bootup phase. Turns out that now, with
a mix of old camera HAL and new display service, the display API
doesn't seem to be called properly leaving camera HAL in a bad state.
Just skip notifying display HAL by fooling the camera HAL into believing
that bootup phase never finished.
Change-Id: I2a12b5373e2ea851fa9d678c3cee9dab9daf25f8