As most of our readers know, an update to the Play Store rolled out a couple of days ago with a feature many of us have been requesting for nearly three years: the ability to join and leave beta test groups from within the Play Store. For reasons we can only speculate about, the join/leave capability was disabled about 24 hours later. While the headlining feature was covered in our original post, there are still a couple of interesting tidbits waiting for the teardown treatment.

Teardown

Disclaimer: Teardowns are based on evidence found inside of apks (application packages) and are necessarily speculative and usually based on incomplete information. It's possible that the guesses made here are totally and completely wrong. Even when predictions are correct, there is always a chance that plans could change or may be canceled entirely. Much like rumors, nothing is certain until it's officially announced and released.

Pre-Caching Play Store Data

If you don't have exceptionally fast cellular data, digging around in the Play Store can feel like the slowest thing you'll do on your phone all day. Between app icons, banners, and screenshots, the number of images can climb pretty quickly. It's not unusual to spend a few seconds watching at a loading spinner, even on fast Wi-Fi. Imagine if you could download some of that data ahead of time. It turns out, that's exactly what Google is going to try out.

Text in the latest Play Store update indicates there will be an option to "preload up to 20 MB" of data from the Play Store while it is connected to Wi-Fi. Google refers to this as "lite mode." Speed is the focus of this feature, but it seems like it should also reduce data usage on cellular networks, which is good news for users with very tight data caps and pay-as-you-go plans.

<string name="lite_mode_settings_description_info">Preload up to 20 MB on your device, over Wi-Fi</string>
<string name="lite_mode_settings_label">Faster store experience</string>

Assuming your device isn't catastrophically low on storage space, this should probably sound like a great feature. There is still one really big question: what is it going to download? After all, we can only see performance gains on things that are downloaded, and 20 MB is a fairly low point for a cap.

The primary landing page seems like an obvious first choice since it loads just about every time. There are plenty of icon images, but that's probably not going to fill 20 MB by itself. It might make sense to extend this to the major subsections, like Music and Books, but the usefulness of those pages is limited, and they probably won't all fit into a 20 MB cap. It's possible Google may choose to go with something a little more clever and apply some basic statistical analysis to determine which sections are best to preload for each user based on browsing or buying habits.

I'd also like to think the listings for installed apps would be preloaded. In my experience, responsiveness drops to a crawl after jumping into the individual listings in the Installed Apps page. Google could also choose to preload the listings of featured and known popular items in the store that are expected to sell very well, like brand new movies and books.

There is one other question, but it's a little easier to guess: when will downloads happen? To begin with, updated content will obviously happen in the background when a device is on Wi-Fi, and most likely while it's charging. Since the Play Store rarely changes its featured content more than once in a given day, it's a pretty safe bet that updates will be downloaded with the same frequency. Since a lot of the images for recommendations and top sellers might not change for days or weeks at a time, they shouldn't need to be downloaded again, which means even the implications to Wi-Fi usage are pretty small.

Android Wear Updates?

This one is more of a curiosity, and it may be nothing, but it's worth a brief note for now. A single new string popped up that refers to checking if there are updates for an Android Wear device. The phrasing is a bit odd, though. The way it reads, it could be interpreted as either checking for firmware updates or for updates to apps that include an Android Wear micro-apk.

<string name="wear_foreground_update">Checking for updates for your Android Wear Device</string>

Why does this seem weird to me? Put simply, neither of the likely scenarios warrant this message. Checking for firmware updates is the responsibility of the watch, and it works through Google Play services and the Android Wear app. The Play Store app probably doesn't have a reason to make that check unless it's going to actively tell users that some apps won't work on their current firmware.

The more logical interpretation of the string is that it relates to app updates, however, the Play Store already does this for all apps, not just those with Wear apps. This string could just add new wording or give a helpful hint, but it's hard to picture where it would belong and how it would actually make sense for users.

With both of the likely possibilities out of the way, and no other good explanation, it doesn't hurt to briefly indulge the possibility that this might relate to an entirely new feature. Perhaps Android Wear will finally support apps direct from the Play Store, without the need for a companion app installed on a phone.

Even if the odds are stacked against a major new feature, this string is just unusual enough that it caught my attention. Who knows, Google might have some Wear-related surprises in the pipeline.

The Android Wear string is showing up in an odd place.

It seems this one is live, but it's still not really clear what it's for. Ben Bradey posted to Google+ with a screenshot showing the text in a notification. Tapping on the notification doesn't produce any result, which may suggest there's a bug in the feature or this may be some sort of courtesy notification. It's even possible this is a debug message that was never meant to escape Google's testers. Whatever the case, the text has been found in the wild, it's just not clear what it's for.

2016 - 1