This is the answer I got in the adt-dev forum:
This isn't supported well yet, but it's definitely something we want to do.
There are two main limitations.
The first one is the platform: When you have a custom view, you have
to manually modify your project to declare the styles that your View
will use via XML. It would be nice if we can figure out a way here to
make this process easier -- possibly using annotations on the view
class that the tool can use to infer which attributes are available,
or perhaps allowing (via our API, discussed below) your widget to
contribute metadata to the styles.xml etc file which we add to the
project on demand when the widget is first dropped (and that would
also use to infer information about your custom view's properties; we
currently just use some basic reflection.)
The second is the tool: We have a lot of support for adding
"designtime" support for the various views. Pretty much all custom
behavior you see for the various views (the guideline feedback shown
in relative layout, the context menu items for setting properties or
specific properties like id, width and height, the automatic drop
handling (setting the layout weight of a text field in a linear
layout, or setting a drawable image when you drop an image view, and
so on) -- all of that is done via a "designtime API"; it's hardcoded
in the layout editor tself. And furthermore, the designtime helpers
live separately from the views, so you can create new designtime
helpers for new widgets and supply them to the tool. By default, the
tool will look in the same package as the custom view (as well as a
few other places) to see if it can add designtime behavior to a custom
view in the layout.
That's the good news. The bad news is that this API is still in a lot
of flux, and while the API lives in a separate package (and is
completely agnostic from which window system etc you are using, so in
theory the designtime helpers used for our Eclipse layout editor could
also be used by any potential other layout editors written in Swing
and so on) we haven't properly pulled it out from the remainder of the
IDE, so there isn't a simple .jar file you can just use as your
library jar to build your designtime helper against. What you have to
do is build the IDE plugins (documented on tools.android.com/build),
place your designtime helpers in there somewhere, build them, and then
pull these jars out and ship with your custom view (but probably in a
separate jar, even if in the same package, such that a running
phone/tablet app doesn't get bloated with designtime classes).
We definitely want to improve the workflow for this, as well as work
on finalizing the API (I'm about to file a CL for a big change to how
actions work for example) -- but it's still going to take some time.
Our focus has been on getting the base level functionality for the
built-in widgets up and running. However, having you and others
actually wanting to use this functionality makes it not just more
important for us to work on, but can also help us drive the API
forwards when we see your use cases and API requirements.
This was from Tor Norbye on the adt-dev google group.