Update: Google posts DRM workaround for paid Android Wear apps

DRM issues had prevented paid apps from working on smartwatches.

With smartwatches running Android Wear slowly starting to trickle out into the world, developers are coming to grips with Google's new wearable platform. In doing so, they have found one of its first big bugs: paid apps don't work.

Further Reading

Currently, there's no such thing as a "standalone Wear app." Watch apps must be downloaded by a phone using the Play Store and include an Android Wear component. After installing the phone app locally, the phone sends the Wear component to the watch over a Bluetooth connection.

Paid Android apps are encrypted, with the encryption key obtained from the Play Store and passed to the phone. But according to a report from Android Police, the key does not currently get passed to the watch. With no way to decrypt the packages, the watch fails to install encrypted wearable apps. The only current workaround is not to charge for the app, which removes the Play Store's encryption.

Developer support for Android Wear remains rough in these early days. One of the apps broken by this bug was a third-party watch face, which only existed thanks to the ingenuity of the developer community; Google doesn't have documentation available on how to properly write a watch face yet.

While no paid app support may be a real bummer for developers, it's probably just a bug. We've contacted Google for comment on this issue and will update if we hear back.

Update: Google has posted on update on the Android Developer Blog with a workaround for the paid app issue. The Android Wear APK normally lives in the "assets" directory, which gets encrypted. Google's temporary workaround suggest developers place it in the "res/raw" directory instead, which doesn't get encrypted. The automated packaging process won't do this, so developers will have to package the app manually by following this documentation.

Interestingly, Google says it will update the automated packaging process to use the "res/raw" workaround, too. There's no word on an actual DRM fix; the company is just making the unprotected workaround standard procedure now. In the post, Google says, "We're working to make this easier for you in the future, and we apologize for the inconvenience."

Ron Amadeo
Ron is the Reviews Editor at Ars Technica, where he specializes in Android OS and Google products. He is always on the hunt for a new gadget and loves to rip things apart to see how they work. Emailron.amadeo@arstechnica.com//Twitter@RonAmadeo

While a bug seems more likely because if it was a designed feature I'd expect a you can't do this error when submitting the app, it falls under the category of "how did QA miss it".

OTOH since apps on the watch are intended as adjuncts to the app on the phone, I could see Google deciding that any paid/not paid differentiation should be done by limiting what the phone app tells the watch app to do.

I wonder why DRM is even a requirement on the watch?I mean if you can't install apps on the watch directly, and have to use the phone for installing, isn't the DRM checking on the phone enough?

The DRM is on the phone, not the watch. A while ago Google added encryption for paid apps, so that they sit in a separate container and can't just be copied to another phone. Since then they have continually broken shit and never bother to actually test whether the functionality of paid apps works. My favorite was the disappearing widget act which took them over a year to fix.

Sure, I'm certain that this is an error and not a design decision. But "just a bug" is a huge understatement. I can't even begin to imagine how rushed QA must have been not to catch something like this.

The headline cleary states that Android Wear apps doesn't work, but then the article goes straight to say that there's no thing as "standalone Wear app". Then what are the developers doing? Sending regular Android apps to it so see if they work? And it doesn't seems to make sense since:

Quote:

Watch apps must be downloaded by a phone using the Play Store and include an Android Wear component. After installing the phone app locally, the phone sends the Wear component to the watch over a Bluetooth connection.

So the keys aren't sent to the watch because the phone app handles it all. Isn't that a design decision? Or the components send to the watch should transmit the encryption key to be installed there? I don´t get it. Could you clarify the issue, please?

EDIT: Ok, I bit he bullet and read the Android Police article. It says this:

Quote:

It seems the Android Wear install process runs into a road block with paid apps because it doesn't know how to extract the file of the encrypted apk. Since the installer fails to recognize the payload, it assumes there is nothing to install and silently aborts. This behavior appears to match another known issue that occurs if the Wear app is compressed more than once before it is published.

So the package goes to Wear to install itself there, but since it's encrypted it doesn't know how to open itself. I was thinking that it would decrypt itself on the phone before pushing it to the watch.

I don't develop for Android, but I would assume the cure would be, after the app is installed, the first time it runs, have it install the watch component itself. I am assuming Google prevents apps from directly installing code to the watch for security reasons.

Another solution would be, run as a free app that requires a one time subscription payment or in app purchase.

DRM: Still only harming the people who agree to pay money for an objectively inferior product.

"Effective" DRM (almost an oxymoron) has objectively been shown to reduce the amount of casual, rampant piracy in an ecosystem. There are at least a few studies (and some anecdotal tests of devs) that have shown that it can increase the amount of legal sales; at the very least it seems to increase the amount of legal sales vs illegal installs.

Does it "prevent" piracy? Ha. No. Not even close. Does virtually any system, even the most draconian, prevent widespread piracy? Well... For the most part? No. A few systems, though... Have been reasonably effective (most systems requiring frequent interaction with servers and paid accounts, like MMOs are especially effective but not the typical form of DRM. But heck, even SimCity 5 took a while to get properly cracked).

Does draconian DRM typically achieve its goals of "stopping" piracy? No way. Does it tend to lead to increased sales by REDUCING piracy? That's way more of a grey area - there's plenty of evidence pointing to "yes" or at least a "maybe". Do the downsides and risks of draconian DRM outweigh the benefits? From a user's perspective I'd say "uhhh, no. Absolutely not". From the authors' perspective I don't think it's nearly so clear.

I hate this argument, though. Anyone that says that "absolutely no DRM" would work best probably isn't being truthful, and DRM defenders are usually even more misguided. Anyone that says they're implementing DRM to "prevent" (and not "reduce") piracy is a moron.

What really pisses me off is people I know that steal stuff with the weakest amounts of self-justification. The lamest one I heard was yesterday. There was a game available for $2 (so price was incredibly reasonable) and there was no DRM. It was a small studio, and they need the money. The reason was "I don't want them to have my credit card info". I can't believe how weak that is.

I mean, look at World of Goo. Those guys did everything right. They ported it everywhere, released it cheap, DRM-free (on most platforms), and it's a hell of a good game. But upwards of 95% of installs are pirated. Dammit fuckers, you're just proving we can't be trusted.

Surprised reviews missed this. What is the point of reviews these days if they miss issues like these?

Reviews? What about testing?

I spend a lot of time revising and fixing other's code, and I love bugs like this. When I see something in production that has never and could never work, I know exactly what to expect from the rest of the code--it's all going to be poo. It's easier to know from the start that an program needs to be rebuilt from the ground up than dig through spaghetti code to find where the edge cases and exceptions fail.

If a paid app won't even install on the watch, you know how much testing was done on those apps. (None.)

Still remains true, no matter what type of media or content/application.

And in regards to rooting, I wouldn't be surprised if someone has managed to root the phone and then extract the key used to decrypt the app. Most DRM consists of a device that contains the key and encrypted content within the same system or memory space. A key at rest and encrypted content should never exist together where an untrusted entity (in this case the lawful owner of a device) has physical control. Hence why DRM will never be a valid crypto system.

The headline cleary states that Android Wear apps doesn't work, but then the article goes straight to say that there's no thing as "standalone Wear app". Then what are the developers doing? Sending regular Android apps to it so see if they work? And it doesn't seems to make sense since:

Quote:

Watch apps must be downloaded by a phone using the Play Store and include an Android Wear component. After installing the phone app locally, the phone sends the Wear component to the watch over a Bluetooth connection.

So the keys aren't sent to the watch because the phone app handles it all. Isn't that a design decision? Or the components send to the watch should transmit the encryption key to be installed there? I don´t get it. Could you clarify the issue, please?

No standalone apps mean there isn't anything you just download for the android watch. All apps with have a phone component and a watch component. Sounds sorta like client-server; the android phone is the server, the watch is the client.

If an app has a watch "client" that component needs to be installed on the watch. Paid apps require a key to be installed. The key isn't sent to the watch, so the component can't be installed.

Basically, it sounds like the android phone becomes the Play Store for the watch, only in this case the store doesn't pass along all the data needed by the watch to run the programs from the store.

DRM: Still only harming the people who agree to pay money for an objectively inferior product.

And then there is the apple crowd who love to point out how low app piracy is and how much money they make.

Rooting however doesn't solve that problem as I've tried taking paid apps off my phone to use elsewhere due to restrictions on form factors. Didn't work. Not saying it is impossible but it does make it not easy.

I am not sure I understand your problem. If you purchase an app for one of your devices, you get that app for every compatible device on your account. With Apple's new rules, you purchase it for your account, someone else in your family uses the same credit card number for their account, they get the app for free.

I wonder why DRM is even a requirement on the watch?I mean if you can't install apps on the watch directly, and have to use the phone for installing, isn't the DRM checking on the phone enough?

The DRM is on the phone, not the watch. A while ago Google added encryption for paid apps, so that they sit in a separate container and can't just be copied to another phone. Since then they have continually broken shit and never bother to actually test whether the functionality of paid apps works. My favorite was the disappearing widget act which took them over a year to fix.

It would delete sync accounts on reboot, too, if the app which set them up was a paid app. Cost me at least one bad review.

Look, I'm sorry, I know this will get downvoted. But my solution to this problem is a Seiko mechanical watch. All it does is tell the time and it needs adjustment every month, but so far it has never had a problem with DRM.

I still think that "smartwatches" really translate as "Oh dear, we're running out of ways of persuading people to buy new phones and tablets." Paying to be an alpha tester may entertain some people, but really my view is that if the designers want you to do that, they should do it for free.

DRM: Still only harming the people who agree to pay money for an objectively inferior product.

Steam seems to be doing OK and gets a lot of praise in these here parts.

Mainly because Valve spends a lot of time and effort to minimize the impact of DRM to the customers (I've literally never had a DRM issue with steam's DRM, can't say the same for other company's DRM), and because they also spend a lot of time and effort to heap upsides to using Steam to go with that DRM downside.

DRM: Still only harming the people who agree to pay money for an objectively inferior product.

And then there is the apple crowd who love to point out how low app piracy is and how much money they make.

Rooting however doesn't solve that problem as I've tried taking paid apps off my phone to use elsewhere due to restrictions on form factors. Didn't work. Not saying it is impossible but it does make it not easy.

I am not sure I understand your problem. If you purchase an app for one of your devices, you get that app for every compatible device on your account. With Apple's new rules, you purchase it for your account, someone else in your family uses the same credit card number for their account, they get the app for free.

Same on android without any limits. My point was DRM can work just fine.

Sure, I'm certain that this is an error and not a design decision. But "just a bug" is a huge understatement. I can't even begin to imagine how rushed QA must have been not to catch something like this.

Yeah, holy crap. I've seen some shoddy QA but nothing quite along the lines of "the biggest feature of this product does not work" shoddy. That's incredible.

DRM: Still only harming the people who agree to pay money for an objectively inferior product.

"Effective" DRM (almost an oxymoron) has objectively been shown to reduce the amount of casual, rampant piracy in an ecosystem. There are at least a few studies (and some anecdotal tests of devs) that have shown that it can increase the amount of legal sales; at the very least it seems to increase the amount of legal sales vs illegal installs.

Does it "prevent" piracy? Ha. No. Not even close. Does virtually any system, even the most draconian, prevent widespread piracy? Well... For the most part? No. A few systems, though... Have been reasonably effective (most systems requiring frequent interaction with servers and paid accounts, like MMOs are especially effective but not the typical form of DRM. But heck, even SimCity 5 took a while to get properly cracked).

Does draconian DRM typically achieve its goals of "stopping" piracy? No way. Does it tend to lead to increased sales by REDUCING piracy? That's way more of a grey area - there's plenty of evidence pointing to "yes" or at least a "maybe". Do the downsides and risks of draconian DRM outweigh the benefits? From a user's perspective I'd say "uhhh, no. Absolutely not". From the authors' perspective I don't think it's nearly so clear.

I hate this argument, though. Anyone that says that "absolutely no DRM" would work best probably isn't being truthful, and DRM defenders are usually even more misguided. Anyone that says they're implementing DRM to "prevent" (and not "reduce") piracy is a moron.

What really pisses me off is people I know that steal stuff with the weakest amounts of self-justification. The lamest one I heard was yesterday. There was a game available for $2 (so price was incredibly reasonable) and there was no DRM. It was a small studio, and they need the money. The reason was "I don't want them to have my credit card info". I can't believe how weak that is.

I mean, look at World of Goo. Those guys did everything right. They ported it everywhere, released it cheap, DRM-free (on most platforms), and it's a hell of a good game. But upwards of 95% of installs are pirated. Dammit fuckers, you're just proving we can't be trusted.

Regardless of my personal feelings on the ethics of piracy, I stand by the point I was making. Software with DRM is objectively and inherently inferior to the same software without DRM. Given that piracy does not, by your own admission, actually stop piracy, or even pose a significant barrier to pirates, the only users who will be inconvenienced by DRM are those who actually buy the software in question.

I think it's funny that a system built on the principle of being "open" tends to have apps with more restrictive and draconian DRM than most anything on Apple.

Apple has to sign each and every copy of iOS for every iphone 4s and higher, preventing downgrades. Every apple app requires signing to run, not just for verification. And of course, apple won't allow any non store apps, and will never allow unlocking their bootloaders.