Ok, fine, maybe. Btw, Alarm is more important for me and for Timer there is IMO no problem to keep the app in background for those few minutes you run the Timer
I'm not the first one who reported. For the previous Weekly several users reported exactly the same, and exactly for the same app, posting also screenshots showing the two blue icons in a Drawer, one of them marked as if it is a 'dual' app
As I checked and noted in my previous post, it is the app coming preinstalled to /system/priv-app hence it is not a user app that I installed myself - and I don't need it.
Besides, there is also MIUI File's app (yellow icon) preinstalled with your ROM
Didn't see that in replays, but in previous update in Xiaomi 11 the DND mode turns by itself every day at 12AM.. checked all settings for that and seen nothing, the schedule in DND mode is off
Any suggestions?
I'm not the first one who reported. For the previous Weekly several users reported exactly the same, and exactly for the same app, posting also screenshots showing the two blue icons in a Drawer, one of them marked as if it is a 'dual' app
As I checked and noted in my previous post, it is the app coming preinstalled to /system/priv-app hence it is not a user app that I installed myself - and I don't need it.
Besides, there is also MIUI File's app (yellow icon) preinstalled with your ROM
Not show anymore on my (Lisa). I got trouble when I was playing with magisk module, my launcher keep stoping, I try to reboot but not reboot to system so I clear the data from the recovery then now it's no see it anymore
I checked and also worked for me for now. I will do more testing to be sure. I did some testing and Notification are not working properly for messenger and discord :/
Then something is wrong on your device, not the ROM. DocumentsUIGoogle is not something we add, it's included with all stock ROMs and it does not have a launcher icon.
It's entirely possible that framework was configured to auto-clone the platform Files app, probably for media access permissions for cloned apps that require it. I'm just not sure why that app's icon is showing when it's not supposed to, perhaps being cloned triggered that behavior. Doesn't look much of an issue, Files app is not the only one that gets cloned by the framework for other cloned apps to work correctly (you just don't see their icons).
Also, it's not exactly "Google Files", it's just "Files" (com.google.android.documentsui, formerly com.android.documentsui), while "Google Files" or "Files by Google" (com.google.android.apps.nbu.files) is an entirely different app available on Play Store.
It's entirely possible that framework was configured to auto-clone the platform Files app, probably for media access permissions for cloned apps that require it. I'm just not sure why that app's icon is showing when it's not supposed to, perhaps being cloned triggered that behavior. Doesn't look much of an issue, Files app is not the only one that gets cloned by the framework for other cloned apps to work correctly (you just don't see their icons).
Also, it's not exactly "Google Files", it's just "Files" (com.google.android.documentsui, formerly com.android.documentsui), while "Google Files" or "Files by Google" (com.google.android.apps.nbu.files) is an entirely different app available on Play Store.
Chip in on this topic. Yes, when you create dual apps it creates another "profile" for those apps, which means many of the GMS services are cloned too, not just the files app. If you have Google One installed, the cloned gOne app will prompt you daily to do backup too.
Speaking of Google One backup, yes, in the previous version, the backup was removed after reboot. However in this version the backup is still there, at least according to the app itself.
It's entirely possible that framework was configured to auto-clone the platform Files app, probably for media access permissions for cloned apps that require it. I'm just not sure why that app's icon is showing when it's not supposed to, perhaps being cloned triggered that behavior. Doesn't look much of an issue, Files app is not the only one that gets cloned by the framework for other cloned apps to work correctly (you just don't see their icons).
Also, it's not exactly "Google Files", it's just "Files" (com.google.android.documentsui, formerly com.android.documentsui), while "Google Files" or "Files by Google" (com.google.android.apps.nbu.files) is an entirely different app available on Play Store.
Understand but the main problem is this dual app doesn't shows up in inbuilt app lock apps list so in a way i can't lock it which means it clearly gives file explorer access to anyone even if all apps are locked. Can this app be removed in future updates (its in priv-app>> documentsui) Because now system comes readonly.
Understand but the main problem is this dual app doesn't shows up in inbuilt app lock apps list so in a way i can't lock it which means it clearly gives file explorer access to anyone even if all apps are locked. Can this app be removed in future updates (its in priv-app>> documentsui) Because now system comes readonly.
I checked and also worked for me for now. I will do more testing to be sure. I did some testing and Notification are not working properly for messenger and discord :/
problem is back after few hours, also some lags but less with "Fluid N.G."...what i've recognized all apps with google account are lagging and homescreen, when i open a non google account app like Performance Tweaker, there is no lag on volume button
Not reporting a bug, I'm interested mainly out of couriosity
Lisa (Mi 11 Lite 5G NE) is A/B device and if I switch the active slot to _b (eg, from the custom recovery installed by the Weekly), it won't boot, it goes straight to Fastboot
Of course, I can unbrick from Fastboot by switching back the active slot to _a:
fastboot --set-active=a
and then I can again properly boot either to the System or Recovery
When I look into the Weekly OTA zip, to the main script META-INF/com/googlee/android/updater-script,
(at the beginning) it flashes the following partitions (same images) both to slots _a and _b:
dsp, xbl_config, modem, tz, bluetooth, abl, cpucp, featenabler, keymaster, uefisecapp, uefisecapp, qupfw, xbl, devcfg, hyp, imagefv, shrm, aop
and later (at the end) it flashes also the remaining (not resizable) partitions both to the slots _a and _b:
boot, vendor_boot, dtbo, vbmeta, and vbmeta_system
In the mean, for the dynamic partitions, it calls update_dynamic_partitions by using dynamic_partitions_op_list.
In the first part it handles again in parallel both slots _a and _b for:
system, system_ext, product, vendor, odm
Eg:
# Add partition system_a to group qti_dynamic_partitions_a
add system_a qti_dynamic_partitions_a
# Add partition system_b to group qti_dynamic_partitions_b
add system_b qti_dynamic_partitions_b
But eventually it resizes super (system, system_ext, vendor, product and odm) only for the slot _a):
# Grow partition system_a from 0 to 3304910848
resize system_a 3304910848
# Grow partition system_ext_a from 0 to 520441856
resize system_ext_a 520441856
# Grow partition product_a from 0 to 935149568
resize product_a 935149568
# Grow partition vendor_a from 0 to 2183393280
resize vendor_a 2183393280
# Grow partition odm_a from 0 to 18120704
resize odm_a 18120704
and then back in updater-script it flashes system, system_ext product vendor, and odm also only to slot _a:
As said, above, I'm kind of puzzled why it cannot reboot to Recovery _b (since it is integrated to boot_b, where boot_b was properly flashed)
Moreover, I'm courious what for the updater_script bothers to flash the non-dynamic partitions also to the slot_b, when, at the end, slot _b is not bootable (it looks that for some reason dynamic super partitions were not resized and not flashed to slot _b)
Or maybe, super (system, system_ext, product, vendor and odm) are supposed to be common for both partitions (hence resized and flashed only for one slot) - but then again, why _b is not bootable
Sorry if the (design) reasons for the not-bootable slot _b were somewhere already asked and answered - I searched but I mostly ffound statements that _b is not bootable and how to switch to _a...
Probably it comes from Xiaomi Beta releases (having the same not bootable slot _b), but if anybody knows more about all that - thanks
Also, I didn't test how it works for stock ROMs, MIUI 13 (A12), maybe similarly
Not reporting a bug, I'm interested mainly out of couriosity
Lisa (Mi 11 Lite 5G NE) is A/B device and if I switch the active slot to _b (eg, from the custom recovery installed by the Weekly), it won't boot, it goes straight to Fastboot
Of course, I can unbrick from Fastboot by switching back the active slot to _a:
fastboot --set-active=a
snd then I can again properly boot either to the System or Recovery
When I look into the Weekly OTA zip, to the main script META-INF/com/googlee/android/updater-script,
(at the beginning) it flashes the following partitions in parallel both for slots _a and _b:
dsp, xbl_config, modem, tz, bluetooth, abl, cpucp, featenabler, keymaster, uefisecapp, uefisecapp, qupfw, xbl, devcfg, hyp, imagefv, shrm, aop
and later (at the end) it flashes also the remaining (not resizable) partitions both to the slots _a and _b:
boot, vendor_boot, dtbo, vbmeta, and vbmeta_system
Regarding to the dynamic partitions, it calls update_dynamic_partitions by using dynamic_partitions_op_list.
In the first part it handles again in parallel both slots _a and _b for:
system, system_ext, product, vendor, odm
Eg:
# Add partition system_a to group qti_dynamic_partitions_a
add system_a qti_dynamic_partitions_a
# Add partition system_b to group qti_dynamic_partitions_b
add system_b qti_dynamic_partitions_b
But eventually it resizes super (system, system_ext, vendor, product and odm) only for the slot _a):
# Grow partition system_a from 0 to 3304910848
resize system_a 3304910848
# Grow partition system_ext_a from 0 to 520441856
resize system_ext_a 520441856
# Grow partition product_a from 0 to 935149568
resize product_a 935149568
# Grow partition vendor_a from 0 to 2183393280
resize vendor_a 2183393280
# Grow partition odm_a from 0 to 18120704
resize odm_a 18120704
and then back in updater-script it flashes system, system_ext product vendor, and odm also only to slot _a:
Replace the word "in parallel" with "sequentially", because flashing in parallel is not possible. Otherwise, you perfectly described the flashing process.
Moreover, I'm courious what for the updater_script bothers to flash the non-dynamic partitions also to the slot_b, when, at the end, slot _b is not bootable (it looks that for some reason dynamic super partitions were not resized and not flashed to slot _b)
Because our fastboot/recovery flash scripts attempt to replicate official fastboot flash scripts as much as possible. "Why bother" you ask? I don't know, and I don't care to find out what happens if we don't do it like prescribed by official scripts, i.e. bootloader discrepancies could send the device straight to EDL/BROM.
Or maybe, super (system, system_ext, product, vendor and odm) are supposed to be common for both partitions (hence resized and flashed only for one slot) - but then again, why _b is not bootable
Sorry if the (design) reasons for the not-bootable slot _b were somewhere already asked and answered - I searched but I mostly ffound statements that _b is not bootable and how to switch to _a...
Probably it comes from Xiaomi Beta releases (having the same not bootable slot _b), but if anybody knows more about all that - thanks
Also, I didn't test how it works for stock ROMs, MIUI 13 (A12), maybe similarly
Slot b is not bootable because it's blank, unused. It's intended for seamless OTA updates, which we don't support and have no intention of supporting, given how complicated it is to implement when not building from original sources, and how unfeasible it would be to maintain, as well as much more bandwidth waste.
Replace the word "in parallel" with "sequentially", because flashing in parallel is not possible. Otherwise, you perfectly described the flashing process.
None of us knows how exactly the bootloader works, it's closed-source and proprietary to Qualcomm or MediaTek.
Because our fastboot/recovery flash scripts attempt to replicate official fastboot flash scripts as much as possible. "Why bother" you ask? I don't know, and I don't care to find out what happens if we don't do it like prescribed by official scripts, i.e. bootloader discrepancies could send the device straight to EDL/BROM.
Slot b is not bootable because it's blank, unused. It's intended for seamless OTA updates, which we don't support and have no intention of supporting, given how complicated it is to implement when not building from original sources, and how unfeasible it would be to maintain, as well as much more bandwidth waste.
Btw, slot _b is not fully empty, those not resizable partitions are properly flashed, Eg, I successfully disk-dumped boot_b and it was (as supposed) your boot.img
Ie, I tested then:
fastboot boot <disk-dumped boot_b img>
and it perfectly booted to the 22.10.12 System
Just let me 'flash.out' few more findings
The five 'super' or 'resizable' partitions (system, system_ext, product, vendor and odm) are not preset in
/dev/block/bootdevice/by-name - screenshot attached
Strange, it usually lists all active file-systems
Additionally, in /vendor/etc/fstab.emmc, those five plus metadata are defined (and only them) with
first_stage_mount:
Btw, slot _b is not fully empty, those not resizable partitions are properly flashed, Eg, I successfully disk-dumped boot_b and it was (as supposed) your boot.img
Ie, I tested then:
fastboot boot <disk-dumped boot_b img>
and it perfectly booted to the 22.10.12 System
Just let me 'flash.out' few more findings
The five 'super' or 'resizable' partitions (system, system_ext, product, vendor and odm) are not preset in
/dev/block/bootdevice/by-name - screenshot attached
Strange, it usually lists all active file-systems
Additionally, in /vendor/etc/fstab.emmc, those five plus metadata are defined (and only them) with
first_stage_mount:
My answer was to why it's unbootable. I'm not saying that ALL of the partitions on slot b are empty, but some of those necessary for booting are.
As to why it's not bootable to recovery at least, that I do not know and don't really care.
Because Xiaomi has not updated the Global Calendar app yet, despite advertising the new widgets a long time ago, and despite the widgets being defined in the Global App vault's backend.
Also, the image you're showing shows China ROM, while we are using the Global Calendar app which has proper integration with international services, like Google Calendar.
Ok, I gave it a try, Werksreset and fresh installing all apps step by step. Not yet all reinstalled and battery drainer not yet identified, but so far battery overnight is now obviously superb and 1A
mi12
any in here ho knows how to get double touch to kill screen ro work on mi12 i have set it in settings but only work on lockscreen but not in homescreen
it is in allways on an lockscreen
double touch to actived or deactived homescreen
but only works to actived screen an deactived on lockscreen
but cant lock it from homescreen