no problem with proximity sensor for me on latest build. Everything works fine.@ganesh varma I appreciate the effort they make to keep this great ROM up to date.
Personally I decided to stay for a while on the latest build with MIUI Vendor, because all firmwares (except 12.0.7 android 10 global version and earlier) have problems with the proximity sensor. The build of "20210503" it's rock solid, and it's excellent for use it as a daily driver.
I will wait for android 11 to be officially released for the global version, waiting for the problem with the proximity sensor to be corrected I am sure that many have this problem and have not realized it. But if anyone looking for a solution, just flash global firmware 12.0.7.
Can you please be more specific?
android_bootable_recovery: recovery: Allow custom bootloader msg offset in block misc
android_bootable_recovery: recovery: use ensure_volume_unmounted in format_volume
android_bootable_recovery: bootable: Read all asserts in case there are more than one
android_bootable_recovery: recovery_ui: Tell the user they're actually formatting
android_bootable_recovery: recovery: Remove the "Format system partition" menu on A/B devices
android_bootable_recovery: recovery: Map logical partitions before installation
android_bootable_recovery: recovery: Draw header lines with less padding
android_bootable_recovery: recovery: Always use the text menu for rescue party
android_bootable_recovery: recovery: allow A/B updater to downgrade
android_bootable_recovery: minui: Allow skipping EV_REL input devices.
android_bootable_recovery: Return the correct action for PromptAndWait
android_bootable_recovery: recovery: Allow going back in rescue party menu
android_bootable_recovery: recovery: Support writing to Virtual A/B partitions
android_bootable_recovery: recovery: Add ability to unmount system
android_bootable_recovery: Add controller support
android_bootable_recovery: roots: Correct mount flags in /etc/fstab
android_build: Remove unused locale data for recovery
android_vendor_arrow: soong: Export bootloader_message_offset to dependencies
android_build_soong: soong: Add equivalent for LOCAL_EXPORT_CFLAGS
android_bootable_recovery: recovery: Set the INFO color to white
android_bootable_recovery: recovery: Clarify help text
android_bootable_recovery: recovery: Draw the help message below the menu on non-touch devices
android_bootable_recovery: recovery: Display recovery version
android_bootable_recovery: recovery: Print the active slot
Just tested todays 20210514 build. Autoupdate did not work. On first try it hangs at 100% restarting. On second try it reboots into recovery and thats it. I had to flash it manually. To do so I had to format data (lost all data) again because decryption does not work with current recoveries. Currently I would just recommend everyone to stay on 2021.05.03 and wait till we get recoveries which work with decryption.
I feel like the problem is that downloading the ROM-breaking update through the official updater only opens https://arrowos.net/changelog.php, which looks like this:So i haven't been around here for a while, after looking at the recent posts many seem to be confused, blaming and do not understand on migrating to OSS builds. In the final MIUI vendor builds the OTA functionality was blocked in order to prevent users from directly updating to OSS builds as it will be needing a MIUI 11 firmware followed by a clean flash. The same has been notified in our device changelogs. Every step and preventive measures have been taken, there's only much i can do from my side in clearing things up. We have this forum and community in place to help each other out, so lets not be pointing fingers here!
Here again i would like to make it clear with a simple guide on how to migrate onto OSS build!
Note: This update will require a CLEAN FLASH (format data), so please backup everything beforehand.
Beware that the current available recoveries haven't been updated yet to support decryption for OSS builds at this point.
- Flash the latest available MIUI 11 firmware. (Region doesn't matter!!)
- Now flash Arrow Vanilla/Gapps build.
- FORMAT DATA. (You'll loose all your data!)
And to which location on the device do you push the file with data being encrypted?
I don't understand how someone can actually get into troubles with this, as OTA updates have been blocked after the 20210503 nightly, which means you can not update through the updater and it gives a proper explanation and warning:I feel like the problem is that downloading the ROM-breaking update through the official updater only opens https://arrowos.net/changelog.php... There's nothing in there giving me any kind of warning. The actual warning is found in our device specific changelog... Which is still far too little, too calm, imo. There should be a big fat red warning in the changelog that opens when you download the 12.05. update like: ⚠ !!! WARNING !!! ⚠ THIS WILL BOOTLOOP YOUR ROM IF YOU DON'T FOLLOW INSTRUCTIONS CAREFULLY! YOU WILL LOSE YOUR DATA!
That's what I thought, no messing around with adb, but simply use an OTG USB device (which is very handy, I have a 256GB USB stick with an USB-A connector at one end and an USB-C connector at the other end) containing the file.
I got the same message today, even though I'm using 20210601 build.
Alright, I think I got it working. I had Magisk Hide for Google apps and banking already activated. I hadn't hidden the manager yet though.
To everyone, please STOP this misconception about having the need to flash magisk in order to pass safety net. Do read the OP I've clearly mentioned there's no need of a magisk or modules for safety net. Device is certified and passes safety net out of the box without need of any modifications.Mission Impossible in all custom ROMs !
1. Safetynet check the bootloader status and will automatically fail if magisk is not installed (Magisk Hide ON must be applied for this) !
2. Furthermore, now you have to install the safetynet-fix module to make your banking apps working !
3. Finally, you must hide Magisk Manager.apk with a random name too (Magisk Settings)
I'm aware of the notification led issue, its interlinked to an sepolicy denial from vendor which is quite tricky to address it while we're using the prebuilt/stock vendor. For now you can assume it as a trade off for enforcing builds. I'm working on a fix, once we start a full transition towards an OSS vendor these issues will be more convenient to be addressed.