In part 1 of this follow-up I discussed what you might call the “cosmetics” of the Marshmallow update. It’s time now to delve into the more profound changes under the covers.
The Adoptable Storage Story.
The concept of “adoptable storage”, introduced in the Marshmallow update, appears to have originated from Google’s initiative for budget phone designs that use only a minimum of storage. One gig of RAM and eight of flash is enough for basic smartphone use, but as you add more apps it’s handy to be able to expand this, rather than having to go out to buy a new Android device.
This is what adoptable storage does. Well, not quite. It actually replaces system storage. This means, in the case of the standard 16GB Shield TV, that plugging in a 16GB microSD card or adding a 16GB USB stick gets you nowhere. The storage you add needs to be bigger—in fact, considerably bigger—than the machine’s internal storage for there to be any real advantage.
And here we’ll have to break off to talk about Android’s unfortunate nomenclature.
Internal versus External Storage
For as long as I can remember the Android file system has always featured something called “External Storage”. You might think this name would apply to an attached USB stick, or an inserted microSD card. It doesn’t.
“External Storage” actually refers to a virtual SD card, carved out of internal memory. It’s “emulated storage” and is filed under /storage/emulated/0.
Real external storage is found in the file system under /storage/sdcard (and there may be other links to the same device, for example /mnt/sdcard).
But when you use adoptable storage the real external storage and the real internal storage get swapped round, and the real internal storage becomes inaccessible (it seems to be used as system cache to speed up access to the adoptable memory).
I’d love to be able to explain the structure fully and rationally, but—although the Android file system is based on Linux, the operating system I’ve written about for years since its inception—Android’s implementation leaves me puzzled. The confusion deepens when you use apps like CX File Explorer or (my preferred file system app for the Shield) X-plore. Invaluable though both these apps are, they offer different views of Android’s file structure.
A Seriously Fast SD Card
My initial Shield “adoptable storage” setup was based on a 128GB Toshiba Exceria Pro full-sized SD card. The Shield doesn’t, of course, accommodate full-sized SD cards, so I used a cheap (£4.00 inc p&p) SD-to-USB3 adapter from the 7 Day Shop.
Apart from the physical disadvantage (see picture) the adapter did the job perfectly, and the super-fast Exceria’s 128GB was a flawless replacement for the Shield’s local 16GB.
The SD card sticks out of the side of the adapter, making the adjacent USB slot inaccessible.
This lead ES File Explorer to believe that I now had approximately 128GB (in fact 117GB, as some space is lost to the file system structure) of “Internal Storage” and a USB stick (designated as USB3004) attached as an OTG (on the go) device.
X-plore, on the other hand, was of the opinion that my USB drive’s capacity was 117GB, but that my internal storage was zero bytes.
At the raw file system level both agreed that /storage was zero bytes.
And to add to the complications, the Shield’s own Storage & Reset reported that 11GB of Internal Storage was available (although there seemed to be no way of getting to it) and the USB drive capacity amounted to 117GB.
If I eventually come to a rational understanding of the Android file system (and as ever your input is welcome) I’ll set it out here as a Data Sheet. Meanwhile, enough to say that “adoptable storage” really does work (if you use fast memory), as long as you don’t fry your brain trying to figure out its precise structure.
Toshiba’s excellent 128GB Exceria SD card is destined for testing in a camera in the fullness of time, so I’ve now removed it from the Shield, replacing it with a 128GB microSD card from PNY.
Marshmallow Memory Swap Walkthrough
Replacing adoptable storage is perilous. If you do the wrong thing you can inadvertently wipe the whole setup. If you do the right thing you still hit a minor bug that looks as if you’ve lost everything. Bear with me as we step through the process, and I think you’ll see what I mean.
I was tempted to use Storage & Reset to eject the USB drive, but prior to doing this it was going to be necessary to move all the apps and data back onto the (genuine) internal memory. This function, called “Move data now” is only available under the “Internal Memory” section of the menu.
Trying to activate this warned me that there was “not enough storage space”. It turned out to be no sweat to uninstall a couple of easily reinstallable apps and copy off my Game Recordings (which can get very large) to the NAS. (More about this in part 3).
Marshmallow’s “Move data now” warns you that the process can be time-consuming (see picture above). With fast memory like the Toshiba Exceria card the wait isn’t too bad: the whole process of cleaning off the excess data and disposable apps and then using the Shield’s move function took about a quarter of an hour.
At this point I checked into Asphalt 8 to make sure that my fleet of vehicles and my 1.5 million odd credits were intact (yes, sad, I know) and then ran a few races. My trusty Volkswagen Beetle Turbo sailed through Test Site Omega as smoothly as ever.
Before inserting the PNY microSD card I ejected the USB adaptor with the Exceria card, safe in the knowledge that all my apps and data were back on the Shield’s main storage. I thought it would be OK to ignore the warning the Shield was giving in connection with the Eject button: “Some apps will be unavailable or will not function correctly until the drive is reconnected.”
To test this, I tried running Asphalt 8.
It loaded and hung. So did Kodi. Nothing worked. The apps did indeed “not function correctly”. WTF???
I remounted the USB/Exceria and checked with Storage & Reset to make sure that the apps and their related data had been genuinely moved back onto the Shield’s inbuilt memory. They had. The directory structure of Apps, Photos & Videos, Audio and so forth was still there, but each of these showed as empty.
All was lost. My l33t fleet of racing cars. My 1.5 million credits.
Well, not really. It may be that Android is as confused about its file system structure as I am. Because the Apps Move function seems to forget to reset some of the operating system pointers to where the stuff has been moved to. The apps and their data are back in the right place inside the Shield’s own memory—it’s just that the operating system doesn’t know this.
I guessed that simply restarting the operating system would fix this.
It did.
Phew!
Nostalgia
Now is was just a matter of inserting the PNY 128GB microSD card and going through the whole adoptable memory thing again.
But there’s another catch here too. Although the USB/Exceria storage device has been emptied of all its apps and data and ejected from the Shield, the Shield still “remembers it”. And while it retains this nostalgia for the removed storage it is not inclined to adopt anything else in its place.
I was baffled by the absence of an option to set up the SD card as “internal storage”. That “nostalgia” was the reason. You have to tell the Shield explicitly to forget the USB arrangement before it will allow you to adopt any other storage.
This is clearly a bug. Android should know there’s now nothing on the external storage. After all, it did the moving. So there’s nothing to forget.
Once this is out of the way, formatting the SD card for its new function only takes a few seconds. As soon as that’s done you’re offered the option to move the apps and data out of real internal memory onto the SD card. There’s the usual warning that the process “may take a while” and that subsequent game performance may be affected “up to an hour”. I’m guessing this is to do with the way real internal memory caches the data off the SD card.
In the next part we’ll discuss the difference between using these two external memory devices, and investigate some of the new networking possibilities opened up with Marshmallow.
Chris Bidmead