Quote:
Originally Posted by Quoth
You need a bigger battery for same run time, which adds expense.
|
Of course. But does the cost per unit in bulk for adding a few hundred mAh offset the cost of paying programmers' salaries? I expect the answer is "yes" but I don't have data to back this up.
Quote:
|
Stock Android UI is poor on eink, so Android eink would save them little in total cost of the Kindle eco-system development.
|
None of the Android-based ereaders I've seen use a stock Launcher. They use a Launcher app tuned for e-Ink. The savings comes from unifying the OS and reader: one OS and one reader app that work across all devices instead of Kindle and Fire having entirely separate code trees.
Quote:
|
Switching to MTP for Kindle eink is likely more about having more than 32 G Flash and not having FAT32 and extra security, not about having code in common with the Amazon Fire (an Android tablet).
|
Could be. Two notes though:
First is that FAT32 works just fine on larger devices. It's Microsoft's tools which are hard-coded to say "no" if you try to put FAT32 on larger devices -- likely an effort to "encourage" vendors to license exFAT. mkfs.vfat will happily format any device up to I believe 2TB. I can't recall doing this myself but I do have 256GB and 512GB microSD cards formatted FAT32 for my Switch and for one of my (currently disused) music players and they work perfectly well.
Second is that the security is an Android thing. Android's application security model is one app = unique UID/GID so that one app cannot "see" another app's data. This does not work on FAT32 or exFAT so Google got rid of them entirely in favor of ext4. Google removed external storage as part of this conversion because this security is easily bypassed with a USB card reader. Google then removed USB Mass Storage from Android because Windows and Macintosh cannot mount ext4 filesystems.
If Amazon aren't looking to migrate Kindle OS to an Android-based stack then I think the move to MTP and the elimination of D&T is simply a consequence of using a Linux native filesystem internally.