The rather extraordinary claim that a future version of android will be able to "automagically" adjust the UI to suit screen size needs some serious evidence to back it up.
Obviously, the operating system is not going to be able to produce the same design decisions that would be made in light of actual experimentation with real users - it will be based on heuristics that will produce sub-optimal results for just about any combination of screen size and resolution other than the original. So I'll assume that you merely meant to assert that the scaling will produce results that are "good enough" in that normal users won't notice that the UI doesn't fit their tablet.
Even the claim that it will be "good enough" seems outlandish. Consider the kinds of scalable GUIs that exist on desktops: the important elements of the GUI (like toolbars, menus, and standard buttons) don't get re-sized. At best, they get wrapped or scrolled, either of which is instantly recognizable as a bad design. Most of the sizing flexibility on desktop apps is in the areas that show relatively static content that the user only interacts with passively, like in a web browser or video player, or in the case of many types of games, areas that you only interact with in small bits at a time. (Word processors alternate between the presentation of static content and the interaction (ie. editing) of one spot at a time.)
On a multitouch display with direct manipulation of the GUI, you will typically have far fewer opportunities for the easy scalability that web browsers and word processors enjoy. You have to know which UI elements need to maintain the same physical size, which ones need to maintain the same pixel dimensions, and what the limits are on the scalability of the other elements.
Take as an example the iPad email app. In landscape mode, you have a list of messages on the left (showing subjects, the first line of the body, and a few other pieces of info), and the body of the currently selected message shown on the right. The right pane takes up about 2/3 of the screen width.
If you were to scale this app from the 4:3 iPad display to a 16:9 tablet, how would the left/right split ratio have to change? It's complicated: the entries in the left-side list will have to maintain roughly the same physical height, because they are essentially buttons. You probably want the left pane to remain at least as many characters wide as in the original, so the physical width won't change by much, but you have some flexibility in font sizes. That means that the right pane showing the body of the email will probably be slightly wider and shorter on a 10" 16:9 tablet, but on a significantly smaller tablet, the left/right split might be 50/50.
All that is merely a first approximation of how that one app would have to scale. Could a computer derive that? How will the operating system know what the driving constraints are? The OS certainly can't know whether it is better on average to use the extra width of the 16:9 tablet to show more of the subject lines on the left or more of the body on the right.
It seems that the only way to make a scalable touch UI work is for the designer to bake in the constraint information, which will require testing at different sizes. This obviously doesn't save any work if you are only targeting two sizes. How many different sizes do you need to target before the rule-based scaling has a significant advantage over manually tuning the different sizes? Whatever that number, Android will exceed it and Apple probably won't. However, this completely ignores the need for more drastic design changes when the difference in sizes is very big, such as between the iPhone and the iPad.
And such discontinuities in the scaling hardly require that big a disparity: according to AnandTech's review of the Samsung Galaxy Tab (http://www.anandtech.com/show/4062/samsung-galaxy-tab-the-an...) which is a 7" 16:9 tablet, the best way to type on it is in portrait orientation using your thumbs, whereas on the iPad (9.7" 4:3) you are better off using both hands in landscape. On a 10" 16:9 tablet, you have even more width in landscape mode to accommodate typing with both hands, but how is the OS supposed to know that in portrait mode it is still too wide for two-thumb typing?
The only really good scalable UI engine I know of is LaTeX, which outputs completely static content, but can handle a wide range of paper sizes without the author needing to worry about margins, and all the font sizes can be scaled with a single change to the header of the source file. Even so, it doesn't know when the paper size is large enough that you should switch to a two-column format.
It's not just about scalable UI. The Android concept is of fragments. Quoting from the allthingsd interview of Rubin -
"[Fragments] allow apps to split their functionality on varying devices. In other words, the Gmail app on an Android phone will load your inbox on one page, then slide to a new screen to display an email. On an Android tablet, that very same app will display completely differently, loading the inbox in a left-hand pane and using most of the screen real estate for emails. Rubin stressed that Android engineers have thought hard about making sure apps are backwards compatible with phones but still run well on tablets. Rubin started to talk about how fragments will work on Google TV before switching topics--we’re guessing he was simply going to specify that some apps will fragment to take advantage of the TV platform as well."
Android already does flow based layout by default, taking its cue from the web itself. Web apps have been dealing with this problem space for many years, and in some ways have conquered it.
Web apps are definitely the place to start looking for solutions, since they always have resizing forced on them. But very few web apps can handle a lot of resizing (particularly down to phone resolutions) without ending up looking like they're obviously the wrong size. This shouldn't be too much of a problem for apps designed to start at WVGA or smaller, but like most things Web-related, it still completely ignores the touch aspects.
iOS has the concept of "autoresizing", which allows for relatively simple flow-based UI. Could you explain (or link to) Android's implementation of the concept? I'm interested to see how it works.
Obviously, the operating system is not going to be able to produce the same design decisions that would be made in light of actual experimentation with real users - it will be based on heuristics that will produce sub-optimal results for just about any combination of screen size and resolution other than the original. So I'll assume that you merely meant to assert that the scaling will produce results that are "good enough" in that normal users won't notice that the UI doesn't fit their tablet.
Even the claim that it will be "good enough" seems outlandish. Consider the kinds of scalable GUIs that exist on desktops: the important elements of the GUI (like toolbars, menus, and standard buttons) don't get re-sized. At best, they get wrapped or scrolled, either of which is instantly recognizable as a bad design. Most of the sizing flexibility on desktop apps is in the areas that show relatively static content that the user only interacts with passively, like in a web browser or video player, or in the case of many types of games, areas that you only interact with in small bits at a time. (Word processors alternate between the presentation of static content and the interaction (ie. editing) of one spot at a time.)
On a multitouch display with direct manipulation of the GUI, you will typically have far fewer opportunities for the easy scalability that web browsers and word processors enjoy. You have to know which UI elements need to maintain the same physical size, which ones need to maintain the same pixel dimensions, and what the limits are on the scalability of the other elements.
Take as an example the iPad email app. In landscape mode, you have a list of messages on the left (showing subjects, the first line of the body, and a few other pieces of info), and the body of the currently selected message shown on the right. The right pane takes up about 2/3 of the screen width.
If you were to scale this app from the 4:3 iPad display to a 16:9 tablet, how would the left/right split ratio have to change? It's complicated: the entries in the left-side list will have to maintain roughly the same physical height, because they are essentially buttons. You probably want the left pane to remain at least as many characters wide as in the original, so the physical width won't change by much, but you have some flexibility in font sizes. That means that the right pane showing the body of the email will probably be slightly wider and shorter on a 10" 16:9 tablet, but on a significantly smaller tablet, the left/right split might be 50/50.
All that is merely a first approximation of how that one app would have to scale. Could a computer derive that? How will the operating system know what the driving constraints are? The OS certainly can't know whether it is better on average to use the extra width of the 16:9 tablet to show more of the subject lines on the left or more of the body on the right.
It seems that the only way to make a scalable touch UI work is for the designer to bake in the constraint information, which will require testing at different sizes. This obviously doesn't save any work if you are only targeting two sizes. How many different sizes do you need to target before the rule-based scaling has a significant advantage over manually tuning the different sizes? Whatever that number, Android will exceed it and Apple probably won't. However, this completely ignores the need for more drastic design changes when the difference in sizes is very big, such as between the iPhone and the iPad.
And such discontinuities in the scaling hardly require that big a disparity: according to AnandTech's review of the Samsung Galaxy Tab (http://www.anandtech.com/show/4062/samsung-galaxy-tab-the-an...) which is a 7" 16:9 tablet, the best way to type on it is in portrait orientation using your thumbs, whereas on the iPad (9.7" 4:3) you are better off using both hands in landscape. On a 10" 16:9 tablet, you have even more width in landscape mode to accommodate typing with both hands, but how is the OS supposed to know that in portrait mode it is still too wide for two-thumb typing?
The only really good scalable UI engine I know of is LaTeX, which outputs completely static content, but can handle a wide range of paper sizes without the author needing to worry about margins, and all the font sizes can be scaled with a single change to the header of the source file. Even so, it doesn't know when the paper size is large enough that you should switch to a two-column format.