[ROM][UNOFFICIAL][MONTHLY] Pixel Experience 13 [NORMAL/PLUS] for Xiaomi Mi 9 SE

[-+BB+-]

I am trying to figure out why my pay app called Mir sometimes doesn't work, it might not start, crashes immediately, or hangs up on the its loading screen. So I installed MatLog with root privileges to gather logs when aforementioned app misbehaves. As far as I understand there is something to do with the app being hanged in the background.
View attachment 5919701
Killing the app in apps overview doesnt solve the issue, but forse stop does.

There are not so much info in locgat but tracking the PID of the app I saw this:

W/FirebaseInstanceId(20719): Token retrieval failed: SERVICE_NOT_AVAILABLE. Will retry token retrieval

There's a lot of reports for this error searching on Google, apparently is something related to the app and how firabase has been implemented

这些是我切换回 FBEV1 的新日志
DMESG 日志仍然有深度睡眠问题

1 - As i told to another user please write in english
2 - This is a development thread for my ROM, not yours. You first post here was a report with deep sleep issues with my kernel and PE/PE Plus, but you are compiling your own version with your own changes, otherwise i should have several reports for this bug, but no one reported it since the initial release. Additionally you merged various commits that I don't have on both kernel and dt, and I'm not sure that are 100% safe/working on our device:
sdm710-common: overlay: Offload WM shell to another thread did you check that the separate thread is properly ending and doesn't stuck in the background? I'm asking because I'm not using it and I have no idea about how AOSP handle this but if the thread stuck in background may be a problem for deep sleep
sdm710-common: Disable per-cgroup PSI accounting it's a noop, needs the companion change in kernel
sdm710-common: Set virtual displays to 0 do we have that prop in QCOM sdm845 display HAL? I'm afraid that the prop does nothing
sdm710-common: rootdir: Get back to default from long-standing VM tweaks that values are already set by default on Android 13
arm64: Inline the spin lock function family should be used with LTO, but we are not compiling the kernel with LTO (at least not me)
sdm710-common: Remove LED entries nodes in init.qcom.rc are used by the torch, you can see by yourself the value on /sys/class/leds/led:switch_0/brightness changing when you enable/disable torch, pretty sure they are needed (if the nodes owner is the root user then probably not everything will work as expected)
sdm710-common: Reduce number of CPUs for system-background apps i'm not sure that this really help on Grus, at least not in my ROM where i have several services binded to system-background cpuset, should be tested if really has benefits and how impacts with deep sleep (it should not break it, but may reduce the deep sleep time)

You may also want to merge this: sched/tune: raise group count to 7 because we have 7 groups and without this sched tune is partially broken.
Last thing: did you try to see what process is keeping the phone awake? Why you are sure is kernel related? I'm asking because I did not see anything strange in dmesg

NOTE: I haven't reviewed all the changes merged in your branches, I just did a partial review but unless i missed them also CVE fixes has not been merged

Hello dear developer, I found the new bud while calling Via Viber. Have a great day bro.

Hi, I've tried to reproduce it with Whatsapp/Telegram/Viber but It's working fine with all the apps for me (I made 3 video calls for every app, worked all the times). It's happening even taking photo/videos with Viber or only when you made a video call?

 

[makrei]

Is there pocket mode for this ROM? I have tap to wake on so I can use long press on fingerprint, but every time I put it in my pocket it always ends up opening the emergency menu.

 

[givemerobot]

I wanna say thank you for your great rom, which is one of the best I've ever used, and for your support and patience.

 

[Toyohama]

There are not so much info in locgat but tracking the PID of the app I saw this:

W/FirebaseInstanceId(20719): Token retrieval failed: SERVICE_NOT_AVAILABLE. Will retry token retrieval

There's a lot of reports for this error searching on Google, apparently is something related to the app and how firabase has been implemented



1 - As i told to another user please write in english
2 - This is a development thread for my ROM, not yours. You first post here was a report with deep sleep issues with my kernel and PE/PE Plus, but you are compiling your own version with your own changes, otherwise i should have several reports for this bug, but no one reported it since the initial release. Additionally you merged various commits that I don't have on both kernel and dt, and I'm not sure that are 100% safe/working on our device:
sdm710-common: overlay: Offload WM shell to another thread did you check that the separate thread is properly ending and doesn't stuck in the background? I'm asking because I'm not using it and I have no idea about how AOSP handle this but if the thread stuck in background may be a problem for deep sleep
sdm710-common: Disable per-cgroup PSI accounting it's a noop, needs the companion change in kernel
sdm710-common: Set virtual displays to 0 do we have that prop in QCOM sdm845 display HAL? I'm afraid that the prop does nothing
sdm710-common: rootdir: Get back to default from long-standing VM tweaks that values are already set by default on Android 13
arm64: Inline the spin lock function family should be used with LTO, but we are not compiling the kernel with LTO (at least not me)
sdm710-common: Remove LED entries nodes in init.qcom.rc are used by the torch, you can see by yourself the value on /sys/class/leds/led:switch_0/brightness changing when you enable/disable torch, pretty sure they are needed (if the nodes owner is the root user then probably not everything will work as expected)
sdm710-common: Reduce number of CPUs for system-background apps i'm not sure that this really help on Grus, at least not in my ROM where i have several services binded to system-background cpuset, should be tested if really has benefits and how impacts with deep sleep (it should not break it, but may reduce the deep sleep time)

You may also want to merge this: sched/tune: raise group count to 7 because we have 7 groups and without this sched tune is partially broken.
Last thing: did you try to see what process is keeping the phone awake? Why you are sure is kernel related? I'm asking because I did not see anything strange in dmesg

NOTE: I haven't reviewed all the changes merged in your branches, I just did a partial review but unless i missed them also CVE fixes has not been merged


Hi, I've tried to reproduce it with Whatsapp/Telegram/Viber but It's working fine with all the apps for me (I made 3 video calls for every app, worked all the times). It's happening even taking photo/videos with Viber or only when you made a video call?

There are not so much info in locgat but tracking the PID of the app I saw this:

W/FirebaseInstanceId(20719): Token retrieval failed: SERVICE_NOT_AVAILABLE. Will retry token retrieval

There's a lot of reports for this error searching on Google, apparently is something related to the app and how firabase has been implemented



1 - As i told to another user please write in english
2 - This is a development thread for my ROM, not yours. You first post here was a report with deep sleep issues with my kernel and PE/PE Plus, but you are compiling your own version with your own changes, otherwise i should have several reports for this bug, but no one reported it since the initial release. Additionally you merged various commits that I don't have on both kernel and dt, and I'm not sure that are 100% safe/working on our device:
sdm710-common: overlay: Offload WM shell to another thread did you check that the separate thread is properly ending and doesn't stuck in the background? I'm asking because I'm not using it and I have no idea about how AOSP handle this but if the thread stuck in background may be a problem for deep sleep
sdm710-common: Disable per-cgroup PSI accounting it's a noop, needs the companion change in kernel
sdm710-common: Set virtual displays to 0 do we have that prop in QCOM sdm845 display HAL? I'm afraid that the prop does nothing
sdm710-common: rootdir: Get back to default from long-standing VM tweaks that values are already set by default on Android 13
arm64: Inline the spin lock function family should be used with LTO, but we are not compiling the kernel with LTO (at least not me)
sdm710-common: Remove LED entries nodes in init.qcom.rc are used by the torch, you can see by yourself the value on /sys/class/leds/led:switch_0/brightness changing when you enable/disable torch, pretty sure they are needed (if the nodes owner is the root user then probably not everything will work as expected)
sdm710-common: Reduce number of CPUs for system-background apps i'm not sure that this really help on Grus, at least not in my ROM where i have several services binded to system-background cpuset, should be tested if really has benefits and how impacts with deep sleep (it should not break it, but may reduce the deep sleep time)

You may also want to merge this: sched/tune: raise group count to 7 because we have 7 groups and without this sched tune is partially broken.
Last thing: did you try to see what process is keeping the phone awake? Why you are sure is kernel related? I'm asking because I did not see anything strange in dmesg

NOTE: I haven't reviewed all the changes merged in your branches, I just did a partial review but unless i missed them also CVE fixes has not been merged


Hi, I've tried to reproduce it with Whatsapp/Telegram/Viber but It's working fine with all the apps for me (I made 3 video calls for every app, worked all the times). It's happening even taking photo/videos with Viber or only when you made a video call?

Sorry, but I think it may be a problem with the wake-up lock. The language issue may be caused by my browser's automatic translation.I will re inspect it Thank you for your response
EDIT: At the beginning I had occasional deep sleep issues on the March pe. And I sometimes encountered a lot of power consumption problems at night on several roms built by the official los dt, so I guessed at first that it was a kernel problem, but the log was filled with encryption errors, so I couldn't judge the deep sleep problem. I'm an android beginner . And sorry for wasting your time with my question

 

[leowolf22]

Face unlock works?

 

[Phyo231]

There are not so much info in locgat but tracking the PID of the app I saw this:

W/FirebaseInstanceId(20719): Token retrieval failed: SERVICE_NOT_AVAILABLE. Will retry token retrieval

There's a lot of reports for this error searching on Google, apparently is something related to the app and how firabase has been implemented



1 - As i told to another user please write in english
2 - This is a development thread for my ROM, not yours. You first post here was a report with deep sleep issues with my kernel and PE/PE Plus, but you are compiling your own version with your own changes, otherwise i should have several reports for this bug, but no one reported it since the initial release. Additionally you merged various commits that I don't have on both kernel and dt, and I'm not sure that are 100% safe/working on our device:
sdm710-common: overlay: Offload WM shell to another thread did you check that the separate thread is properly ending and doesn't stuck in the background? I'm asking because I'm not using it and I have no idea about how AOSP handle this but if the thread stuck in background may be a problem for deep sleep
sdm710-common: Disable per-cgroup PSI accounting it's a noop, needs the companion change in kernel
sdm710-common: Set virtual displays to 0 do we have that prop in QCOM sdm845 display HAL? I'm afraid that the prop does nothing
sdm710-common: rootdir: Get back to default from long-standing VM tweaks that values are already set by default on Android 13
arm64: Inline the spin lock function family should be used with LTO, but we are not compiling the kernel with LTO (at least not me)
sdm710-common: Remove LED entries nodes in init.qcom.rc are used by the torch, you can see by yourself the value on /sys/class/leds/led:switch_0/brightness changing when you enable/disable torch, pretty sure they are needed (if the nodes owner is the root user then probably not everything will work as expected)
sdm710-common: Reduce number of CPUs for system-background apps i'm not sure that this really help on Grus, at least not in my ROM where i have several services binded to system-background cpuset, should be tested if really has benefits and how impacts with deep sleep (it should not break it, but may reduce the deep sleep time)

You may also want to merge this: sched/tune: raise group count to 7 because we have 7 groups and without this sched tune is partially broken.
Last thing: did you try to see what process is keeping the phone awake? Why you are sure is kernel related? I'm asking because I did not see anything strange in dmesg

NOTE: I haven't reviewed all the changes merged in your branches, I just did a partial review but unless i missed them also CVE fixes has not been merged


Hi, I've tried to reproduce it with Whatsapp/Telegram/Viber but It's working fine with all the apps for me (I made 3 video calls for every app, worked all the times). It's happening even taking photo/videos with Viber or only when you made a video call?

Hello everything work for now but HDR processing time of BSG Gcam is too long. Could you change back to miui cam like other pixel plus rom? I tried to install ANX camera for Android 11 but can't install. BTW I like this rom coz of user can get in touch with developer. Thz and have a great day

 

[TSlak]

Hello everyone. I'm going to ask a very strange question, but how secure is your ROM? Sounds like I asked if they were scammers, they said no)) And I also wonder how easy it is to embed Trojans and other malware into the firmware? Is my paranoia unfounded? Sorry if I offended you, I didn't mean to.

 

[-+BB+-]

Is there pocket mode for this ROM? I have tap to wake on so I can use long press on fingerprint, but every time I put it in my pocket it always ends up opening the emergency menu.

There's a pocket mode like all other ROMs, it' s in ambient display section, but I don't know if will work for your case, as DTTW works in conjuction with power HAL, not ambient display. This is the default implementation for basically all custom ROMs for Grus. BTW it's strange, DTTW should not work when the phone is in your pocket

I wanna say thank you for your great rom, which is one of the best I've ever used, and for your support and patience.

Thanks, really <3

Sorry, but I think it may be a problem with the wake-up lock. The language issue may be caused by my browser's automatic translation.I will re inspect it Thank you for your response
EDIT: At the beginning I had occasional deep sleep issues on the March pe. And I sometimes encountered a lot of power consumption problems at night on several roms built by the official los dt, so I guessed at first that it was a kernel problem, but the log was filled with encryption errors, so I couldn't judge the deep sleep problem. I'm an android beginner . And sorry for wasting your time with my question

No time wasted, don't worry, I've also picked some useful stuffs from your branches for my Gemini and Grus, but if you need me ping me on GitHub, this discussion is for PE ROM, but I have no problem at all on Git if I can help

Face unlock works?

Yes

Hello everything work for now but HDR processing time of BSG Gcam is too long. Could you change back to miui cam like other pixel plus rom? I tried to install ANX camera for Android 11 but can't install. BTW I like this rom coz of user can get in touch with developer. Thz and have a great day

Hi, do you have a link for MIUI and ANX camera? I will take a look at them (at least to see why it doesn't install properly). Regarding HDR processing on GCAM i'm aware of that and I agree with you, I had to take some photos at work in these days and I wanted to launch the phone on the wall a couple of times. I probably understood what's wrong in GCAM, but there's nothing i can do on device side to fix/mitigate that, here's a quote of my message some days ago in Gemini thread:

Set "Disable hexagon" to off. Snapdragon 820 has hexagon processor.

I was taking a look some days ago trying to understand why my Grus is so slow processing HDR photos and I ended up reading QCOM SDK docs, for what I understood Halide operations for custom GCAM doesn't work in any device, and probably will never work. I will try to explain in a simple way: Hexagon devices like our Gemini allow apps to take advantage to DSP processing, which is faster than CPU for some operations like HDR processing. In order to do that, you need two libs: libhalide_hexagon_host.so and libhalide_hexagon_remote_skel.so, these libs can be compiled by anyone using QCOM SDK, signed with a signing key for testing purposes and shipped with the apk. But the test signature does not work in production devices, it works only on debug-signed devices like Dragonboard platforms. Only OEMs or QCOM can sign a working lib for production devices, this means that Hexagon DSP processing sadly will probably never work on GCAM
NOTE: starting from SM8150 devices DSP have an unsigned mode, but there are some limitations and one of them probably breaks HDR processing even on that devices. From SDK docs:

Access to limited drivers i.e. UBWC/DMA and Camera Streamer are not available to Unsigned PDs

There's also another drawback with this bug: if you want to load libhalide_hexagon_host.so and libhalide_hexagon_remote_skel.so from the apk you must set the environment variable ADSP_LIBRARY_PATH. When you set that path on your app, the libs in your apk will override the libs provided with the ROM, this means that if a device have a native working implementation (Pixel devices, some Oneplus phone) the working libraries will be overridden by the libs with the wrong signature, and this will break HDR processing even in devices where is supposed to work fine natively

Log of Hexagon failing:

I com.shamim.cam: vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:865: Successfully opened file /data/user/0/com.shamim.cam/libhalide_hexagon_remote_skel.so
E com.shamim.cam: vendor/qcom/proprietary/adsprpc/src/fastrpc_apps_user.c:1286: Error 0xfffffffb: remote_handle_open_domain: dynamic loading failed for halide_hexagon_remote on domain 0 (dlerror signature
verify start failed for libhalide_hexagon_remote_skel.so) (errno Success)
E com.shamim.cam: vendor/qcom/proprietary/adsprpc/src/fastrpc_apps_user.c:1304: Error 0xfffffffb: remote_handle_open failed for halide_hexagon_remote (errno Success)
I halide  : Hexagon: remote_poll_log failed 44
E libgcam : [halide_runtime.cc:100]: halide_error: Error: Initialization of Hexagon kernels failed

Additionally, I don't know what QCOM/Xiaomi did on sdm710 dsp, but while all other devices I'm using (msm8996, msm8998, sm6150) has the same identical behaviour [try to load the lib --> signature check fail --> fallback to CPU processing] sdm710 do something different, which is the root cause of our issue [try to load the lib --> signature check fail --> dsp tries again and again to load the lib and obviously fails everytime --> after a random number of failed attempts fallback to CPU processing] This behaviour it's causing the delay in HDR processing, I've tested with Shamim GCAM and disabling hexagon processing from options fixes it.

NOTE: there's a small possibility that we can succesfully use dsp for HDR processing, if libhalide_hexagon_host.so and libhalide_hexagon_remote_skel.so provided by Google on their Pixel has been signed by QCOM then MAY work for our device too (or at least we should be able to pass signature check), i can take a look at them, will require some SEPolicy changes but with selinux permissive add the libs and expose them in public.libraries.txt should be enough, the problem is that modded GCAMs must use them instead the prebuilt version provided with the apk. I can test the libs with QCOM examples, but will probably won't work with GCAM, we need an updatd version that use the ROM libs

Hello everyone. I'm going to ask a very strange question, but how secure is your ROM? Sounds like I asked if they were scammers, they said no)) And I also wonder how easy it is to embed Trojans and other malware into the firmware? Is my paranoia unfounded? Sorry if I offended you, I didn't mean to.

That's absolutely a legit question, and no, you did not offend me Talking about security, I'm shipping a ROM with sources updated to latest AOSP tag, and I've also merged CVE fixes on kernel side, the device is updated like official Pixel phones. There are some compromises on SELinux policy and other parts of the ROM, because this is a legacy device, we don't have updated proprietary blobs, and some stuffs needs legacy code removed from AOSP sources or works in a totally different way than recent phones, but we are running SELinux in enforcing mode (QCOM provide sepolicy rules for legacy devices too), we have a good security level. Regarding the trojan in firmware/dsp as far as i know this is something that only an OEM can do, I don't have QCOM/Xiaomi signing key, if I put something on dsp it will be rejected (basically the same issue we have with Hexagon processing on GCAM), and I'm not shipping the modem firmware with the ROM, you use the stock firmware provided by Xiaomi.
It would be possible to embed a trojan/malware on ROM side, but for this reason the code is 100% public, you are totally free to review it and compile it by yourself, it's pretty simple, you only need a linux distro, 600 Gb free on an ssd, at least 18/20 Gb of RAM (or add a swap space to reach at least 18/20 Gb of RAM+Swap), and some hours for compiling (depends on your CPU), it's rather easy, just replace PE audio/video/media repos in hardware/qcom-caf/sdm845 with LOS version because PE repos are broken for sdm710 and build fails. hardware/xiaomi repo must be manually downloaded at the moment, but i will add the dependency to dt so it will be downloaded automatically. You can build both stock/plus version with my repos, links are in the OP

PS: if you are interested, i was reading some days ago an analysis made by Check Point Research on DSP vulnerabilities, there is a great explanation about how QCOM DSP works and the security implications

 

[Phyo231]

There's a pocket mode like all other ROMs, it' s in ambient display section, but I don't know if will work for your case, as DTTW works in conjuction with power HAL, not ambient display. This is the default implementation for basically all custom ROMs for Grus. BTW it's strange, DTTW should not work when the phone is in your pocket


Thanks, really <3


No time wasted, don't worry, I've also picked some useful stuffs from your branches for my Gemini and Grus, but if you need me ping me on GitHub, this discussion is for PE ROM, but I have no problem at all on Git if I can help


Yes


Hi, do you have a link for MIUI and ANX camera? I will take a look at them (at least to see why it doesn't install properly). Regarding HDR processing on GCAM i'm aware of that and I agree with you, I had to take some photos at work in these days and I wanted to launch the phone on the wall a couple of times. I probably understood what's wrong in GCAM, but there's nothing i can do on device side to fix/mitigate that, here's a quote of my message some days ago in Gemini thread:

Additionally, I don't know what QCOM/Xiaomi did on sdm710 dsp, but while all other devices I'm using (msm8996, msm8998, sm6150) has the same identical behaviour [try to load the lib --> signature check fail --> fallback to CPU processing] sdm710 do something different, which is the root cause of our issue [try to load the lib --> signature check fail --> dsp tries again and again to load the lib and obviously fails everytime --> after a random number of failed attempts fallback to CPU processing] This behaviour it's causing the delay in HDR processing, I've tested with Shamim GCAM and disabling hexagon processing from options fixes it.

NOTE: there's a small possibility that we can succesfully use dsp for HDR processing, if libhalide_hexagon_host.so and libhalide_hexagon_remote_skel.so provided by Google on their Pixel has been signed by QCOM then MAY work for our device too (or at least we should be able to pass signature check), i can take a look at them, will require some SEPolicy changes but with selinux permissive add the libs and expose them in public.libraries.txt should be enough, the problem is that modded GCAMs must use them instead the prebuilt version provided with the apk. I can test the libs with QCOM examples, but will probably won't work with GCAM, we need an updatd version that use the ROM libs


That's absolutely a legit question, and no, you did not offend me Talking about security, I'm shipping a ROM with sources updated to latest AOSP tag, and I've also merged CVE fixes on kernel side, the device is updated like official Pixel phones. There are some compromises on SELinux policy and other parts of the ROM, because this is a legacy device, we don't have updated proprietary blobs, and some stuffs needs legacy code removed from AOSP sources or works in a totally different way than recent phones, but we are running SELinux in enforcing mode (QCOM provide sepolicy rules for legacy devices too), we have a good security level. Regarding the trojan in firmware/dsp as far as i know this is something that only an OEM can do, I don't have QCOM/Xiaomi signing key, if I put something on dsp it will be rejected (basically the same issue we have with Hexagon processing on GCAM), and I'm not shipping the modem firmware with the ROM, you use the stock firmware provided by Xiaomi.
It would be possible to embed a trojan/malware on ROM side, but for this reason the code is 100% public, you are totally free to review it and compile it by yourself, it's pretty simple, you only need a linux distro, 600 Gb free on an ssd, at least 18/20 Gb of RAM (or add a swap space to reach at least 18/20 Gb of RAM+Swap), and some hours for compiling (depends on your CPU), it's rather easy, just replace PE audio/video/media repos in hardware/qcom-caf/sdm845 with LOS version because PE repos are broken for sdm710 and build fails. hardware/xiaomi repo must be manually downloaded at the moment, but i will add the dependency to dt so it will be downloaded automatically. You can build both stock/plus version with my repos, links are in the OP

PS: if you are interested, i was reading some days ago an analysis made by Check Point Research on DSP vulnerabilities, there is a great explanation about how QCOM DSP works and the security implications

Hello bro! here ANX camera link
--https://camera.aeonax.com/

Here are MIUI camera magisk module

MiuiCamera [Magisk Module]

MiuiCamera for AOSP A11,A12 and A13 Custom ROMs, properly tested on miatoll devices but may work on other devices as well.

store.kde.org

 

[YH297]

YH297

 

[Toyohama]

There's a pocket mode like all other ROMs, it' s in ambient display section, but I don't know if will work for your case, as DTTW works in conjuction with power HAL, not ambient display. This is the default implementation for basically all custom ROMs for Grus. BTW it's strange, DTTW should not work when the phone is in your pocket


Thanks, really <3


No time wasted, don't worry, I've also picked some useful stuffs from your branches for my Gemini and Grus, but if you need me ping me on GitHub, this discussion is for PE ROM, but I have no problem at all on Git if I can help


Yes


Hi, do you have a link for MIUI and ANX camera? I will take a look at them (at least to see why it doesn't install properly). Regarding HDR processing on GCAM i'm aware of that and I agree with you, I had to take some photos at work in these days and I wanted to launch the phone on the wall a couple of times. I probably understood what's wrong in GCAM, but there's nothing i can do on device side to fix/mitigate that, here's a quote of my message some days ago in Gemini thread:

Additionally, I don't know what QCOM/Xiaomi did on sdm710 dsp, but while all other devices I'm using (msm8996, msm8998, sm6150) has the same identical behaviour [try to load the lib --> signature check fail --> fallback to CPU processing] sdm710 do something different, which is the root cause of our issue [try to load the lib --> signature check fail --> dsp tries again and again to load the lib and obviously fails everytime --> after a random number of failed attempts fallback to CPU processing] This behaviour it's causing the delay in HDR processing, I've tested with Shamim GCAM and disabling hexagon processing from options fixes it.

NOTE: there's a small possibility that we can succesfully use dsp for HDR processing, if libhalide_hexagon_host.so and libhalide_hexagon_remote_skel.so provided by Google on their Pixel has been signed by QCOM then MAY work for our device too (or at least we should be able to pass signature check), i can take a look at them, will require some SEPolicy changes but with selinux permissive add the libs and expose them in public.libraries.txt should be enough, the problem is that modded GCAMs must use them instead the prebuilt version provided with the apk. I can test the libs with QCOM examples, but will probably won't work with GCAM, we need an updatd version that use the ROM libs


That's absolutely a legit question, and no, you did not offend me Talking about security, I'm shipping a ROM with sources updated to latest AOSP tag, and I've also merged CVE fixes on kernel side, the device is updated like official Pixel phones. There are some compromises on SELinux policy and other parts of the ROM, because this is a legacy device, we don't have updated proprietary blobs, and some stuffs needs legacy code removed from AOSP sources or works in a totally different way than recent phones, but we are running SELinux in enforcing mode (QCOM provide sepolicy rules for legacy devices too), we have a good security level. Regarding the trojan in firmware/dsp as far as i know this is something that only an OEM can do, I don't have QCOM/Xiaomi signing key, if I put something on dsp it will be rejected (basically the same issue we have with Hexagon processing on GCAM), and I'm not shipping the modem firmware with the ROM, you use the stock firmware provided by Xiaomi.
It would be possible to embed a trojan/malware on ROM side, but for this reason the code is 100% public, you are totally free to review it and compile it by yourself, it's pretty simple, you only need a linux distro, 600 Gb free on an ssd, at least 18/20 Gb of RAM (or add a swap space to reach at least 18/20 Gb of RAM+Swap), and some hours for compiling (depends on your CPU), it's rather easy, just replace PE audio/video/media repos in hardware/qcom-caf/sdm845 with LOS version because PE repos are broken for sdm710 and build fails. hardware/xiaomi repo must be manually downloaded at the moment, but i will add the dependency to dt so it will be downloaded automatically. You can build both stock/plus version with my repos, links are in the OP

PS: if you are interested, i was reading some days ago an analysis made by Check Point Research on DSP vulnerabilities, there is a great explanation about how QCOM DSP works and the security implications

In addition, I found the reason for the abnormal deep sleep. It seems to be because of the problem of the screen off fod. The fingerprint module in the log prevents the deep sleep, and everything returns to normal after the screen off fod is turned off.

[   43.208163] [GTP-INF][gsx_gesture_before_suspend:737] Set IC in doze mode
[   43.208167] [GTP-INF][goodix_ts_suspend:1880] suspend_stat[3]
[   43.208172] [GTP-INF][goodix_ts_suspend:1881] Canceled by module:Goodix_gsx_gesture
[   43.208179] [GTP-INF][goodix_ts_suspend:1931] Suspend end

 

[TSlak]

thank you, I really liked the ROM. And what is the difference between the plus version? Is it also possible to turn on the usual one so that the percentages are shown, and not the prediction of the battery? And 4g instead of lte?

 

[Pumukk]

Hi, this ROM seems amazing. How much time of screen time do you get with it?

 

[TSlak]

Hi, this ROM seems amazing. How much time of screen time do you get with it?

100-57% percent - 3:39 display on. But I have a new battery
UPD: 100-20% 6:09

 

[Carlos2100]

When will It was update this rom?

thanks

 

[nathankaunang]

how to root? when i change twrp to latest twrp but bootloop

 

[drik05]

Finally managed to install this rom on my old Grus. So far so good. No bugs so far. Thank you

 

[drik05]

One thing, do we have an option to hide the notch ? I installed pe+ version. The notch shape is not good in this rom.

 

[-+BB+-]

Hello bro! here ANX camera link
--https://camera.aeonax.com/

Here are MIUI camera magisk module

MiuiCamera [Magisk Module]

MiuiCamera for AOSP A11,A12 and A13 Custom ROMs, properly tested on miatoll devices but may work on other devices as well.

store.kde.org

I took a look and MIUI camera require several changes in order to properly work:
1 - PE does not support at all MIUI camera, there's a topic open in PE Gerrit, but it's WIP and cannot be merged as is (I'm 100% sure that jemalloc breaks things on gemini/msm8996 devices, so at least the bionic part must be changed)
2 - When the topic will be merged i will see if i can merge all the needed changes in dt and proprietary files repo, because i don't want to import MIUI gallery or other things that may break some PE functionality, and there are also some changes in SEPolicy that sounds wrong to me, I must revisit them before merge SELinux rules

In addition, I found the reason for the abnormal deep sleep. It seems to be because of the problem of the screen off fod. The fingerprint module in the log prevents the deep sleep, and everything returns to normal after the screen off fod is turned off.

[   43.208163] [GTP-INF][gsx_gesture_before_suspend:737] Set IC in doze mode
[   43.208167] [GTP-INF][goodix_ts_suspend:1880] suspend_stat[3]
[   43.208172] [GTP-INF][goodix_ts_suspend:1881] Canceled by module:Goodix_gsx_gesture
[   43.208179] [GTP-INF][goodix_ts_suspend:1931] Suspend end

I should take a look at FP sources, but as far as i remember that log should not be related to deep sleep as FP module is stopping screen suspend, which is what should happen if you want to use FOD with the screen off

thank you, I really liked the ROM. And what is the difference between the plus version? Is it also possible to turn on the usual one so that the percentages are shown, and not the prediction of the battery? And 4g instead of lte?

Plus version has some additional customisation and options, like battery icon shape, network indicator, etc.
Battery prediction has been added by AOSP and there are no option for disabling it, at least last time I checked, when you enable battery percentage battery prediction will be enabled too (stock AOSP behaviour).
Regarding 4G/LTE what carrier are you using? Some carriers use custom configurations and LTE is displayed instead of 4G

When will It was update this rom?

thanks

When PE devs will merge QPR3 in ROM sources

how to root? when i change twrp to latest twrp but bootloop

I do not support rooting or TWRP, but you should be able to root your device even with stock recovery

One thing, do we have an option to hide the notch ? I installed pe+ version. The notch shape is not good in this rom.

Notch shape will be fixed in next release: grus: overlay: Set config_mainBuiltInDisplayCutout

 

[drik05]

Notch shape will be fixed in next release: grus: overlay: Set config_mainBuiltInDisplayCutout

I appreciate it very much. I'll stay in this rom
to see what comes along, hoping for an
official build. Thank you for your work