The Linkify Problem: The Patent and the Behavior

We as Android developers will start to see functionality regressions on various devices, courtesy of software patent disputes between Apple and several Android device manufacturers. We are already seeing this with newer HTC devices shipped in the US, and it is well within reason that other manufacturers will follow suit in coming months, albeit in their own ways.

In February of 1996, Apple Computer, Inc. filed a US patent application – granted in 1999 – entitled “System and method for performing an action on a structure in computer-generated data “.

Now, for the record, IANALNDIPOOTV (I am not a lawyer, nor do I play one on TV). If you want a detailed examination of this patent, please consult with qualified legal counsel, not a blogger.

That being said, in a nutshell, this patent covers, among other things:

• A computer detecting various “structures of data”
• Associating various actions with those structures
• Displaying a pop-up menu to allow the user to choose one of those actions

In the specific case of Android, Apple is complaining that this patent covers the behavior powered by the Linkify class and used in various places, such as when you set android:autoText on a TextView. In those cases:

• Android detects things like email addresses and URLs, via regular expressions and makes them clickable
• Upon a click, Android crafts an ACTION_VIEW Intent for the clicked-upon item and calls startActivity() upon it
• This startActivity() call may produce a pop-up menu, in the form of a chooser, if there are multiple possible activities that could respond to that Intent

Now, normally and historically, this would be a matter for the US court system to adjudicate, and that will presumably happen someday.

However, Apple has filed claims against Android device manufacturers with the US International Trade Commission (ITC for short). ITC has the power to ban imports of products that might involve “intellectual property” violations, if the ITC believes that the complaintant would be “irreparably harmed” by those imports continuing while the legal process churns along.

ITC’s efforts blocked import of a number of HTC devices.

HTC made modifications to their devices to attempt to eliminate the infringing behavior, and ITC has since allowed HTC to sell these modified Android devices in the US. Apple feels that HTC’s efforts were insufficient, and it is entirely possible the import block will return someday. It is also emininently possible that other ITC acts over this patent will affect other device manufacturers, and these manufacturers will make their own modifications to Android to try to get around the import block.

You may feel that software patents are a valid legal construct, or you may not. You may feel that this particular patent is invalid, or you may not. Regardless, what is indisputable at this point is that this patent is being applied and, as a result, select Android devices are changing their behavior. And, unfortunately, those changes affect us as developers.

Normally, on an Android device, if you click on a link that shows up in a TextView augmented by android:autoText, some activity will appear based upon what you clicked. A browser will appear for URLs, a mapping activity will appear for an address, and so forth. None of that has changed.

However, suppose you have two or more browsers, or you have two or more mapping applications, and you click on one of those links. On a normal Android device, a chooser will appear… but that is the behavior that Apple is asserting violates its patent.

On various US-sold Android devices, such as the HTC One S, you will not get a chooser. Instead, it will open one of your possible choices automatically. By default, it will be whatever app for this type of link came with the device, though you can go into an “App associations” area of the Settings app and configure which of your various applications should handle each of the restricted types of links:

• Phone numbers
• Email addresses
• Physical addresses
• Web URLs
• “Map addresses” (presumably geo: URLs, but that is unclear)
• Streaming links (presumably rtsp: URLs, but that too is unclear)
• “Online audio download by webview”
• “Online video download by webview”

On the surface, this may not seem too bad. It’s basically a return to classic Microsoft Windows behavior, where you used to have to go in and specify which application should handle which file extension.

However, the scope of the behavior change is a bit of a problem. You might think that it would only affect stuff powered by Linkify: direct use of the Linkify class, android:autoText, and so on.

You would be mistaken.

It affects everything that tries to perform an ACTION_VIEW on any of those URL types. Whether that comes from WebView, or you invoking startActivity(), or links created by Html.fromHtml(), or anything else does not matter. None of those will display a chooser if there is more than one choice and the user has not specified a default activity for that action, the way it will on other devices.

Hence, developers of browsers, email clients, mapping applications, media players, and the like, who might be expecting the user to choose to use their apps for handling these sorts of URLs will be disappointed. User can choose their apps, but they have to do so via Settings, not via a chooser. In fact, they may not even realize that they can make this sort of change, particularly if they are new to Android and are unaware of this whole chooser thing. After all, since the vast majority of devices do not have an “App associations” portion of Settings, the user is unlikely to run across references to it in blog posts and the like.

This can also impact developers who are calling startActivity() for these URL structures, as where you might have expected a chooser to appear as needed, none will on these devices.

Also, bear in mind that this is HTC’s response to the problem. Other manufacturers may make different changes as they attempt to get around the threat of import bans.

Tomorrow, I will point out how we can detect affected devices and some ways in which we can mitigate the damage.