A mess: Photo management on Android Oreo

“It’s not a nude, but it could be.”

At the risk of proving myself a fumbling, tech-illiterate boob, I must share my frustrating experience with stock Android’s photo management. I am genuinely flummoxed that it’s this shit.

Background: I’ve been using iPhones since the iPhone 4. One week ago, I decided I’d had it with sloppy iOS releases and wondered — with my debit card — if Android might be a happier mobile home. I bought a Pixel 2. I expected a somewhat clumsy transition as I unlearned years of iOS workflow and adapted to my new digs. I did not, however, expect Google’s own implementation of its latest Android OS to suffer buggy, incoherent management of photo files. (Android 8.0.0 Oreo is installed.)

I’ve not found solutions for the issues I’ve experienced, largely because the issues are so ambiguous and multivariate that I’ve failed at finding the correct search term that returns relevant discussions. I’ll do my best to describe the issues here, in hopes of connecting with some poor souls who’ve also struggled to find the right words.

First, nomenclature

One of the reasons I’ve had difficulty searching for my issues is that I’m unclear on Google’s nomenclature. Most of my problems stem from Android’s multi-image file storage, which I’ll blanket-describe as “burst” photos.

When shooting with the stock Camera app, you can press and hold the shutter button to burst-capture a series of frames. Google stores these burst captures as a single item in your photo library, but with small sub-photos that allow you to browse each frame within the burst.

I’m not shooting burst images per se. When using the phone’s vaunted portrait mode for sick selfies, the stock Camera app creates a “burst” stack with two copies of your photo. One of the sub-photos contains the selfie with artificial blur, the second sub-photo contains the un-bokehfied original image.

A “portrait” selfie, with blurred background, appears organized like a burst photo.

For the purpose of this post, I’ll use “burst photo” to describe such a photo, and “sub-photo” to describe one photo frame within the burst.

Export from Snapseed disappears originals

The first issue appeared after editing and exporting a photo via Snapseed. I love Snapseed, a fantastic photo editing app owned and operated by the same Google that makes Android. I have some expectation that it should function predictably with the stock OS (Snapseed works perfectly on iOS).

I edited an exquisite self portrait — some might call it a selfie — that I shot with the phone’s excellent portrait mode, making a slight crop adjustment and applying some selective contrast to bring out the highlights in my sunken eyes. On clicking the “Export” button to save my adjustments, I’m presented three options:

• Save: Create a copy of your photo
• Export: Create a copy of your photo. Sizing, format and quality can be changed in the settings menu.
• Export as: Create a copy to a selected folder.

I chose “Save,” Snapseed confirmed the action, and I went to the stock Photos app to find the file. Unfortunately this is where details get fuzzy, and I can only relay my own confusion.

• The “Saved” image appeared in a new “Snapseed” folder in the stock Photos app.
• I deleted this copy of the image and tried each of the other export options, hoping to find one that might save the edited photo as a sub-photo in the original burst.
• Somewhere along the way, I succeeded in saving my edit as a sub-photo of the original burst, but lost the un-edited bokehfied original. I swear I did not delete it.

I cannot reliably reproduce the issue, but it has resulted in lost images for at least two of my selfie masterpieces.

Empty “Snapseed” folder appears, unclickable

I tried to better understand the issue by deleting the self portrait and retracing my steps. To my surprise, within the stock Photos app, the “Snapseed” folder thumbnail still showed my dumb face, the dumb face I deleted from the folder. I tapped the thumbnail to — I guess — try and delete the file a second time, for real. But now that the “Snapseed” folder was empty, it wouldn’t open. It still appears in my list of albums, it still shows my dumb face, but it can’t be opened by the Photos app. (I’ve somehow managed to flush my face from the thumbnail, but the empty, unclickable “Snapseed” folder persists, even while the transient “Screenshots” folder politely disappears when empty.)

The empty “Snapseed” folder appears in my albums, and is unselectable.

Screenshot edited in one place, not in another

This morning, I took a screenshot of a web article and used the stock Android Photos app to crop the screenshot to highlight the single paragraph I was interested in sharing. The process seemed as simple and straight-forward as one could expect, until I jumped into my tweeting app (Fenix 2) to share the screenshot.

I composed a tweet, hit the button to add an image, and found the screenshot in its original, uncropped form. I jumped back to the Photos app, navigated to the “Screenshots” folder, and confirmed that the crop was made and saved.

I abandoned the tweet, and still do not understand why the screenshot has two separate states, each being accessed from different touch points within Android. I could not resolve this issue. What a mess.

Photos vs. albums

The stock Photos app is at least somewhat to blame for the confusion. For starters, there are two core browsing tabs in the app, “Photos” and “Albums.” The former is a time-sorted thumbnail grid of every photo in my Google Photos library (including literally hundreds of photos from my pre-Android usage of Google Photos). The latter is — I think — the same photos, but sorted into both (a) algorithmic albums and (b) on-device folders like “Camera,” “Screenshots,” and “Snapseed.”

Bizarrely, some of same photos that appear as burst photos in the “Photos” view appear as single-frame photos in the “Albums” view. On my local device, the sub-photos are simply missing from these bursts.

Deleted burst photos leave empty folders on device

I thought perhaps I might better understand my issues by installing a file browser for Android and digging around to find out what Google is doing with my photos. Unfortunately, this unearthed more problems. (It’s worth clarifying that (a) the app I’m using is called Amaze, and that (b) I have not used Amaze to make any changes to files on the phone, only to snoop around the file system.)

Seven days into Android ownership and I’ve already accumulated technical debt.

Photos from the stock Camera app are stored in a “Camera” sub-folder of the high-level “DCIM” folder. Within the “Camera” folder are my photos and videos. And a whole bunch of folders that follow the same file naming convention of the photos.

My best guess is that burst photos are stored in folders, rather than as solo photo files floating around loosely in the “Camera” folder. That makes sense. What doesn’t make sense is that most of these folders on my phone are empty.

It seems that burst photos, even when deleted entirely, leave behind these empty folder carcasses. My phone is a week old and already has a mess of empty folders cluttering its file system. What will this look like in a year?

Deleted photos still on device

Okay, a bunch of empty image folders isn’t the end of the world. They likely take up next to zero space, and I’m not meant to be browsing the file system like this anyway. But while digging around, I found something very disturbing: A photo I had deleted last week is sitting there, on my Pixel 2.

It’s not a nude, but it could be. Imagine what photo files might be lurking on your phone, or your friends’ phones. All it takes to find them is installing a popular, simple-to-use file browsing app and some willingness to comb through mostly-empty folders.

Android doesn’t appear to have any built-in file recovery or trash system for helping avoid accidental deletions — if it did, that might explain why the image is still there. But in fact, the deleted photo I found is only one photo out of dozens I’ve deleted over the past week. This doesn’t appear to be part of an intentional, intelligent file system, but the result of some really clumsy, possibly dangerous photo management.

(Update: A Twitter friend alerted me to the Trash section of Google Photos, which did indeed have this photo as well as others. I emptied the Trash and re-checked Amaze. The photo is still on the device.)

“Free Up” space, no thanks

In the stock Photos app, under the “Photos” tab, is a “Free up (n)MB from device” call to action. Because I’ve got cloud backups enabled, Google is encouraging me to delete the backed-up files from my local device.

I am already highly-skeptical of Google’s reliability in managing my photos, because of the experiences enumerated above. To make this prompt even more untrustworthy is how little it transparency it offers about what it will do. A confirmation prompt nonchalantly offers to “Free up (n)MB” at the press of a button, without clarifying at all which items will be deleted from my device, or what it means for my ability to access the photos that are backed up but not stored locally.

I’ve intentionally omitted any mention of behavior differences between iOS and Android. I’m generally pretty adept at jumping between operating systems, and understand certain muscle memories must be overwritten and that that process is sometimes frustrating, but not a fault. The issues described above, however, I consider massive faults.

And so far, the best solution I’ve found is disabling backups for image albums. Perhaps coincidentally, I have not been able to reproduce the aforementioned UX disasters when I try, but those tries have occurred after I disabled the backups which I’d suspected as a possible source of problems.

That’s Week 1 of Android. But Bluetooth works, so I’ll not go back to iOS just yet. Optimally, this post exposes some revelation that confirms I am, in fact, a tech-illiterate boob, and the wiser me can avoid problems moving forward. Worst case, I’ll see how messy this home gets.