Using AWT means you need to drag in a bunch of other stuff, from Bitmap and
elsewhere, that are not necessarily appropriate for Android. Also the
implementation for Android is quite optimized for running on mobile class
hardware, in a multi-process environment. (Just supporting the standard
core Java classes is often quite painful for us, because of how heavy-weight
they can be.)
Generally, using an existing API can have significant disadvantages as well
as advantages. Especially for something like AWT, where you are in a
position where you would need to compatibly support whatever existing APIs
you use, having to work under that existing API can actually make it a lot
more effort and less efficient to implement your desired system.
- We acquired the Skia graphics library for use in Android. Using AWT would
require significant work to expose that in the AWT API in a compatible way,
rather than directly exposing its actually rendering API as done in the
Android Canvas class.
- The AWT event model is fairly mouse-centric. It has concepts like moving
a pointer over the screen without a button being down, which we don't care
about, and lacks information like pressure and size (and its coordinates are
integers instead of floats). Likewise there is a slew of virtual key codes
we don't care about, and no standard definitions for ones we really care
about like search, home, back, call, hangup, etc.
- We have a lot of core concepts we want to have integrated into our view
hierarchy (contexts holding themes, layout inflation from xml, searching by
id, etc) that don't exist.
So what it boils down to, is we would be looking at implementing the generic
AWT, and them building our "desired" API on top of it. This would make
things a lot more complicated, introduce a lot more overhead (casting to our
extended view class continuously as we traverse through the view hierarchy
looking for an id!), and be of questionable benefit.
At then end of the day, the view hierarchy is at the very heart of the user
experience, and we had a specific experience we wanted to achieve. So it
makes a lot of sense for Andoid to define its own core UI model, designed
specifically to support its UI model, as the platform APIs.
And if you want AWT on Android... well you can implement the AWT APIs on
top of the Android UI. That's how AWT is supposed to work, right? ;)
Android framework engineer
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and