Adaptive brightness bug (?) and solution - Redmi K20 / Xiaomi Mi 9T Themes, Apps, and Mods

Hi, I bought this phone six months ago and until today I struggled with the adaptive brightness. Even in dark rooms I had very high brightness if I set to adaptive brightness. Today I found out how to solve. I had to edit a file located in /persist/sensors/registry/registry. If you have root access you have to edit the file tcs3701_platform.als.fac_cal so that it looks like that:
{"tcs3701_platform.als.fac_cal":{"owner":"sns_tcs3701","scale":{"type":"flt","ver":"1","data":"0.905537"},"bias":{"type":"flt","ver":"0","data":"0.000000"}}}
If you aren't able to acces that file you can go to TWRP, copy it to internal storage, modify it with a text editor, go back to recovery and restore the file.
Before touching anything a persist partition backup is highly recommended.

Hello,i have the same problem. I Will test.

Related

[Q] How to manually set text size in froyo browser

See here for my solution on how to do this: http://forum.xda-developers.com/showthread.php?t=1136116
1. In eclair there were two size settings in the stock browser
- text size
- zoom
2. In froyo we lost the text size option in browser settings *but, if you upgraded with an official update.zip, whatever you had set for the text size was retained in froyo.
3. If you wipe and restore nandroid of /data to the a froyo rom, it restores your text size setting (even though it isn't available in the settings).
This leads me to believe the setting can still be changed/set in froyo. Has anyone dug into this at all, or is there other interest in it? I'm not sure where to begin to look for something like this but am willing to try.
Sent from my SPH-D700 using XDA App
I've done some digging on my current rom and think there is a good possibility the setting has to do with the following file:
/data/data/com.android.browser/shared_prefs/WebViewSettings.xml
I'm trying to open this file from a nandroid backup I did a while ago which had the text size still toggled (because it was from a di18 stock update to froyo) but am having difficulty opening the file.
Can anyone shed some light on how to open a *.img file which was backed up by nandroid? E.g. I'm trying to get into data.img but 7-zip won't open/extract it, and I also tried mounting it as a disc image with MagicISO and it won't mount it.
Edit: Looks like I need to use the unyaffs utility, messing around with getting that to work now...
Edit2: I was able to get the files extracted of my old nandroid backup, pulled up the XML file I mentioned above and sure enough I found the following line:
"<string name="text_size">LARGER</string>"
This "text_size" was not listed in the XML file on my current system which was wiped and odin'd straight to Froyo. I suspect by inserting that line into my existing install will allow me to have the much desired (by me at least) larger text size in the browser and allow me to keep the zoom level at its default (medium).
The reason this matters to me, is when you increase the default zoom level all the images also zoom in which causes distortion in quality whereas the text size only increases the text size. This keeps images looking normal (100% zoom) while making text more readable at a distance. Will update again once I've tried updating my WebViewSettings.xml file and testing that the text does in fact increase.
Edit 3: I was successful in changing the Browser text size in Froyo by modding the XML file. I'm going to start a thread in DEV to share my findings and will post some screenshots there. My hope is that Chef's may want to include this hack in their ROM and possibly even write a script to allow end user toggling more easily. To me, being able to have a larger default text size at all zoom levels but keep images at their default zoom is a big improvement. Will post a link to the dev post once I get everything setup.

[Q] android media process high cpu

com.android.process.media (Android Media Process is (ab)using CPU)
so, I've tried:
Settings -> Apps -> ALL -> Media Storage -> “Force stop” & “Clear data”
That didn't really help at all(((
community's users suggests following:
* its due to corrupted music/pictures (I don't have any music/pictures on my phone).
* suggestion to reformat sdcard, but toro doesn't have SD card, although through recovery I was able to check filesystem of /userdata mount point (see below):
~ # e2fsck -n /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata
e2fsck 1.41.11 (14-Mar-2010)
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata: clean, 53630/1875968 files, 1921615/7493115 blocks
~ #
Click to expand...
Click to collapse
aside the fact that phone works extremely slow upon boot (due to com.android.process.media) all that high CPU eating a lot of battery (battery life isn't that great to begin with) but thanks to this bug I get to use even less.
after deleting nanodroid's backup (ROM manager), I'm seeing following (through logcat):
D/MediaProvider( 6784): object removed 71054
D/MediaProvider( 6784): object removed 71055
D/MediaProvider( 6784): object removed 71056
D/MediaProvider( 6784): object removed 71057
D/MediaProvider( 6784): object removed 71058
Click to expand...
Click to collapse
i read that if you have folders with a lot of media/picture files, it will sometimes hang while scanning. start fresh, factory reset/reflash google factory images.
bk201doesntexist said:
i read that if you have folders with a lot of media/picture files, it will sometimes hang while scanning. start fresh, factory reset/reflash google factory images.
Click to expand...
Click to collapse
i dont want to loose my /data so doing factory reset won't work for me
I had an issue with this at the beginning of the week.
I had read that it was corrupted media files, so I began investigating. I was able to fix the problem by browsing through my pictures and deleting some images that had somehow become corrupted. The corrupted files were just washed out black squares. No SD format / factory reset was needed.
t3h_g3n3r4l said:
I had an issue with this at the beginning of the week.
I had read that it was corrupted media files, so I began investigating. I was able to fix the problem by browsing through my pictures and deleting some images that had somehow become corrupted. The corrupted files were just washed out black squares. No SD format / factory reset was needed.
Click to expand...
Click to collapse
i thought that would be a problem) i found one and i delete, restarted my phone and still android media process is at least 20% cpu(
I had about half a dozen across several folders that were corrupt. I was looking at the android media process consuming my battery in about 3 or 4 hours until I deleted the bad images. I can now make it through most of a day without any problems.
Somewhere in your phone, a corrupted file lurks. It may not be where you're thinking, but it's there. And it's hungry.
t3h_g3n3r4l said:
I had about half a dozen across several folders that were corrupt. I was looking at the android media process consuming my battery in about 3 or 4 hours until I deleted the bad images. I can now make it through most of a day without any problems.
Somewhere in your phone, a corrupted file lurks. It may not be where you're thinking, but it's there. And it's hungry.
Click to expand...
Click to collapse
i went through all of my gallery and deleted those, yet after restart still doing something and by the time it's done something whatever it was doing i have 90%-70% left!!! AAAAA
is there a way to find those files some other way? can i see some debug information of gallery/android media process and see where hiccup is?
it really kills my battery( anyone has any ideas?
So yesterday I've had it and copy ask of my pictures from my phone to computer and delete them from my phone...
Reboot... and guess what?
It's still using 40/50% of cpu for about first 15 min after I reboot my phone which kills my battery big time(
I need help, anyone??
Sent from my Galaxy Nexus using Tapatalk 2
is there a way to turn on some detailed debug to figure out what's causing this exactly?!
a1exus said:
com.android.process.media (Android Media Process is (ab)using CPU)
so, I've tried:
Settings -> Apps -> ALL -> Media Storage -> “Force stop” & “Clear data”
That didn't really help(( Any other ideas? I keep reading that users saying its due to corrupted music (I don't have any music on my phone).
People are also suggesting to reformat sdcard, but we don't have SD card. Please advise, as one thing it uses CPU the other thing it uses battery and battery life isn't that great to begin with. Is there a way to do fsck or something to make sure there is no corruption of any kind?
*** UPDATE ***
I went into recovery and using adb shell got into a system can I do something like this?
Click to expand...
Click to collapse
I am having the same issue. I found this article but it says the same as the others here.
http://www.transformerforums.com/fo...help/24279-solved-media-using-94-battery.html
If I find anything else out or if you figure something out, let me know also.
a1exus said:
i dont want to loose my /data so doing factory reset won't work for me
Click to expand...
Click to collapse
Your pics and stuff are not in the /data folder. You won't really lose anything important. That is the directory a factory reset/data does. It just basically gets rid of the apps that you had installed. If you are already rooted just get titanium backup to restore. I assure you, I had the same problem up until yesterday. The factory reset was the only thing that fixed it.
The /data wipe is not going to get rid of your pics taken with the phone.
If you do a backup first you have nothing to lose by trying.
On a side note, your Galaxy Nexus does have an "sd card" it's just an internal partition.
Hope you get this resolved.
rushter said:
Your pics and stuff are not in the /data folder. You won't really lose anything important. That is the directory a factory reset/data does. It just basically gets rid of the apps that you had installed. If you are already rooted just get titanium backup to restore. I assure you, I had the same problem up until yesterday. The factory reset was the only thing that fixed it.
The /data wipe is not going to get rid of your pics taken with the phone.
If you do a backup first you have nothing to lose by trying.
On a side note, your Galaxy Nexus does have an "sd card" it's just an internal partition.
Hope you get this resolved.
Click to expand...
Click to collapse
I deleted manually all of my pictures/music yet I still having this issue((
I do have Titanium Backup and I backup my phone regularly, I may try do that...
Do the wipe, trust me. A few installs of programs is not an issue. Your personal data is not lost. Just reinstall your shops that you need and if the days is missing restore with titanium backup.
You will keep having these issues until you do.
Sent from my Nexus 7 using Tapatalk 2
Im having the exact same problem.. Media is 50% CPU, and my S3 gets hot until I stop the Media process after each reboot.
I would like to find a fix before going threw a wipe.
rushter said:
Do the wipe, trust me. A few installs of programs is not an issue. Your personal data is not lost. Just reinstall your shops that you need and if the days is missing restore with titanium backup.
You will keep having these issues until you do.
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
I was having the same problem and the phone was burning a hole in my pocket.
I found that the problem only seemed to occur on a reboot with android.process.media consuming 96% of the CPU for approximately 40minutes.
I attempted to add a .nomedia file to every single directory on the root of my internal SDCARD. - This made no difference.
I discovered that if I killed the process via the terminal it was eventually restarted by zygote and the same issue occured.
I found the only way to stop this from occuring was to Freeze the "Media Storage" app using Titanium Backup. But (not surprisingly) other things did not work - eg being able to capture a screenshot.
I also discovered that if I went into Titanium Backup and issued a "Clear Cached Data" for the Media Storage app, this resulted in the process ceasing it's CPU consumption - useful - but hardly a silver bullet and an annoying step to take after every reboot. (Additionally I do not know if the scan process might of kicked off automatically at some later stage anyway).
Interestingly I discovered that the phone did not overheat when it was plugged into a power supply - completely unrelated but none the less I found this interesting cause I always thought it was the CPU causing the overheating - when in actual fact it was the battery being emptied - unrelated to the issue at hand but none the less a nice tangent
Now this is what I discovered:
I have an application called NZ Topo Maps, it creates a absolutely massive directory structure to download all the tiles of NZ and cache them locally. Each directory can have many sub directories which in turns has many more and can have many many files in each.
So I deleted the entire tilecache. The result - after a reboot android.process.media consumed 5seconds of CPU.
Not convinced I browsed some maps and "cached" ~64MB of tiles - rebooted - 2:33mins of CPU time consumed... hmmmm.
So I cached ~128mb of tiles - 7:44mins of CPU time consumed after a reboot - diffidently onto something here....
Of interest - every single directory which the NZ Topo Maps program creates has a ".nomedia" included and all of the files are labelled with a *.jpg_ suffix.
So I decided to do some more research - Under the structure I had 425 sub-directories and 10615 files that ended with the suffix .jpg_
Out of curiosity I deleted all the files (including the .nomedia) and left the directory structure completely intact.
After a reboot the media process consumed 32sec of CPU time.
For the final test I deleted the directory structure:
CPU consumed: SIX seconds!!!!
Solved: Why android.process.media is consuming so much battery.... for me atleast.
So in conclusion it seems that:
1) The .nomedia directive applies only to the current directory - android.process.media will still recurse into sub directories
2) The .nomedia does not make any difference to the time it takes media to process the contents of a directory - eg - it was still doing "something" with the files in the directory.
3) The naming of files .jpg_ does not make any difference either, the process will still look at them - not sure if it is supposed to or not.
Where to from here - I would really like to find the source for this process and have a look at it's logic, but right now I just don't understand the android internals enough to be able to determine where the source is located in the source tree! I have posted another thread about this - http://forum.xda-developers.com/showthread.php?p=34326153#post34326153 hopefully someone will give me an answer because this situation is less than ideal.
Hopefully this helps someone else and sends them in the right direction?
Rowan
All,
I found this link. I would post a click-able link but I am not allowed as I am a new forum member - so I am afraid you'll have to type it in the old fashioned way from the image below.
Please head over and "STAR" the bug and/or add your own comments / experience, the more visibility it gets the more likely it is to be fixed.
Cheers.
-Rowan
I have a new HTC One X+ running JB 4.1.1 Sense+. I noticed this happens off and on that the phone gets hot and battery plummets. Using Android Task Manager, realtime process viewer and showing system processes setting turned on, I discovered also it is android.process.media consuming the CPU.
I have over 2,800 mp3 files, most are highquality high bitrate, 16GB worth. They are all put into a directory structure based on artist and album name. I'm sure this is what the process is choking on.
The question is, is it some sort of indexing that just takes days or is it going to happen every time I reboot the phone? The USB charge can't even keep up with the batter drain when it is doing this.
every reboot, so don't reboot your phone)
jazee said:
The question is, is it some sort of indexing that just takes days or is it going to happen every time I reboot the phone? The USB charge can't even keep up with the batter drain when it is doing this.
Click to expand...
Click to collapse
It happens every reboot. The following workarounds are available:
a) not reboot
b) reboot only when you are connected to power
c) use TitaniumBackup to Freeze "Media Storage" (requires root)
d) Settings -> Apps -> ALL -> Media Storage -> “Clear data”. NB: A Force Stop will result in the process being restarted by Zygote at a later time.
e) delete the large directory structure and directories with 1000's of files.
(c) works indefinitely but things stop working - eg - screenshot fails
(d) seems to work until the next reboot but all of your media is gone from the native library - but this may not effect third-party players/apps
If you're using too much power when charging via USB, you might want to get a plug in wall adapter which can supply more current.
It's a really bad situation and seems to be effecting every build of JellyBean - it's a defect in the core software.
Things which do not work:
.nomedia - placing .nomedia files in all directories, some of the directories or the root directories has no noticeable effect.
renaming files - renaming media to an unknown extension (e.g., picture.jpg -> picture.abc) has no effect
-Rowan
I personally went through:
deleting broken images inside of my gallery
deleting my music
deleting my pictures
checking filesystem on my /sdcard partition
deleting some large directories that contains a lot of files
placing .nomedia inside of some directories
bloging about this: Android Media Process (high CPU) | alexus' blog
about to commit suiside #$%#&@!)
and almost every time when i (re)boot my phone and i'm not plugged in, i'll lose about 10% of battery in first 10min of my phone is doing something...
Google! fix it already!))

[Q] Paranoid Android preference storage problem

Hello guys,
I've just flashed the Paranoid Android ROM by WOH (http://forum.xda-developers.com/showthread.php?t=1912187&page=111) and I really like it.
However, I'm having some kind of issue with the PA engine settings.
The problem goes like this:
1. When I set the global UI settings, I'm asked to reboot, but the settings are back to defaults after the reboot.
2. When I edit the preferences for a particular app, I'm only able to make it work by setting and applying the needed values followed by using the launch button, which finally makes the changes effective. These changes are, however, also reset after rebooting the phone.
I did some searching and found this hint (http://www.paranoid-rom.com/forum/guides-references/256-hint-pa-prefs-does-not-save-changes) which seems to deal with this problem, but haven't had any luck with it. In the terminal, when trying to run the commands, I get an error saying my file system is mounted read only. So I tried modifying the file perimissions in the ES file manager (which also didn't work on some occasions, but sometimes it did), then running the terminal commands successfully, but without any effect on the PA preferences bahaviour after rebooting.
I ended up editing those files manually and removing the backup file (which, I thought, was overwriting the preferences file, reverting the settings to defaults). The ES file manager also behaved very oddly when trying to manipulate those files, once I was not allowed to delete those files, than they disappeared on their own, same goes for renaming.
Finally, I think, the problem is being caused by the properties file being overwritten with the defaults on every boot. So far I've been unable to determine the cause of this behaviour, so I hope perhaps some of you have come across this problem and know the solution. Thanks in advance for that.

[LS990 ZV4] LG File Manager gives error, screenshots won't save, Gallery empty?

Repost from Sprint forum area, since this main area is much more active...
I have some weirdness going on with my LS990, still running the original ZV4 with Xposed and TWRP. I've never had any problems, until now, with anything on this phone, it's been fantastic and that's why I leave it on Kit Kat.
Starting yesterday, whenever I try to open the stock File Manager, I get the following error dialog:
------------
Note
Cannot read files. File Manager will be closed. Please check Media Storage enable settings and try again.
OK <--button
------------
Sometimes the dialog is in the foreground and I can close it with OK, but File Manager never opens. Sometimes the dialog appears behind my launcher icons and everything is unresponsive until I kill the running process using my nav bar shortcut from G3 Tweaksbox.
Also, I was trying to take a screenshot to include with this post, but it gives an error (Cannot take screenshot. Try again.) when trying to save it, plus the notification just stays on "Saving Screenshot" and is unable to be swiped away. [UPDATE: Noticed the screenshots do get saved in the proper Pictures/Screenshots folder, but the notification remains "stuck"]
I have also noticed my gallery is now empty, yet I can still access all of my pics from third-party file managers. Plus, when I open the camera and take a picture, it doesn't show in the little Gallery bubble at the bottom of the screen - in fact, the bubble doesn't even work, but yet the picture is saved properly.
Has anyone seen behavior like this before? The only thing I have changed on the phone is flashing the new TWRP 3.0.0.0 yesterday, using the image feature in my previously installed TWRP 2.8.7.0. I've updated TWRP plenty of times and there has never been an issue, but one difference I did notice this time was it asked if I wanted to keep System read-only or the default swipe to make read-write, which is what I did since I have Xposed and it modifies the System anyways.
Hopefully someone out there has an idea how to fix this, I really don't want to start all over, at least not until Sprint releases MM for the G3. The strange thing is, everything else is working just fine. My phone is fully functional except for the quirks mentioned above, root is still there and Xposed is functioning properly. I did do a Safe Mode boot to see if I could eliminate any root apps, but the issues were still there even after a safe boot.
Try sd card write fix on the market just for kicks u mighta lost permissions to the ext sd try switching save point to internal and see if they save
Unfortunately, I'm not using a microSD card, everything is saved to the internal memory. I thought it might be something with permissions, was thinking about trying the "fix permissions" option in TWRP but I'm not sure if that would make things worse. I've already tried a cache and Dalvik wipe, but that didn't fix anything. Even in Safe Mode, nothing changes.
I've searched online and haven't seen anyone else with this issue, it's very strange. I wish Sprint would hurry up and drop the MM update so I would have the perfect excuse to flash back to stock.

[Q] SDCard write issue with 3rd party apps (0 byte files)

Issue:
When using Open Camera, ES File Explorer or Amaze file explorer files are created with zero bytes. i.e. Copying a file will create a 0 byte file or if file storage location set to the SDCard, the Open Camera app will fail to record video or take pictures.
Initially write operations on the SDCard did seem to work for a while (recorded one video before fail using Open Camera and copied files across without errors).
All operations are fine on internal memory.
There is no issue using the built-in file manager and camera apps. Will update as I check though other apps affected by this.
Setup:
The phone was on MIUI 9, then updated to the MIUI 10 OTA update (from beginning of Oct2018):
GLOBAL Version 10.0.1.0 (OEDMIFH)
Android 8.1.0 OPMI.171019.019
Kernel 4.4.78-pref-ge3e6edb
I then performed a factory reset from the boot recovery before installing everything from my previous phone. I didn't try MIUI 9 with an SDCard.
System Apps and Apps up to date.
I then started with the SDCard (128GB Class 10) cleanly formatted on PC, FAT32, and then when inserted into the phone formatted again. Looked for option to mount as Internal Storage, but noted that this isn’t available on this device (probably for the best), and no obvious option for encryption???
Troubleshooting:
Initially I thought, OK failed SDCard (this was before I found built-in apps worked OK). So I removed the card formatted it and checked using a test program to write/verify the whole card and it checked out OK. Still same issues back in the phone.
Next I pulled SDCard from another phone and tried that, and I get the very same issues. Thinking less likely it is a failed SDCard now, perhaps it is a hardware issue with the phone. Although it did write some files before.
After reading a few places, mention of an issue on MIUI 9 but this was fixed in later update. The steps don't match with anything in MIUI 10.
There is also mention of a bug with Android Orio which is similar, where apps need Storage permissions. Checked and I'd given the apps this permission and I had.
Following this, I tried the standard apps (Camera and File Manager) and discovered that these wrote files without errors (using the very same files which fail before/after on the other apps). Right so looking less like a hardware issue (hopefully!).
For ES Explorer, first time you write to the SDCard you have to select the SDCard root (“Please choose the root directory (XXXX-XXXX) of ext-SDCard…”). In this step, the SDCARD is referred to as BOOT and ES Explorer mounts it with the ID of SDCARD. The internal memory is mounted as /storage/emulated/0 and the SDCard as /storage/XXXX-XXXX/.
Additional testing with the apps, has shown that the data is actually written by ES Explorer since the 0 byte file shown in ES Explorer after a copy, is the correct size and opens from the standard file manager. This is further confirmed when performing a reboot or remount of the SDCard, ES Explorer then reads the file as it should… Any file copied/moved by the standard file manager is shown and works correctly, even from ES Explorer.
I get just the same behaviour with alternative file explorers such as Amaze. Also I think many of the other apps suffer from the same issue since they can't open the 0byte photo or video until there is a remount/reboot.
With regards to Open Camera, this has the option to Use Storage Access Framework, which I think I had to enable for it to select the SDCard for storage (otherwise I think it returned a “serious error” when a few seconds into recording). I suspect something similar is happening on this app, but perhaps not consistently. As mentioned before, the first time I noticed a problem was after it had recorded a video (which was fine) and the next one I recorded was 0 bytes. The fact that it recorded without complaining, in retrospect, suggests to me that it was only reporting 0 bytes for the file (and if I’d remounted the card I would have the video OK) – since it’d have to been writing the data somewhere.
So it may be that the issue isn't writing to the SDCard, but correctly reading the data afterwards without remounting the SDCard (or reboot).
I've noticed there is a new version of MIUI 10 released yesterday, so may pick that up to see if it magically solves things (nothing mentioned on change log).
Questions:
Anyone else experienced anything similar? Ans: Apparently yes, it is a "feature", aren't we lucky.
Am I missing some special setting? Ans: No.
Any thoughts on what the issue could be or if there is a fix? Ans: It can be fixed using root magisk.
Are your mount points similar/different? Ans: Guessing not and isn't related to the problem.
Did you do a factory reset after update (one possibility is that whatever made it work in MIUI 9 remained for most people if they didn't factory reset)? Ans: Not the cause of the problem.
Thanks
meltwater.
i thought i was the only one with zero bytes files. and when you transfer them back- all good
The only way I could find an alternative solution was to install "ExSDCard Access Enabler" module in magisk.
Then point the direction to /mnt/media-rw/XXXX-XXXX/* and you can carry on as usual.
But this only works for apps that allow you to enter or select a path where you can enter the directory path by typing or open a gui to browse to this directory.
Or a file manager such as Root explorer, just go back back back to / directory and go to /mnt and you'll find the folder from there.
Apps such as OpenCamera when selecting the save path you can manually either enter this path or choose to use the Android framework to go to this folder.
But if the app only has an option to "save to external sd card" it assumes the sdcard is mounted to /storage/XXXX-XXXX/* with write permissions.
A bit of a shame..but I don't use any apps that asks for this permission so I can live with it.
I like to mention that this behavior is the same on Treble roms too, Pie or Oreo.
dvijetrecine said:
i thought i was the only one with zero bytes files. and when you transfer them back- all good
Click to expand...
Click to collapse
Awesome, helps to know it isn't something terminal. Will update if I manage to get to the bottom of it.
SUPERUSER said:
The only way I could find an alternative solution was to install "ExSDCard Access Enabler" module in magisk.
Then point the direction to /mnt/media-rw/XXXX-XXXX/* and you can carry on as usual.
But this only works for apps that allow you to enter or select a path where you can enter the directory path by typing or open a gui to browse to this directory.
Or a file manager such as Root explorer, just go back back back to / directory and go to /mnt and you'll find the folder from there.
Apps such as OpenCamera when selecting the save path you can manually either enter this path or choose to use the Android framework to go to this folder.
But if the app only has an option to "save to external sd card" it assumes the sdcard is mounted to /storage/XXXX-XXXX/* with write permissions.
A bit of a shame..but I don't use any apps that asks for this permission so I can live with it.
I like to mention that this behavior is the same on Treble roms too, Pie or Oreo.
Click to expand...
Click to collapse
Interesting, not come across it before, very odd behavior. Very glad I don't have to throw the card or return the phone.
I've seen magisk mentioned elsewhere, shall look into it. Does that require root? How easy is the Mi Max 3 to root? That sounds like that should be enough to make it work.
Also thanks for pointing out it is on other roms too, saves chasing down a fix through that. I assume then it does it on MIUI 9 too.
Thanks!
meltwater said:
Awesome, helps to know it isn't something terminal. Will update if I manage to get to the bottom of it.
Interesting, not come across it before, very odd behavior. Very glad I don't have to throw the card or return the phone.
I've seen magisk mentioned elsewhere, shall look into it. Does that require root? How easy is the Mi Max 3 to root? That sounds like that should be enough to make it work.
Also thanks for pointing out it is on other roms too, saves chasing down a fix through that. I assume then it does it on MIUI 9 too.
Thanks!
Click to expand...
Click to collapse
Magisk is the new "supersu" standard when it comes to root.
So it is the root per say. Yes you need root. But you root your phone by installing Magisk, its kind of a multi-tool.
You need to unlock your bootloader, if not already unlocked if you bought it that way like I did from Tradingshenzhen.
It will say Unlocked on the bootloader mi splash screen when you turn the phone on if the bootloader is unlocked.
And then you need to properly flash TWRP. Other than that you can stay on stock rom and use Magisk
Magisk thread https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
ExSDCard Write Access Enabler module thread https://forum.xda-developers.com/apps/magisk/module-exsdcard-write-access-enabler-t3670428
I see something I did not see before.
In the thread OP mentions:
Since the v3.3 ZIP version, a feature has been added especially for Oreo (Android 8) users, on this Android version, several special permissions can be used by any app.
For exemple, theses specials permissions are used to get access to reading logs, managing the power of the device.
If you want to use this special feature, you just have to follow theses easy steps:
- creating a simple file named "ExSDCard_Oreo_apps" in the module path, so: /sbin/.core/img/ExSDCard/ExSDCard_Oreo_apps (remove any extension).
- Write all the apps package names that require a special permissions, one by line, for exemple:
Click to expand...
Click to collapse
So with this you can apparently create custom rules for apps that don't support selecting the external SD card path.
Maybe you should look in to that and experiment
This bug happened across android 8.0 in various brand.
Since I familiars with ES File Explorer, I solved by root the phone, convert ES File Explorer into System app via Titanium Backup, then everything work perfectly fine. No more 0 bytes copy file.
ES File Explorer still work even I un-root my phone by uninstall Magisk.
If you're really not want to root your phone or any other reason. Just copy file that you want then restart your phone. Copied file will now become usable file.
My bootloader isn't unlocked and for now I'd rather avoid rooting my phone (may well do so later).
Good to know there are work-arounds, and that my device hardware is ok.
Will have an experiment and see if I can live with it until I have a go at rooting. Even if I do the temp fix of ES explorer.
Thanks for the info and tips.
Same **** for me. 1 year to solve this stupid bug and they dont have fix this **** yet
Say thanks to xiaomi[emoji108][emoji867]
Enviado desde mi MI MAX 3 mediante Tapatalk
Hmm i'm getting an SD card tomm for my Mix Max 3, i use the Asus File Manager. I wonder if that problem happnes with other file manager apps. Tried the Samsung Evo and another one and that 0byte bug there. No bueno.
Wmateria said:
Hmm i'm getting an SD card tomm for my Mix Max 3, i use the Asus File Manager. I wonder if that problem happnes with other file manager apps. Tried the Samsung Evo and another one and that 0byte bug there. No bueno.
Click to expand...
Click to collapse
Yep, looks like it is a solid bug. For now, I'm living with it and use the space I have on internal memory to transfer data to before using a System file manager to transfer to SDcard.
Been trying some app development and now found the "Install via USB" bug.
Again can work around it, but it does spoil debugging with Android Studio.
There are certainly some odd bugs on this phone, I suspect down to Xiaomi going "off plan".
meltwater said:
Issue:
When using Open Camera, ES File Explorer or Amaze file explorer files are created with zero bytes. i.e. Copying a file will create a 0 byte file or if file storage location set to the SDCard, the Open Camera app will fail to record video or take pictures.
Initially write operations on the SDCard did seem to work for a while (recorded one video before fail using Open Camera and copied files across without errors).
All operations are fine on internal memory.
There is no issue using the built-in file manager and camera apps. Will update as I check though other apps affected by this.
Setup:
The phone was on MIUI 9, then updated to the MIUI 10 OTA update (from beginning of Oct2018):
GLOBAL Version 10.0.1.0 (OEDMIFH)
Android 8.1.0 OPMI.171019.019
Kernel 4.4.78-pref-ge3e6edb
I then performed a factory reset from the boot recovery before installing everything from my previous phone. I didn't try MIUI 9 with an SDCard.
System Apps and Apps up to date.
I then started with the SDCard (128GB Class 10) cleanly formatted on PC, FAT32, and then when inserted into the phone formatted again. Looked for option to mount as Internal Storage, but noted that this isn’t available on this device (probably for the best), and no obvious option for encryption???
Troubleshooting:
Initially I thought, OK failed SDCard (this was before I found built-in apps worked OK). So I removed the card formatted it and checked using a test program to write/verify the whole card and it checked out OK. Still same issues back in the phone.
Next I pulled SDCard from another phone and tried that, and I get the very same issues. Thinking less likely it is a failed SDCard now, perhaps it is a hardware issue with the phone. Although it did write some files before.
After reading a few places, mention of an issue on MIUI 9 but this was fixed in later update. The steps don't match with anything in MIUI 10.
There is also mention of a bug with Android Orio which is similar, where apps need Storage permissions. Checked and I'd given the apps this permission and I had.
Following this, I tried the standard apps (Camera and File Manager) and discovered that these wrote files without errors (using the very same files which fail before/after on the other apps). Right so looking less like a hardware issue (hopefully!).
For ES Explorer, first time you write to the SDCard you have to select the SDCard root (“Please choose the root directory (XXXX-XXXX) of ext-SDCard…”). In this step, the SDCARD is referred to as BOOT and ES Explorer mounts it with the ID of SDCARD. The internal memory is mounted as /storage/emulated/0 and the SDCard as /storage/XXXX-XXXX/.
Additional testing with the apps, has shown that the data is actually written by ES Explorer since the 0 byte file shown in ES Explorer after a copy, is the correct size and opens from the standard file manager. This is further confirmed when performing a reboot or remount of the SDCard, ES Explorer then reads the file as it should… Any file copied/moved by the standard file manager is shown and works correctly, even from ES Explorer.
I get just the same behaviour with alternative file explorers such as Amaze. Also I think many of the other apps suffer from the same issue since they can't open the 0byte photo or video until there is a remount/reboot.
With regards to Open Camera, this has the option to Use Storage Access Framework, which I think I had to enable for it to select the SDCard for storage (otherwise I think it returned a “serious error” when a few seconds into recording). I suspect something similar is happening on this app, but perhaps not consistently. As mentioned before, the first time I noticed a problem was after it had recorded a video (which was fine) and the next one I recorded was 0 bytes. The fact that it recorded without complaining, in retrospect, suggests to me that it was only reporting 0 bytes for the file (and if I’d remounted the card I would have the video OK) – since it’d have to been writing the data somewhere.
So it may be that the issue isn't writing to the SDCard, but correctly reading the data afterwards without remounting the SDCard (or reboot).
I've noticed there is a new version of MIUI 10 released yesterday, so may pick that up to see if it magically solves things (nothing mentioned on change log).
Questions:
Anyone else experienced anything similar?
Am I missing some special setting?
Any thoughts on what the issue could be or if there is a fix?
Are your mount points simlar/different?
Did you do a factory reset after update (one possibility is that whatever made it work in MIUI 9 remained for most people if they didn't factory reset)?
Thanks
meltwater.
Click to expand...
Click to collapse
no need for this post. erased.
I want know why xiaomi dont fix this ****?
Think that mi max 3 will die with this bug. Never buy a xiaomi phone more
jorgeepelos said:
I want know why xiaomi dont fix this ****?
Think that mi max 3 will die with this bug. Never buy a xiaomi phone more
Click to expand...
Click to collapse
Get a Mi Mix 2S
Wmateria said:
Get a Mi Mix 2S
Click to expand...
Click to collapse
Phone with 3 month since release and they dont solve bugs and i have to buy more expensive phones?
All xiaomi phones its ****, policies, comunity,software and bugs that the dont solve
And People like you its the problem=sh it comunity guys that likes get fuked the ass by xiaomi[emoji108][emoji6]
Enviado desde mi MI MAX 3 mediante Tapatalk
jorgeepelos said:
Phone with 3 month since release and they dont solve bugs and i have to buy more expensive phones?
All xiaomi phones its ****, policies, comunity,software and bugs that the dont solve
And People like you its the problem=sh it comunity guys that likes get fuked the ass by xiaomi[emoji108][emoji6]
Enviado desde mi MI MAX 3 mediante Tapatalk[/QUOTE.
It's people like you who make the community bad when you out your hatred in the forums or is not knowledgeable enough because main post talks about THIRD PARTY FILE MANAGER APPS not 1ST PARTY Xiaomi File Manger APP and thinks it's the end of the world on here and the Xiaomi forums. And trust me there is plenty of you people around pushing Devs and OP here by complaining when other people already stated the fact many times on a thread, and trust me, I hardly take offense. "Read", it works.
Click to expand...
Click to collapse

Categories

Resources