[Relwal]

Here's what I believe is going on:

Honeycomb adds a framework to support DRM plugins. Android 3.1 adds an actual implementation of a DRM plugin called Widevine (acquired by Google in Dec. 2010). Android 3.1 also supports HDCP. The DRM plugin is technically not built into Android; it's a modular add-on. The interface to the DRM plugins is part of Android.

In order for DRM and HDCP to actually work the DRM system has to validate that the system can be trusted. (That's all that DRM does.) If the system is rooted, apparently the DRM system can not validly claim that the system can be trusted.

Google's YouTube Movie Rental service that's part of the Android Market on Android 3.1 apparently relies on the DRM system to validate that the system can be trusted. (This condition may have been part of the deal to get the movie studios to allow their content to be distributed and rented through the Android Market.) If the DRM framework reports that the system can not be trusted because the system has been rooted then the jig's up -- no movies.

Bottom line: you can't have a movie rental service that requires that the system be trustworthy and a possibly untrustworthy system that would result from the system being rooted. You can have one or the other -- not both.

[darklajid]

What I'd like to understand is how pluggable these DRM plugins are. For most things on Android you can just replace the default thingy with your own (dialer, home screen are prominent examples).

How long until someone comes up with a custom DRM plugin that returns true for all validation requests?

[tomjen3]

You properly have to replace the entire component - eg you have to decrypt the movie (easy enough since the master key was leaked some time ago), talk to the hardware, etc.

[Relwal]

An app that is using android.drm will probably be looking for specific DRM plugins.

[odiroot]

Plugins that would be signed. It'd also make sense if the whole communication with content owners (or Google) was encrypted.