Today Google announced that Video and Voice “chat” is coming to Google Talk on Android. I just got an Acer Iconia Android tablet yesterday, and it already supports this.

Understand what this means – you’ll be able to call and video chat with other Android phones, tables, and anything that can run GMail & GTalk in the browser. No need for a phone carrier. All that you need is network connectivity, which could come in the form of ubiquitous wifi.

Sure other apps are doing something similar. There’s Skype, Qik, Fring, etc., but I already use Google for my phone. Because of that I already have GTalk – built-in. All my contacts are already there. I think only Google can make this ubiquitous. Google Talk is based on an open protocol, so anyone can implement an app that integrates with this service. You also have Google backing the connectivity.

Also remember that not too long ago, Google tied Google Voice to GTalk so you can make phone calls from your PC. Free calls at that. It’s all coming together now.

I was enthused about the announcement of the Android Market Licensing Service. This is a step in the right direction to fight rampant piracy. You can actually now use a pirated version as an opportunity to sell your app. If someone downloads a pirated version, you can use the licensing service to detect it and direct them to buy the paid version.

However, there are a couple of problems. First of all, the generic version of the licensing code has been cracked. Tim Bray responded to this with the comment that “100% piracy protection is never possible in any system that runs third-party code…” Quite true. Contrary to this Google blog entry, it’s usually easy to crack. All forms of licensing, unlocking, server-side validation, and tamper detection come down to some point in the code that essentially says:

if (!licensed) { rejectUser(); }

It’s relatively easy to find this “if”. The pirate just has to debug the code, run to the point of rejection, and work backwards. The cracker can change the value of “licensed” or change the “then” branch in the Dalvik code to branch to the point after the “if”. Server-side validation can be circumvented the same way – at some point it all comes back to your code. Once cracked, the pirate can post the .apk online and almost anyone can install it. All of your hard licensing work as a developer has been wasted.

This is the problem with any license check embedded in an app. Once the app has been cracked by one experienced person, it can be distributed to thousands of unexperienced users. We need something harder to crack and near-impossible to distribute. I think the solution lies in Android itself. Android needs to check if the app has been licensed when launching the app. If it hasn’t been, reject the user. Then the potential crack lies in the Android system code. Most people are not going to installed a cracked version of Android.

Any time you put an additional step in the sales process, you gain an opportunity to lose a customer. Such is the case with Free and Paid apps. It’s a common freemium pattern in the Google Android Market and Apple App Store.

You’re familiar with the pattern – there’s a Free version of the app that’s restricted and then there’s a Paid version that has all of the features. As a developer, the problem is that you have to maintain two versions of the same app. You have two app store listings. You have to track two sets of stats. It’s difficult if not impossible to track Free to Paid conversions. You can’t tell if your marketing tool (the Free version) is working.

As a customer, you may like the Free version, but find it confusing how to upgrade to the Paid version. Here’s the typical scenario for the Android Market:

George is taken to the Market app and is presented with the single-line app listing. This shows the price and rating. He doesn’t care – he knows what he wants already. He’s made his own rating in his mind. This is the first chance for George to leave the sales process.

George clicks on the app. He sees the description of the app, screenshots, etc. He doesn’t care – he already knows what the app is all about. Second chance for George to leave.

George clicks the “Buy” button.

A list of security permissions is presented. George doesn’t care – he already agreed to them with the Free version. Chance 3 to leave.

George accepts the permissions by clicking “Ok”.

George is taken to Google Checkout. If George doesn’t have a credit card setup already, he must do so now. It’s a fairly cumbursome process. Chance 4 and 5 for George to leave.

George clicks “Buy Now”.

The download starts. George is returned to the app description with a button that says “Cancel Download”. Why? He just purchased it. Chance 6 for George to cancel.

After the download is done, the buttons change to “Open” and “Uninstall”. Uninstalling at this point grants an automatic refund. Chance 7 for George to leave.

If George clicks “Open”, he’s taken to the Paid version. Good. That’s what we wanted.

But wait…there’s more! George now has to hunt down the Free version of your app and uninstall it. He doesn’t need it anymore. Some users get confused at this point and end up uninstalling/refunding the Paid version on accident.

Whew! George should get a medal or something! This could be much simpler. You create one version of your app. It starts out in restricted/Free mode, but it’s unlockable. Then the scenario could be:

George makes one free download.

George likes it. He clicks “Buy Full”.

George is allowed to pay via carrier billing (simplest) or checkout with any online payment provider he might have.

Android Market allows your app to detect whether it has been unlocked, possibly via an enhancement to the licensing service.

George is returned back to the same app which is now fully featured.

This could also happen incrementally, allowing George to unlock multiple features as he wants them. How ’bout it Google? In-app payments? Simplified payment process? Support for payment methods you already have?

I must give many thanks to my wife and kids for putting up with my long hours and lack of attention while I was completing our new game Syrious Blasts and launching our new brand Syrious Games. Your patience with me is greatly appreciated!

My Dell Studio 15z (Windows 7) has been waking up by itself at night for some reason which I haven’t determined yet. It’s not waking for virus scans. The bad part is it doesn’t shut itself back down. The other night I had it hibernated and it was not plugged in. When I got up in the morning, the battery was dead.