Merge commit '9a81736176f507489f262344b6e3d55bbe53be7c'
* commit '9a81736176f507489f262344b6e3d55bbe53be7c':
Add the ability to specify the onClick handler with XML. The new android:onClick attribute defines the name of the method in the Activity to invoke when the button is clicked. The method has to be public and get one View parameter.
Merge commit 'd4ed0496724d9083ce0762d3a5c0b36183c02f6c'
* commit 'd4ed0496724d9083ce0762d3a5c0b36183c02f6c':
AI 148024: fix NPE when there is no history
* Introduced ApplicationScale (may not be good name. CompatibilityScale? CanvasScale? Pls let me know if you have better idea)
* Changes to RootView / SurfaceView
- Makes the app believe it's running in the supported density/resolution.
- Makes the window manager believe it's running at the right density/resolution.
* Added methods to Rect/Event for scaling up/down.
Known issues:
* certain kind of images (such as nine patch for buttons) seesm to be loaded not by app, thus does not take the scale into account,
which, in turn, is causing layout issue.
* ZoomButton in MapView is rendered in wrong place
* Transparent region on Surface is not correct
* Specifying different densities in one process is not working.
BUG=1770627
Automated import of CL 147976
There are three major classes of changes here:
- Avoid writing lines where their values are often empty, false, or some other typical thing.
- Use partial writes to the PrintWriter to avoid creating temporary strings.
- Use StringBuilder where we need to generate real String objects (and where possible cache the result).
#1748954 (New status bar fades into all white background): FrameLayout wasn't updating its foreground drawable when its padding changed, which would happen as the status bar is shown and hidden. To fix this I also ended up fixing a problem in the view debug stuff where we couldn't get a bitmap for a view that is the full screen size because it is too big... actually I just went ahead and added another function to snapshot the view hierarchy which works a lot better for us anyway.
#1737952 (Home screen icons overlap with the notification bar after exiting any camera app): Originally I punted this because it only happened in rare situations, but now that home is always portrait it happens a lot more so it is more important to fix. This involved a few things to clean up hiding/showing the status bar:
- We now determine when to hide and show it during layout, which allows us to do this at the time it is actually needed rather than during animation after we can actually catch it for the initial display of a window. This required tweaking the layout API so the policy can request a second layout pass if needed.
- When doing layout, we are now much more aggressive about skipping the layout of windows. Basically anything that we know will be hidden in the near future is ignored for layout, so that it doesn't glitch as it is transfered out of the screen. The theory being that it is better to leave it as it was originally placed while we are transitioning it out, than to switch it to something slightly more correct.
Original author: hackbod
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143901
#1748954 (New status bar fades into all white background): FrameLayout wasn't updating its foreground drawable when its padding changed, which would happen as the status bar is shown and hidden. To fix this I also ended up fixing a problem in the view debug stuff where we couldn't get a bitmap for a view that is the full screen size because it is too big... actually I just went ahead and added another function to snapshot the view hierarchy which works a lot better for us anyway.
#1737952 (Home screen icons overlap with the notification bar after exiting any camera app): Originally I punted this because it only happened in rare situations, but now that home is always portrait it happens a lot more so it is more important to fix. This involved a few things to clean up hiding/showing the status bar:
- We now determine when to hide and show it during layout, which allows us to do this at the time it is actually needed rather than during animation after we can actually catch it for the initial display of a window. This required tweaking the layout API so the policy can request a second layout pass if needed.
- When doing layout, we are now much more aggressive about skipping the layout of windows. Basically anything that we know will be hidden in the near future is ignored for layout, so that it doesn't glitch as it is transfered out of the screen. The theory being that it is better to leave it as it was originally placed while we are transitioning it out, than to switch it to something slightly more correct.
Original author: hackbod
Merged from: //branches/cupcake/...
Automated import of CL 143899
Also do most of the work for issue #1732012 (Only show screen rotation animation when triggered by sensor). This just needs to be hooked up to the surface flinger API when that appears.
Original author: hackbod
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143318
Define orientation limits for various cases.
Values between 235 and 295 are considered landscape,
0 - 60 are considered portrait.
0-235 are ignored since we don't support Surfaces for 180 and 270 yet.
A linear threshold value is calculated for values between 265 and 355 to switch between landscape and portrait.(different for both cases)
Based on current mode we not only calculate the threshold but also compare accordingly based on increasing or decreasing orientation
BUG = 1734325
Original author: asuchitra
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143311
Also do most of the work for issue #1732012 (Only show screen rotation animation when triggered by sensor). This just needs to be hooked up to the surface flinger API when that appears.
Original author: hackbod
Merged from: //branches/cupcake/...
Automated import of CL 143169
Define orientation limits for various cases.
Values between 235 and 295 are considered landscape,
0 - 60 are considered portrait.
0-235 are ignored since we don't support Surfaces for 180 and 270 yet.
A linear threshold value is calculated for values between 265 and 355 to switch between landscape and portrait.(different for both cases)
Based on current mode we not only calculate the threshold but also compare accordingly based on increasing or decreasing orientation
BUG = 1734325
Original author: asuchitra
Merged from: //branches/cupcake/...
Automated import of CL 143162
The reason for that bug was that the marquee could potentially be stopped/started as part of the layout workflow. Unfortunately TextView was relying on setFrame() being called after onMeasure() which is *not* always the case, especially when the widget is inside of a ListView. This change simply checks for the marquee restart flag in on the onDraw() method in case we skipped the setFrame() step.
Original author: romainguy
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143240
