This is a known issue with Honeycomb. Scrolling behaves properly with HW acceleration turned on. A preference has been added to android container to toggle HW acceleration on/off. While turning it on solves this problem, HW acceleration displays a number of other idiosyncrasies.

1) placing a setTimeoutFunction int he delayedResizeHandler makes not difference ....here is what I did
var delayedResizeHandler = function(updates){
ice.log.debug(ice.log, "IN DELAYEDRESIZEHANDLER");
setTimeout(function () {
resizeElementHeight('#

');
ice.log.debug(ice.log, 'resize on update ' + window.innerHeight);
}, 100);
}
2) the delayedResizeHandler just duplicates the effort of the resizedElementHeight(elementId) function. but...it just does it once. This:-
var supportsOrientationChange = "onorientationchange" in window,
orientationEvent = supportsOrientationChange ? "orientationchange" : "resize";
registers a listener for every time the browser window changes (you can make this work on desktop, by opening up firebug and changing the window size of the browser console for example). It fires a lot.
3) mostly was working on browser window without container and noticed that if I initially load mobile showcase, don't do anything except rotate the device, it doesn't resize. If I refresh the page, then it will change dimensions every time I then change the orientation for that view only.....after trying this out several times, I get the xmlParseEntityRef error and have to reboot the server.
When I comment out the delayedResizeHandler function totally, I can't tab through the fields, but I can turn the android tablet and get the proper resize of the screen.
Anyways the resize event is being fired every time the container changes size. So when you have a popupmenu opening, that changes the size of the container and it wants to continually change the size of the container with the Android (this is exactly how the desktop browsers treat this event as well when you change the size of the available browser window by making firebug console bigger...the event is continually firing then as well). The iPad is a little smarter and this event only fires when the actual orientation of the device has changed.
If you JUST want to repaint the screen when an actual orientation change has happened, i think we need to keep variables of the actual page size and when they change by a certain amount (for we can check the width of the screen and ensure it has gone from landscape to portrait or changed by a certain %?), then do the resize. In this way, it won't interfere with the actual behaviour of the panel being used.

this seems to give me the correct return for orientation change:-
var previousOrientation = 0;
var checkOrientation = function(){
if(window.orientation !== previousOrientation){
previousOrientation = window.orientation;
ice.log.debug(ice.log, "WINDOW ORIENTATION HAS CHANGED!!");
alert("orientation has changed!");
resizeElementHeight('#

');
}
};

window.addEventListener("resize", checkOrientation, false);
window.addEventListener("orientationchange", checkOrientation, false);

....the only problem is that it doesn't handle resize (which I don't think should apply to mobile devices, but we should probably have for desktop browsers....can you think of any reason why they should be used for mobile devices???
Anyways, the problem now is that I am not that familiar with composite components and I am only getting one of my scroller panels to change their dimenstion/size (not the menu panel).
Once this is a component and not a composite component, if the mobile devices don't require a resize, we can just write these scripts based on that.

This works on the iPad as well as the android tablet (even though the menu is not being resized properly for the android tablet, I suspect it is my lack of knowledge regarding composite components and that iPad is doing it's own thing) for some reason the android is just wrapping the entire block of code into one panel and resizing it whereas the composite component still has 2 scrolling panels on the iPad (strange!).