yashsingh1/xdaforums huggingface dataset:
[Xiaomi Mi MIX  Guides, News, & Discussion] cazcryy:
How would they go about placing dual front facing speakers on this device without doing away with the whole "bezel less" look? Would defeat the entire purpose of the phone.
[Xiaomi Mi MIX  Guides, News, & Discussion] satishp:
Having an LCD display doesn't make this device a failure at what its intended to be. LCD vs AMOLED is always personal preference. No technology is superior over the other. They are designed to co-exist. While you and I may prefer AMOLED, there are many who prefer a decent LCD panel for more natural colors and uniformly lit screen.

Moreover, AMOLEDs tend to show burn-in or lose brightness in a relatively short period of time, especially if the display has been used at close to max brightness. This may be a deal breaker for some.

Even I would have preferred an AMOLED display, mainly because all my previous devices were Samsung flagships. But that doesn't make the Mix an inferior device.

And considering the Mix has really good blacks and contrast for an IPS panel, I don't really miss AMOLED that much.

Stereo speakers may be possible in a successor, but it may not be front-firing as it would need bezels on top and bottom. Most probably it will be another speaker grill on the top, beside the 3.5mm jack if they bring one with a stereo speaker.
[Xiaomi Mi MIX  Guides, News, & Discussion] Iron_Overheat:
The "OLED vs LCD is subjective" argument is baseless. OLED defeats LCD in every possible way: the only reason current OLEDs don't reach LCD brightness levels is because they don't actually invest in OLED research. For example, the Quantum Dot implementation on LCDs is completely brain-less, since it could also be applied to OLED, and it would make an absurdly better display (academic research on QD-OLED here https://www.researchgate.net/figure/281318407_fig2_Fig-3-The-structure-of-the-QD-OLED, https://www.ncbi.nlm.nih.gov/pubmed/22408958, http://www.sciencedirect.com/science/article/pii/S0921510707005557). WRGB also helps solving OLED's few problems (which are way less than LCD's), and anti-burn-in techniques are being researched, although they are underfunded. And they're underfunded 'cause OLED would be bad for business (harder to make), but good for the customer. That's why manufacturers don't let LCD die. OLED is just simply a superior technology. This doesn't mean this phone is horrible. It just means it's not up to today's standards for display technology. If the display for the Mi Mix EVO is OLED, then it would be a very nice upgrade.

---------- Post added at 09:17 PM ---------- Previous post was at 09:13 PM ----------

Maybe they should use technology similar to Sony's new TVs shown on CES 2017, the "speaker on glass" technology (where the screen vibrates to create sound). I'm sure that would be a way better alternative then back or side-facing speakers.
[Xiaomi Mi MIX  Guides, News, & Discussion] satishp:
While I wont disagree to any of your points, anything that is still under research in a lab, isn't immediately beneficial to the end consumer. Ofcourse, OLEDs may completely replace LCDs one day but we haven't reached there yet.

The argument is like saying Hydrogen fuel cells, if used in smartphone batteries, have the potential to provide week long battery life and will blow the current Li-Po batteries out of the water. While this is good to know, it would take a few more years to see consumer-grade cellphone batteries based on the technology.

My statement was based on what's available at present to someone who is willing to buy. At present:

1. Only AMOLED screens used on Samsung flagships reach close to 600nits of brightness. Again, this is only under certain conditions and for a limited amount of time. AMOLEDs on almost every other smartphone show lower but still good or acceptable numbers despite being manufactured by Samsung.

2. OLEDs still exhibit a considerable amount of burn-in, especially on devices that have been used at close to max-brightness. It has evolved a lot since the Galaxy S days, but it hasn't reached a point where burn-in has become un-noticeable.

3. Even if the future of LCDs may seem bleak according to your statement, LCDs aren't going anywhere for a long time and LCD technology has been developing almost as fast as OLEDs. Within a short span of time, smartphone LCDs have progressed a lot.

1. Almost every budget phone can have a decent IPS panel now as costs have come down.

2. Some displays (LG) have reached brightness levels of over 1000nits with decent contrast ratios.

3. Contrast ratio and black levels of IPS displays used on high end smartphones have improved drastically and we see improvements every year.

4. Power consumption of LCD panels have come down significantly, close to or on par with AMOLEDs. AMOLEDs consume higher power when displaying whites anyway.

5. Color accuracy on many smartphone IPS panels is now on par with professional or studio quality monitors.

I'm not saying AMOLEDs haven't progressed since the Galaxy S. Just saying that both technologies have their drawbacks and both are equally moving forward. Neither technology has surpassed the other and both technologies will co-exist for many years.

I'd pick an AMOLED display over an LCD because that's what I am used to and that' s what I prefer. But that doesn't mean its because AMOLEDs are "far superior" to LCDs.

When you say that the display on the Mix is not up to "Today's standards", a measured display comparison shows the Mix and the Mate 9 posting considerably better scores compared to other competing flagship phones like the HTC 10 and the LG G5\V20 (Comparing similar technology). I'm talking max brightness, black levels, contrast ratio and color accuracy. Resolution isn't the only benchmark for "today' s standards".
[Xiaomi Mi MIX  Guides, News, & Discussion] Iron_Overheat:
I am fully aware that IPS LED LCD displays have progressed a lot. They're a mature technology that displays very good color, brightness, and contrast ratios. But OLED just trumps all of that:

Contrast ratio: infinite, the pixels are self-lighting and can shut off when black color is displayed.

Thickness: Destroys LCD, the back-lighting and the other layers cause a thicker overall display, plus no back light means no back light bleed (large downside to IPS). Read in a website once that QD-OLED could achieve paper-thin thicknesses, but can't find that site anymore, and don't know if it's true or not.

Response time: 0.1 ms. 0.1 F****** MILLISECONDS. IPS barely does 4ms and TN panels to 1ms tops.

Flexibility: Very good, LCD is barely flexible.

Power consumption: Essentially lower than LCDs. The only reason some LCDs might be on par with AMOLEDs is because of the amount of desperate research they're putting to keep LCD alive. If that research went into OLED, the improvements would be realms apart.

Possible color accuracy and brightness, giving enough research: Vastly superior to LCDs. QD-OLEDs will rock.

The only reason LCD is still alive, being such an essentially inferior technology, is because people still buy them. If we keep buying OLEDs, they will advance much faster and we'll have amazingly better displays. Hell, from 2016 to 2017 LG managed to increase their panel's OLED brightness by 25%. If people actually let LCDs die, we would see bigger increases that would trump LCDs hard. Because of maturity, high-end LCDs might beat OLEDs in some aspects, but the only reason for that is underfunded OLED research, and therefore, less experienced technology. And the reason for that underfunding (besides our capitalist system and CEOs) is because people still buy LCDs. LCDs will only "keep existing for a long time" if we let them. So let's not.

Also I said nothing about resolution. It's important, but it's far less important than display technology, refresh rate, color accuracy, etc.
[Galaxy S II Original Android Development] Lanchon:
(reserved)
[Galaxy S II Original Android Development] Namoi:
Thanks for these insights. I do hope someone with the needed skills will carry on ?
[Galaxy S II Original Android Development] Lanchon:
well, you can carry on! just use a file manager in root mode, create a backup of /data/system/storage.xml, edit the live file, and remove the attribute. that's all there is to it. your sdcard will be /data/media/0 after a reboot. you can copy your current sdcard files there (better do it after the first reboot) using adb shell in TWRP. some (but not all) files can also be copied using a root file manager.
[Galaxy S II Original Android Development] the.gangster:
I dared to try it.

Just to confirm:

Modifying the storage.xml still seems to do the job on Android 7.1.1 (CM14.1).

After extinguishing the mentioned attribute (and nothing else yet! ) in storage.xml:

- an emulated storage was created in /data/media/0

- default folder structure got created in there

- settings->storage shows "internal share storage" as well as the well-known "sdcard0" and "sdcard1"

- file manager (where I had bookmarks for sdcard0 + 1) now shows bookmarks to Internal shared storage + sdcard1

- camera app (set to store pictures on phone) automatically switched to the new folderstructure

- Total Commander still showed sdcard0+1 until deleting its app-data -> now it references SD-card to emulated/0 and USB to sdcard1

- After connecting the phone to a PC and switching USB connection from "charging" to "Transfer files" even the PC only shows "Internal shared storage" and "sdcard1"

So all in all, android seems to really kind of automatically hide the existing non-emulated one in most apps, while still allowing access to it thru /mnt/media_rw/UUID if needed.

That's it for today from my side.

I'll add some screenshots.
[Galaxy S II Original Android Development] Lanchon:
so it seems everything works!!

strange that the system seems to show the size of sdcard0 as used spaced in internal storage...

so will you backup sdcard0 and REPIT? or go back to non-emulated? i'm curious about what would happen with the +wipe+swap options in sdcard=. will the phone boot or not? who knows...
[Galaxy S II Original Android Development] ale5000:
Does someone have any link that explain the "'addon' ROM flashing mechanism"?

PS: Does using emulated SD affect read/write performance?
[Galaxy S II Original Android Development] the.gangster:
Free space: Yes, it looks like the size calculation simply shows the used space out of the whole emmc area (mmcblk0). So all partitions except /data (mmcblk0p10) are "used" space (even if they are free) and only the actual free space in the /data partition (1.5gb of 4.5gb) is shown as "not used".

Repit: Haven't made my mind up, yet. As I only started testing it out of curiosity. I wasn't even a friend of the idea to break up with all the well-known tools and reinventing everything from scratch. But as it turns out now, it might not be the big step that it was expected to be. Meanwhile I would rather consider preserving a small internalsd, not to break with the partition layout.

Whether formatted or not shouldn't make a big difference. There have been so many people here, who used the odin-with-pitfile-method to change their partitions and who where not instructed properly to format the internalSD in the recovery right away, that I can recall the only thing happend was, the s2 booted up and if an App wanted to access that storage it resulted in "sdcard0 is corrupted"-errors.

But maybe I'll also manage to test the rest within the next week.

[MENTION=5627087]ale5000[/MENTION]

just take a look into your /system/addon.d folder and you'll find some scripts that are executed automatically upon ROM upgrades. They should serve as good examples already.
[Galaxy S II Original Android Development] Lanchon:
you should try it. when i migrated to unified storage many many years ago, it was a big hit. there is not big break up and nothing to invent, everything in android should work out of the box. take the plunge! and go for min sdcard. you dont need it! you have external SD if you need one. and in any case, if needed, using REPIT later to shrink data, and enlarge plus wipe sdcard should be almost instantaneous (no moving of any partition).

the only problem is TWRP:

-wipe data will wipe your sdcard too. but why would you wipe data? and you can adb shell to TWRP to manually wipe while keeping /data/media if you needed it.

-backup data will backup sdcard too. you'll need to backup to external storage of course.

-restore data will wipe and restore sdcard too.

i REALLY THINK an emulated official build for this device would be a great thing.
[Galaxy S II Original Android Development] Lanchon:
addon is a channel between gapps (and whatever else) and custom roms. CM supports it. when you flash CM, it wipes system putting a new file system image there (in LP and later). but mysteriously if you had gapps before flashing, gapps remain. how's that?

well, CM runs hooks that might be present in /system/addon.d at several stages. i dont remember the details but at a minimum it's like this:

-run "before" hooks.

-install CM, completely wiping system.

-run "after" hooks.

so stuff you flash after flashing CM (eg: gapps) might add hooks in that folder. gapps in particular backs itself up from /system to somewhere in its "before" hook, then reinstalls itself from the backup in its "after" hook. where does it back itself up? i don't know, probably to /data, as REPIT gets /cache to be very small by default on many devices and i havent heard any complaints so far.

so when you flash stuff that uses addon, not only it flashes whatever it needs, but it also sets up hooks in the addon folder. and that's it.

for the life of me i can't understand why so many software doesn't use addon. examples that come to mind now: xposed and roots such as supersu. maybe rovo doesnt know about this mechanism? impossible, someone must have told him!

anyway, to get rid of existing addons, just format /system before flashing CM et al. pretty intuitive if you ask me.
[Galaxy S II Original Android Development] ale5000:
[MENTION=4141005]Lanchon[/MENTION]: Thanks.

Does it work on both flashing ROM update manually through recovery and normal OTA updates inside Android or not?
[Galaxy S II Original Android Development] Lanchon:
yes but only when apps access storage, not when the system accesses it. this is because access goes though FUSE.

google's FUSE use in android is an abomination. samsung and moto both knew this and fixed their OSes by moving the FUSE functionality to a kernel driver. google is backporting samsung's implementation (sdcardfs) to the standard android kernel, and my guess is that FUSE will be retired on the next android version.

FUSE can have a performance impact going from 15 to over 50%. large numbers correspond to small files or small file operations.

BUT... maybe FUSE is used for the non-emulated sdcard too, to synthesize permissions, so there might be no extra hit if you switch. this is at least very probable. i think FUSE is used for external microSDs these days, so the internal ones would be handled in the same way.

there is a native process in your phone called sdcard (that's the binary's name). if you find it, kill it. it shouldn't respawn i guess. after the kill, apps such as the gallery should loose access to the sdcard until you reboot. if this happens, it proves that FUSE is already being used and you wont get a performance hit from switching to emulated sd.

well... strike all that! i remember from the FPBug days, sdcard WAS in fact used, and when it died, access to the sdcard WAS indeed lost. this was already happening in KK and maybe android 4.3 too. so yes, you are already running FUSE.
[Galaxy S II Original Android Development] Lanchon:
it works on both methods. the flashable zip never knows if it's manual or OTA.
[Galaxy S II Original Android Development] the.gangster:
And I thought, simply looking at the mount command would already tell, wouldn't it?

i9100:/ # mount
rootfs on / type rootfs (ro,seclabel,relatime)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt type tmpfs (rw,seclabel,relatime,mode=755,gid=1000)
none on /dev/memcg type cgroup (rw,relatime,memory)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p9 on /system type ext4 (ro,seclabel,noatime,us
/dev/block/mmcblk0p7 on /cache type ext4 (rw,seclabel,nosuid,node
/dev/block/mmcblk0p1 on /efs type ext4 (rw,seclabel,nosuid,nodev,
/dev/block/mmcblk0p10 on /data type ext4 (rw,seclabel,nosuid,node
/dev/block/mmcblk0p12 on /preload type ext4 (rw,seclabel,nosuid,n
tmpfs on /storage type tmpfs (rw,seclabel,relatime,mode=755,gid=1
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,seclabel,
/dev/fuse on /mnt/runtime/default/emulated type fuse (rw,nosuid,n
/dev/fuse on /storage/emulated type fuse (rw,nosuid,nodev,noexec,
/dev/fuse on /mnt/runtime/read/emulated type fuse (rw,nosuid,node
/dev/fuse on /mnt/runtime/write/emulated type fuse (rw,nosuid,nod
/dev/block/vold/public:179_11 on /mnt/media_rw/8C8D-EB5C type vfa
o)
/dev/block/vold/public:179_13 on /mnt/media_rw/E1C9-1514 type vfa
o)
/dev/fuse on /mnt/runtime/default/E1C9-1514 type fuse (rw,nosuid,
/dev/fuse on /storage/E1C9-1514 type fuse (rw,nosuid,nodev,noexec
/dev/fuse on /mnt/runtime/read/E1C9-1514 type fuse (rw,nosuid,nod
/dev/fuse on /mnt/runtime/write/E1C9-1514 type fuse (rw,nosuid,no
i9100:/ #
[Galaxy S II Original Android Development] Lanchon:
lol, i suppose, that too!
[Galaxy S II Original Android Development] Lanchon:
btw i found this lying on my harddrive. i dont know what it is, i dont remember. it is probably a attempt to hack official TWRP to work in emulated mode. i suppose it might not work because i dont remember success, but for sure it wont be anything malicious, so you guys can try it if you want.
[Galaxy S II Original Android Development] the.gangster:
Thx. I would have taken a look at TWRP anyway so I'll have a look at that one as well.

If I only had more time....
[Galaxy S II Original Android Development] the.gangster:
hm,

adb shelling to to both my i9100 devices doesn't work when in TWRP, as adb doesn't find my devices then.

error: no devices/emulators found

Tested that with four adb versions (1.0.31, 1.0.32, 1.0.35 and 1.0.36).

Also tested against TWRP 2.8.7.0.

MTP-mounting in TWRP works fine.

As I use it frequently it is needless to say that when booted into the ROMs (CM13+LineageOS14.1) both work fine with each of those adb versions.

Any idea? Special drivers needed for that?
[Galaxy S II Original Android Development] Lanchon:
some adb operations require being root on the pc side. why? i don't know. it might be a strange safeguard in the adb client, i never understood that.

try:

sudo adb kill-server

sudo adb shell

if on linux.

on windows open an administrative cmd prompt and run those two same commands (without sudo of course).
[Galaxy S II Original Android Development] the.gangster:
Thank you but: No it's none of that. (Yes, I am still on Win7 x64 Pro)

Those were the first actions that I checked already even before trying with the other adb versions. And if you are switching from one version to another the old adb is also killed automatically.

It's not that simple. ;)

But thanks anyway.
[Galaxy S II Original Android Development] matee89:
[MENTION=5948428]askb4uwreck[/MENTION]: Have you tried to wipe cache partition + dalvik/art through recovery? That solved my issues with insufficient storage space.
[Galaxy S II Original Android Development] The Weeping Angel:
Thank you for the suggestion matee89. Just tried that through the advanced wipe options in recovery but sd card still shows up as 7,56MB with 5,26 MB occupied.
[Galaxy S II Original Android Development] matee89:
From what I've understood, that little sdcard partition will be mounted and unused, since the rest of capacity is used for /data, where your actual internal storage will be accessible (although it depends how did you partitioned your phone, but I assume that you've followed the guidelines for emulated storage migration).
[Galaxy S II Original Android Development] fireburner-de:
I am migrating to LOS 14.1 and additionally wanted to switch to emulated storage.

So far changing /data/system/storage.xml seemed to switch.

But now I am stuck with

When I type getprop o.vold.primary_physical it gives me 1.

But setprop o.vold.primary_physical 0 does not change this.

Does anyone why or am I doing it the wrong way?
[Galaxy S II Original Android Development] PackElend:
Does anyone have experience with emulated internal SD plus an extended internal storage (Adoptable Storage) by making the extSD internal storage.

[IMG="Format as internal storage"]https://www.androidcentral.com/sites/androidcentral.com/files/styles/larger/public/article_images/2015/11/Format-as-internal.jpg?itok=2kYGE-Ya[/IMG]
[Galaxy S II Original Android Development] PackElend:
in addition, has anyone tried to switch to F2FS as described below
[Galaxy S II Original Android Development] PackElend:
[MENTION=4399645]Lachon[/MENTION] I've always that is all about get from such a layout:

to this layout:

obviously it isn't.

Could you some information such as partition table, device storage view in settings, showing the state before and after switching.
[MENTION=6560258]the.gangster[/MENTION] more or less started this in his post

but it misses the original state.

That would it make easier to understand all this.
[Galaxy S II Original Android Development] PackElend:
This process didn't get along smooth at all but I'm quite happy that latest LOS 14.1 runs on my S II. There were some events during this process which haven't been answered yet. May some of you can answer some of them, e.g. why repit has never succeed to mount /sdcard and why the command adb backup - twrp doesn't trigger anything.

-----

I case the quote don't gets you to the referenced post: 22th July 2018, 09:34 PM |#92
[Galaxy S II Original Android Development] philsilvers:
Could someone advise me please....am I right in assuming that this conversion leaves around 7.91mb free space in sdcard0, making sdcard0 unusable, and any downloads I make or pics etc will go to the external SD card and won't work without an external SD card installed, this what I'm getting & don't know if I've done something wrong because I was expecting the files to look like los16 files with one shared storage folder and no sdcard0 folder, in the files app, thankyou for any help.
[Galaxy S II Original Android Development] shkedov:
Nothing that you have described has happened to me. Please report accurately the process you have performed
[Galaxy S II Original Android Development] philsilvers:
I followed page 9 instructions, is that right, thanks.

---------- Post added at 12:47 AM ---------- Previous post was at 12:30 AM ----------

Just noticed I made the mistake of not using the ROM with emu and used a non emu rom, so I'm going to start again, thanks.
[Galaxy S II Original Android Development] shkedov:
Oh my gosh, good luck! Always backup!
[Galaxy S II Original Android Development] philsilvers:
Could anyone tell me a solution to this please - sdcard1 won't open in file manager, keeps asking for elevated permissions even though it is set to root access mode and the phone is rooted, so I can't access my external sd files via the file app. Everything is working fine via settings/storage I can access external sd card files here, thankyou.

---------------------------------------

Edit - all ok now, fixed it.

---------------------------------------