| f0681b34dffc1510cbd9c3da5c3a7e695553fa8d |
|
24-Oct-2012 |
Jeff Brown <jeffbrown@google.com> |
Secure windows, secure surface views and secure displays.
Add new API to determine whether a display is secure.
Add new API to make a SurfaceView secure.
Clarify documentation.
Bug: 7368436
Change-Id: I7068c34c910e43b4bc72e43fa0dded59a25f0fe2
/frameworks/base/core/java/android/view/WindowManager.java
|
| 6018aeec27914f138f36b00d8f00136a87562fd3 |
|
23-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Add throwing InvalidDisplayException from addView.
Throw an InvalidDisplayException to addView if the display being
added to has been removed. Handle this exception in Dialog.show()
by removing the view after it has been added and rethrow the
exception from there.
Add javadoc to ViewManager.addView and Presentation.show explaining
the new exception and how best to handle it.
Bug: 7368565 partially fixed. It remains for the Videos app to
handle Presentation.show throwing the InvalidDisplayException.
Change-Id: Ib4303c9b3f7bf7a0cfa95d19bd60a0c128658c48
/frameworks/base/core/java/android/view/WindowManager.java
|
| 5962b12bedc4a1d0354816c1cd6b06ba04f6d807 |
|
05-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Adds showWhenLocked attribute to Activities.
The new attribute allows an Activity such as the alarm to appear
on all users screens.
Bug: 7213805 fixed.
Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
/frameworks/base/core/java/android/view/WindowManager.java
|
| 88400d3a31139c40c4014faf86c243647087ef6c |
|
30-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Add flag for displaying non-user's Windows to user.
Created a new flag that indicates that a window should be shown
to all users. For the flag to be valid the owner of the window
must have system permissions.
Also separated system window types into those that show to all
users (e.g. StatusBar, Keyguard, ....) and those that appear only
to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear
only to their owner can override their default behavior using
the new flag (e.g. LowBattery).
Fixes bug 7211965.
Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
/frameworks/base/core/java/android/view/WindowManager.java
|
| 1e3b98d47df596d0c4eadbdf60143709f8465b28 |
|
01-Oct-2012 |
Jeff Brown <jeffbrown@google.com> |
New internal API to eliminate poke locks.
Added a new WindowManager.LayoutParams inputFeatures flag
to disable automatic user activity behavior when an input
event is sent to a window.
Added a new WindowManager.LayoutParams field userActivityTimeout.
Bug: 7165399
Change-Id: I204eafa37ef26aacc2c52a1ba1ecce1eebb0e0d9
/frameworks/base/core/java/android/view/WindowManager.java
|
| 1cf70bbf96930662cab0e699d70b62865766ff52 |
|
06-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Screen magnification - feature - framework.
This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.
Interaction model:
1. Triple tap toggles permanent screen magnification which is magnifying
the area around the location of the triple tap. One can think of the
location of the triple tap as the center of the magnified viewport.
For example, a triple tap when not magnified would magnify the screen
and leave it in a magnified state. A triple tapping when magnified would
clear magnification and leave the screen in a not magnified state.
2. Triple tap and hold would magnify the screen if not magnified and enable
viewport dragging mode until the finger goes up. One can think of this
mode as a way to move the magnified viewport since the area around the
moving finger will be magnified to fit the screen. For example, if the
screen was not magnified and the user triple taps and holds the screen
would magnify and the viewport will follow the user's finger. When the
finger goes up the screen will clear zoom out. If the same user interaction
is performed when the screen is magnified, the viewport movement will
be the same but when the finger goes up the screen will stay magnified.
In other words, the initial magnified state is sticky.
3. Pinching with any number of additional fingers when viewport dragging
is enabled, i.e. the user triple tapped and holds, would adjust the
magnification scale which will become the current default magnification
scale. The next time the user magnifies the same magnification scale
would be used.
4. When in a permanent magnified state the user can use two or more fingers
to pan the viewport. Note that in this mode the content is panned as
opposed to the viewport dragging mode in which the viewport is moved.
5. When in a permanent magnified state the user can use three or more
fingers to change the magnification scale which will become the current
default magnification scale. The next time the user magnifies the same
magnification scale would be used.
6. The magnification scale will be persisted in settings and in the cloud.
Note: Since two fingers are used to pan the content in a permanently magnified
state no other two finger gestures in touch exploration or applications
will work unless the uses zooms out to normal state where all gestures
works as expected. This is an intentional tradeoff to allow efficient
panning since in a permanently magnified state this would be the dominant
action to be performed.
Design:
1. The window manager exposes APIs for setting accessibility transformation
which is a scale and offsets for X and Y axis. The window manager queries
the window policy for which windows will not be magnified. For example,
the IME windows and the navigation bar are not magnified including windows
that are attached to them.
2. The accessibility features such a screen magnification and touch
exploration are now impemented as a sequence of transformations on the
event stream. The accessibility manager service may request each
of these features or both. The behavior of the features is not changed
based on the fact that another one is enabled.
3. The screen magnifier keeps a viewport of the content that is magnified
which is surrounded by a glow in a magnified state. Interactions outside
of the viewport are delegated directly to the application without
interpretation. For example, a triple tap on the letter 'a' of the IME
would type three letters instead of toggling magnified state. The viewport
is updated on screen rotation and on window transitions. For example,
when the IME pops up the viewport shrinks.
4. The glow around the viewport is implemented as a special type of window
that does not take input focus, cannot be touched, is laid out in the
screen coordiates with width and height matching these of the screen.
When the magnified region changes the root view of the window draws the
hightlight but the size of the window does not change - unless a rotation
happens. All changes in the viewport size or showing or hiding it are
animated.
5. The viewport is encapsulated in a class that knows how to show,
hide, and resize the viewport - potentially animating that.
This class uses the new animation framework for animations.
6. The magnification is handled by a magnification controller that
keeps track of the current trnasformation to be applied to the screen
content and the desired such. If these two are not the same it is
responsibility of the magnification controller to reconcile them by
potentially animating the transition from one to the other.
7. A dipslay content observer wathces for winodw transitions, screen
rotations, and when a rectange on the screen has been reqeusted. This
class is responsible for handling interesting state changes such
as changing the viewport bounds on IME pop up or screen rotation,
panning the content to make a requested rectangle visible on the
screen, etc.
8. To implement viewport updates the window manger was updated with APIs
to watch for window transitions and when a rectangle has been requested
on the screen. These APIs are protected by a signature level permission.
Also a parcelable and poolable window info class has been added with
APIs for getting the window info given the window token. This enables
getting some useful information about a window. There APIs are also
signature protected.
bug:6795382
Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
/frameworks/base/core/java/android/view/WindowManager.java
|
| a492c3a7b2c18426fd0cb4d017eacbc368195dc5 |
|
24-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Initial draft of high-level multi-display APIs.
This patch introduces the ability to create a Context that
is bound to a Display. The context gets its configuration and
metrics from that display and is able to provide a WindowManager
that is bound to the display.
To make it easier to use, we also add a new kind of Dialog
called a Presentation. Presentation takes care of setting
up the context as needed and watches for significant changes
in the display configuration. If the display is removed,
then the presentation simply dismisses itself.
Change-Id: Idc54b4ec84b1ff91505cfb78910cf8cd09696d7d
/frameworks/base/core/java/android/view/WindowManager.java
|
| 29d8d267dd97f66d829478778de5e0c56b965a47 |
|
30-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix build for some javac compilers.
It seems some compiler versions don't like trailing
commas in attribute lists. Weird.
Change-Id: I3a05f49a2e94f63fe1662d14c1d8a7ee249d8a16
/frameworks/base/core/java/android/view/WindowManager.java
|
| bd6e1500aedc5461e832f69e76341bff0e55fa2b |
|
28-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Add initial multi-display support.
Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.
Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.
Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.
Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.
At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.
Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.
Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.
Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
/frameworks/base/core/java/android/view/WindowManager.java
|
| d32460c5b7bea7b06e345397fdbaca58d9732dcf |
|
21-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor local window manager implementation.
The objective of this refactoring is to remove the reliance on
WindowManager wrapper objects for compatibility mode and for
managing sub-windows.
Removed the WindowManager.isHardwareAccelerated() method since
it is never used.
Change-Id: I4840a6353121859a5e0c07d5cc307a437c595d63
/frameworks/base/core/java/android/view/WindowManager.java
|
| 3cc321ecf505d87850740ad3c63849e6793a8ef6 |
|
17-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove dithering support.
The dithering flag is no longer implemented in Surface Flinger
so this is all dead code.
Change-Id: I74c0e452923207e5b7cfe0eeca9457e5cb990947
/frameworks/base/core/java/android/view/WindowManager.java
|
| a4b7f2f75e7803193429ec1179fb5e2eb1c6fbda |
|
21-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Use two fingers to work some magic...
Change-Id: Ibcb3dbd3d158c22da8277e544d81fb47eadccd49
/frameworks/base/core/java/android/view/WindowManager.java
|
| aeb7723a123dc09dc4ada55393a6c68858f45b3b |
|
01-Jun-2012 |
Scott Anderson <saa@android.com> |
Clean up IntToStrings for window TYPE_*
Remove duplicates and add missing entries for the conversions
from window types to strings.
Change-Id: I4378e1191b156bd0b73ac23bc43bc3bfd1c3f198
Signed-off-by: Scott Anderson <saa@android.com>
/frameworks/base/core/java/android/view/WindowManager.java
|
| bf08af3323117e15a65b74e66b7499d31537f9e1 |
|
17-May-2012 |
Craig Mautner <cmautner@google.com> |
Eliminate deferred surface destruction.
Removing the code that delays a surface destruction when
WindowManager.FLAG_KEEP_SURFACE_WHILE_ANIMATING is set. The lock
screen that continued to animate after destroySurfaceLocked is no
longer used and this code was causing problems.
Also mDrawState was being set to NO_SURFACE in destroySurfaceLocked
even if the surface ended up not being destroyed. Later when it was
reused the false value of mDrawState was messing things up.
The screen lock bug referenced below no longer levaes the user stuck
with a black lockscreen. However it occasionally powers back up in the
launcher screen rather than the lock screen.
Fixes bug 6485955.
Change-Id: I684104c7e7c39c161a5118aa890889fbae92e635
/frameworks/base/core/java/android/view/WindowManager.java
|
| e898ac59db04d8ab0762180ca8ec7cea1347aa09 |
|
07-Apr-2012 |
Jim Miller <jaggies@google.com> |
Fix 6299832: Add search target swipe action to navigation bar on phones
This adds a feature to swipe upward on the navigation bar to invoke
voice search on phones.
Change-Id: I462076fd43b1c66c5bf624f00b297c6d3414a19a
/frameworks/base/core/java/android/view/WindowManager.java
|
| 7d276c377ce0c56630c06a6da431a6cb9bd76d1e |
|
30-Jan-2012 |
Daniel Sandler <dsandler@android.com> |
New Android Dreams architecture, disabled for now.
Rather than normal Activities (which have a host of problems
when used for this purpose), screen savers are now a
special kind of Service that can add views to its own
special window (TYPE_DREAM, in the SCREENSAVER layer).
Dreams are now launched by the power manager; whenever it is
about to turn the screen off, it asks the window manager if
it wants to run a screen saver instead. (http://b/5677408)
Also, the new config_enableDreams bool allows the entire
feature to be switched on or off in one place. It is
currently switched off (and the APIs are all @hidden).
Change-Id: Idfe9d430568471d15f4b463cb70586a899a331f7
/frameworks/base/core/java/android/view/WindowManager.java
|
| f76a50ce8fdc6aea22cabc77b2977a1a15a79630 |
|
09-Mar-2012 |
Ken Wakasa <kwakasa@google.com> |
Fix obvious typos under frameworks/base/core
Change-Id: Ia5fc3db1bb51824e7523885553be926bcc42d736
/frameworks/base/core/java/android/view/WindowManager.java
|
| 73ab6a49db2b834ce1d56c7a1164938b409ee6fc |
|
13-Dec-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5755172: Soft menu key disappears when menu is open
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
/frameworks/base/core/java/android/view/WindowManager.java
|
| a8e5a2bcd6a0d35893187c6df42425c03be005da |
|
28-Oct-2011 |
Chet Haase <chet@google.com> |
Optimize handling of scrolled wallpapers
Swiping the home screen causes the WindowManagerService to do
a bunch of work to keep the wallpapers in sync. First, it lays out
and places all windows. Also, it notifies the SystemUI process that
the wallpaper position has changed.
The layout/place operation is too much work - we only need to set
the position values for the wallpaper, not relayout the whole system.
The notification mechanism must exist, but should be optional. Most
wallpapers don't care (especially static ImageWallpapers). So we'll
give them a new API (WallpaperService.Engine.setWantsOffsets()) to
allow wallpapers to opt out of this process and avoid the performance
overhead.
Change-Id: I66c38375438937f14f6f5550565b28eb204b1e06
/frameworks/base/core/java/android/view/WindowManager.java
|
| df89e65bf0fcc651d20b208c8d8d0b848fb43418 |
|
07-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix how we hide and show the nav bar.
The PhoneWindowManager is now responsible for hiding and showing
the nav bar.
For hiding, it just moves it off the screen (easy way to get a
nice slide animation on and off). At the same time, we use a
new WM facility to put up a fake input window to capture all
touch events.
When a touch event is received, we force the system UI to clear
the navigation hiding bit so it will be shown again.
This removes a bunch of code from the system UI for hiding and
showing the nav bar. Also removes the code calling from userActivity()
to the system UI, which was bad. (Also no longer using userActivity()
fixes bugs around re-showing the nav bar due to key presses and
other wrong things.)
Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
/frameworks/base/core/java/android/view/WindowManager.java
|
| 40e0383dce630ed9b2b1aa0e497709b89dfab6ef |
|
06-Oct-2011 |
Chet Haase <chet@google.com> |
Fix issue #5384631: hw windows not resizing correctly
When the SystemUi becomes visible, the activity window resizes.
The hardware renderer was not begin resized to suit, so it was drawing
to a surface larger than that of the activity window, and some of the
rendering (like the action bar) appeared off the screen.
The fix is to keep track of the surface size in HardwareRenderer and to
recreate the surface when the size changes.
This change also removes the BUFFER_CHANGE flag from WindowManager.LayoutParams.
The only reason the flag existed was to trigger a hardware surface recreation,
but checking the old/new size is a more direct way of handling this.
Change-Id: I9d6bf6385794886d1d93c60609c170864cdcdfab
/frameworks/base/core/java/android/view/WindowManager.java
|
| bfcb60ab0f696c8ef70830c365550e62fe2808bf |
|
09-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Adjust layers for system overlays.
Prevent system overlays from showing above the notification bar.
Allow secure system overlays to be fullscreen, for the pointer
location view.
Show the drag layer above the notification bar.
Change-Id: Ic8d663792a243cca2cd9952d241d001e0357d551
/frameworks/base/core/java/android/view/WindowManager.java
|
| f21c9b0f52d5a1de5050f90f0818467fad014eaa |
|
07-Sep-2011 |
Romain Guy <romainguy@google.com> |
Don't destroy a window's buffers when moving it
Change-Id: Ib08608373ae4299639c1b157421ba633e4293446
/frameworks/base/core/java/android/view/WindowManager.java
|
| 5d927c2d8e832fcfcb0154c8741f896001141ef4 |
|
02-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5150899: Call activity takes 15MB we never get back.
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
/frameworks/base/core/java/android/view/WindowManager.java
|
| cc4f7db698f88b633a286d8ab1105b28a474cd09 |
|
31-Aug-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix input channel leak.
Bug: 5156144
Input channels could leak or simply live longer than they should
in some cases.
1. Monitor channels (used by the pointer location overlay) are never
unregistered, so they would leak.
Added code to handle failures in the receive callback by closing
the input channel.
2. The DragState held onto its input window and application handles
even after the input channel was disposed.
Added code to null these handles out when they are no longer needed.
3. Input channels previously used as input event targets would stick
around until the targets were cleared (usually on the next
event).
Added code to detect when the input dispatcher is in
an idle state and to proactively clear the targets then
to ensure that resources are released promptly.
4. Native input window handles held onto the input channel even
after the input window was removed from the input dispatcher.
Consequently, the input channel would not be disposed until
the input window handle itself was freed. Since the input
window handle is held from managed code, this meant that the
window's input channel could stick around until the next GC.
Refactored the input window handle to separate the properties
(info) and identify (handle) state into different objects.
Then modified the dispatcher to release the properties (info)
when no longer needed, including the input channel.
7. The pointer location overlay does not actually use its
standard input channel, only the monitor input channel.
Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to
request that they not be provided with an input channel
at all.
Improved some of the error handling logic to emit the status
code as part of the exception message.
Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
/frameworks/base/core/java/android/view/WindowManager.java
|
| 29aae6f36e565b8f2a99f2193597b964bb800ee8 |
|
19-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4279860: previous UI flashes before showing lock screen...
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
/frameworks/base/core/java/android/view/WindowManager.java
|
| a44abeb125a0c8a8e5a065f868d316e41354286a |
|
09-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve window manager debug output.
Cleaned this up while I was debugging another issue.
Change-Id: I0663b9ed581c6868b59655a0f994d870971ec1a6
/frameworks/base/core/java/android/view/WindowManager.java
|
| e8ecde10b33b1d050d2b63b3f4cd20e8bb7c96d4 |
|
04-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Whoops also need to move notification shade above lock screen.
And this requires making a new layer for the volume toast.
Change-Id: I4f272d56c87cf3b6bf886774b0fb02e610ab9164
/frameworks/base/core/java/android/view/WindowManager.java
|
| 474dcb5c3ddff737c4ac9fc44a1f7be569605e5f |
|
15-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Add support for disabling pointer gestures.
Made it possible for individual windows to disable pointer gestures
while the window has focus using a private API.
Cleaned up the InputReader configuration code to enable in-place
reconfiguration of input devices without having to reopen them all.
This change makes changing the pointer speed somewhat nicer since the
pointer doesn't jump back to the origin after each change.
Change-Id: I9727419c2f4cb39e16acb4b15fd7fd84526b1239
/frameworks/base/core/java/android/view/WindowManager.java
|
| 98db5fabdad86dca379740d8050697950b9f026c |
|
09-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Allow touches to slide out of the navigation bar.
Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
/frameworks/base/core/java/android/view/WindowManager.java
|
| 9e3b002d3f9141d54948a65e0330fdcd09e75a30 |
|
07-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Rename Gravity BEFORE/AFTER to START/END
- following spec proposal for having CSS3 like naming
Change-Id: Id5e316a2d9b54b9f20bbcb168fea6a3a83882e1b
/frameworks/base/core/java/android/view/WindowManager.java
|
| 6a03640539405afbdefe72894759281b98aa6e6f |
|
23-May-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Add support for Gravity BEFORE and AFTER
- update layouts
- add Callback2 for RTL aware Drawable
- add unit tests
Change-Id: Ic64d0291e262170aff7297c6580b0b422eaa8d89
/frameworks/base/core/java/android/view/WindowManager.java
|
| 8956dbbc5f292d8b79072ae73b25f2114c8c7479 |
|
22-Apr-2011 |
Daniel Sandler <dsandler@android.com> |
On-screen navigation bar (separate from the status bar).
In Honeycomb we introduced navigation controls in the status
bar, for xlarge devices without physical buttons. What about
phones? The status bar is pretty cramped already, and
besides, it's at the top of the display most of the time,
not at the bottom where your thumb is likely to be.
Enter the navigation bar. It's a new window type that
appears atop almost everything (including the keyguard); the
window manager subtracts its rectangle from the default
visible rectangle of other windows (including the status bar
and notification shade).
However, it behaves (on phones) like the status bar in that
applications that request fullscreen windows can get access
to those pixels. Well, almost; they need cooperation from
the navigation bar implementation to make the navbar
disappear, just like the status bar.
The current SystemUI implementation of the navigation bar on
phones is still rough, but it has the basics:
+ back, home, and menu keys (NB: we're showing menu all the
time right now because checking the api level of the
package owning the top window is currently a poor
indicator of whether the app requires the menu key)
+ it tries to stick to the same physical end of the device,
regardless of device orientation (on a phone, this is
the strip of land closest to the microphone)
Change-Id: Ic613a3351220af0bbfbdef63e1d99cbefd5ed1c2
/frameworks/base/core/java/android/view/WindowManager.java
|
| 3fa8a454f61c772036f5f38661d1a077fd3d8388 |
|
10-Mar-2011 |
Jim Miller <jaggies@google.com> |
Fix 3201849: Enable hardware acceleration in LockScreen WaveView
Change-Id: Id64e82fe2e09ac231736d7867cd47b504d79b81b
/frameworks/base/core/java/android/view/WindowManager.java
|
| d6f5bde96b2fe82bc7e5d4e64266d585108c4648 |
|
20-Jan-2011 |
Glenn Kasten <gkasten@google.com> |
Protected surface API
To be used by DRM framework, implemented by display HAL
Change-Id: I054a07a94f4d5dbe792f3a597e2e49a100d90eb2
/frameworks/base/core/java/android/view/WindowManager.java
|
| a4a5ec5e748f99c40301c9c422b3d36cb44c6081 |
|
26-Jan-2011 |
Joe Onorato <joeo@google.com> |
am 1aadb210: Merge changes I48392c75,Id09437a4,I4a0aa878 into honeycomb
* commit '1aadb2108d7614d9d1ff61b41c6c31cb8d211ab9':
Expose the window flags for lights out mode.
Make TabletStatusBar call into StatusBarManagerService when it goes out of lights out mode on its own.
Make FLAG_FULLSCREEN not go into lights out mode anymore.
|
| 14782f705e94d4e563a48efc85fd25129fd38a7d |
|
26-Jan-2011 |
Joe Onorato <joeo@google.com> |
Expose the window flags for lights out mode.
I hadn't wanted to do this, but it makes porting the FLAG_FULLSCREEN
stuff over to this simpler because you don't have to go find a view
to proxy through.
This change also clears the flag everywhere when the window manager
notifies the views that the change has come back.
Change-Id: I48392c7550925bcca50c5bb9e1f263e99de6c7bc
/frameworks/base/core/java/android/view/WindowManager.java
|
| faf083ef0b7b893acb871084231d20e08e208f8f |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
am 4c541b13: Merge "visibility ("lights out") API." into honeycomb
* commit '4c541b1303b0ee2b9b0d19bee85d3780c5c4c110':
visibility ("lights out") API.
|
| 664644d9e012aa2a28ac96f305b1ce6499ec8806 |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
visibility ("lights out") API.
1. Views may setSystemUiVisibility() to recommend that
the system chrome (status bar or other UI) show or hide
itself. (This functionality was previously available only
via the FLAG_FULLSCREEN window flag for some SystemUI
implementations.)
2. Views may register a OnSystemUiVisibilityChangedListener
on a view, and find out when the system UI actually
appears or disappears, allowing apps to coordinate the
appearance of their own UI if desired.
Bug: 3241144
Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
/frameworks/base/core/java/android/view/WindowManager.java
|
| 8a82de2fcae11a2a9cba25132c37cad83ccc859f |
|
21-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
am 4bb180d6: am ded2b006: Merge "frameworks/base: remove redundant code in WindowManager"
* commit '4bb180d62f71658d04a7d6800707de83c10b01a5':
frameworks/base: remove redundant code in WindowManager
|
| be2c4f92a990ca48ad6ede252343dd9574dfe505 |
|
18-Jan-2011 |
Gilles Debunne <debunne@google.com> |
Race condition patched in Email autocompletion.
Bug 3347962
Root cause of this problem: if the adapter's content gets updated by a backgroung
thread, the PopupDataSetObserver will call showDropDown which will popup the
list.
Added a flag to make this call show the popup iif it is already visible.
This relayout is needed to clear the mDataChanged flag set when the content was
modified and which otherwise prevents touch events on the result list.
ArrayAdapter didn't use its lock to protect access to mObject.
-------------------------------------------------
However, the study of the this race conditions revealed an other bug:
Updated adapter's content is not displayed in filtered AutoCompleteTextView
Bug 3369097
Change-Id: Icd90d452f98231866f4d8a1f6994c1492febecb9
/frameworks/base/core/java/android/view/WindowManager.java
|
| 3f6875f143fbaf4de993025f6765dc8237eb2b0b |
|
18-Jan-2011 |
Vairavan Srinivasan <vairav@codeaurora.org> |
frameworks/base: remove redundant code in WindowManager
Change-Id: I8a356ca36129645977d33129e0d56c1b89f97fb0
/frameworks/base/core/java/android/view/WindowManager.java
|
| 72f0a276ffd5f3d6513400e50de1a8bda547bed4 |
|
10-Jan-2011 |
Romain Guy <romainguy@google.com> |
Better documentation for FLAG_HARDWARE_ACCELERATED
Bug #3154883
Change-Id: I2062781ba3b447b8ec4e0836b9ddeaa97c7aa60e
/frameworks/base/core/java/android/view/WindowManager.java
|
| 83c09685f2e62bc3cf7e71bc61d903f4b9ccaeb4 |
|
24-Dec-2010 |
Jeff Brown <jeffbrown@google.com> |
Add initial support for cursor-based pointing devices.
Some parts stubbed out but you can plug in a mouse and move
a green cursor around to interact with the UI.
Change-Id: I80d597a7f11d3bd92041890f74b3c77326975e6e
/frameworks/base/core/java/android/view/WindowManager.java
|
| d2112306330ce0c162bee4b864991962ca2b655a |
|
08-Dec-2010 |
Mathias Agopian <mathias@google.com> |
remove support for PUSH_BUFFER surfaces and overlays
the same functionality is now supported through
the h/w composer HAL, and YUV support in the GPU.
Change-Id: I8146605449954b8e8fd7f78810b7d873c2d8f5bf
/frameworks/base/core/java/android/view/WindowManager.java
|
| a89e903fd4b84778e1a7f2268fe025fe66a6e45e |
|
24-Nov-2010 |
Joe Onorato <joeo@google.com> |
this should be @hidden
Change-Id: Ib372fa15a5284b30e2edef5a1d90544eb2166ee4
/frameworks/base/core/java/android/view/WindowManager.java
|
| 29fc2c9705e1bb8ae098fca016032d2325031587 |
|
24-Nov-2010 |
Joe Onorato <joeo@google.com> |
Allow status bar panels to be on top of the status bar.
Change-Id: I3c74ece5f7042e6302717f4263746d59d5447ec9
/frameworks/base/core/java/android/view/WindowManager.java
|
| 8e11ef0d949a52fec15359ec35557b2e773b093d |
|
19-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Some work on issue #3201795: Improve transition when keyboard comes up
Now try to slide dialogs if they end up moving due to the IME (or
other system things) showing/hiding. Pretty hackish, but seems to
work.
Change-Id: Icd297e941cf847fa920c9605145c46be63043d52
/frameworks/base/core/java/android/view/WindowManager.java
|
| d9b3b7e8e1d8c919c3e5f5851daa80a2651ea7d1 |
|
17-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3202866: system server crash
Change-Id: Ied92164bea70f6cb8afe2c1c6ff4fc3836a209ab
/frameworks/base/core/java/android/view/WindowManager.java
|
| 7eec10e6c99c30d5ee061fec08ac89ad4254ac32 |
|
13-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Get rid of the extended themes.
We now decide whether to use a bitmap background based on whether the
window's drawing is hardware accelerated. To do this, there is a new
"state_accelerated" that state list drawables can be parameterized on,
and the standard window background uses this to select a solid color
or bitmap drawable as appropriate.
Introduces a little hackery to have wm preview windows pretend like
they are hardware accelerated even if they aren't, so the preview looks
closer to the actual app.
Also Add a DialogWhenLarge variation for the light theme.
Change-Id: I215a79d5df65ba3eed52ab363cade9d8218a6588
/frameworks/base/core/java/android/view/WindowManager.java
|
| 8eb2e244f9b14d946ee587d0b673b866865026c0 |
|
01-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Various PreferenceActivity and related improvement.
This is all about making the preferences implementation better.
Well, mostly all about that.
Change-Id: I8efa98cb5680f3ccfa3ed694a1586de3fb3a9e11
/frameworks/base/core/java/android/view/WindowManager.java
|
| dea3ef7967228f0ddcc03f2455a4f1254758e584 |
|
28-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Add new resize mode to not resize, new web input types.
Change-Id: Ib098c03793d08532c3c099b59d0cc6b567e54900
/frameworks/base/core/java/android/view/WindowManager.java
|
| 3b2b354ec1ba070eae13391d004d97a3e1403050 |
|
15-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for secure system overlays.
Manual merge from Gingerbread.
This change adds a new window type for secure system overlays
created by the system itself from non-secure system overlays that
might be created by applications that have the system alert permission.
Secure views ignore the presence of secure system overlays.
Bug: 3098519
Change-Id: Id876736fd8bf332ff9a5428bde59f5268aa49c3a
/frameworks/base/core/java/android/view/WindowManager.java
|
| 2d3f159aa9622e05a18e7f93cecd57ad673955ae |
|
15-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for secure system overlays. (DO NOT MERGE)
This change adds a new window type for secure system overlays
created by the system itself from non-secure system overlays that
might be created by applications that have the system alert permission.
Secure views ignore the presence of secure system overlays.
Bug: 3098519
Change-Id: I8f8398f4fdeb0469e5d71124c21bedf121bd8c07
/frameworks/base/core/java/android/view/WindowManager.java
|
| e02d808abf370965c3c4e4d38af11bc69110fde2 |
|
08-Oct-2010 |
Daniel Sandler <dsandler@google.com> |
Dynamically show the menu button on the system bar.
Windows with FLAG_NEEDS_MENU_KEY (or windowNeedsMenuKey=true
in their theme) will cause the system bar to show a menu
icon. (Note that the phone's status bar currently ignores
this, but phones tend to have hardware menu keys anyway.)
Additionally, all windows whose package's SDK version is
pre-Honeycomb will have FLAG_NEEDS_MENU_KEY set by default.
Bug: 3003728
Change-Id: I2d983763a726ea4f32cd1af9b0390e30478b11d1
/frameworks/base/core/java/android/view/WindowManager.java
|
| a53146c5569f8ff5f7eb55e9ad35d23ddacf2add |
|
07-Sep-2010 |
Christopher Tate <ctate@google.com> |
Drag/drop APIs and infrastructure
A View initiates a drag-and-drop operation (hereafter just called a "drag")
by calling its startDrag(ClipData) method. Within the processing of that
call, two callbacks are made into the originating View. The first is to
onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this
callback must respond by calling setDragThumbnailDimension(width, height) to
declare the size of the drag thumbnail image that should be used. Following
this, the View's onDrawDragThumbnail(canvas) method will be invoked to
actually produce the bits of the thumbnail image.
If all goes well, startDrag() will return 'true', and the drag is off and
running. (The other arguments to startDrag() provide reconciliation between
the current finger position and where the thumbnail should be placed on
the screen relative to it.)
Potential receipients of the ClipData behind the drag are notified by a
new dispatch mechanism, roughly parallel to motion event dispatch. The core
routine is the View's onDragEvent(event) callback, with the mechanics of
dispatch itself being routed through dispatchDragEvent(event) -- as in
the case of motion events, the dispatch logic is in ViewGroup, with leaf
View objects not needing to consider the dispatch flow.
Several different event 'actions' are delivered through this dispatch
mechanism:
ACTION_DRAG_STARTED: this event is propagated to every View in every window
(including windows created during the course of a drag). It serves as a
global notification that a drag has started with a payload whose matching
ClipDescription is supplied with the event. A View that is prepared to
consume the data described in this event should return 'true' from their
onDragEvent() method, and ideally will also make some visible on-screen
indication that they are a potential target of the drop.
ACTION_DRAG_ENTERED: this event is sent once when the drag point
enters the View's bounds. It is an opportunity for the View to set up
feedback that they are the one who will see the drop if the finger goes
up now.
ACTION_DRAG_LOCATION: when the drag point is over a given View, that
View will receive a stream of DRAG_LOCATION events, providing an
opportunity for the View to show visual feedback tied to the drag point.
ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point
leaves the View's bounds. The View should undo any visuals meant to
emphasize their being the hovered-over target.
ACTION_DROP: when the drag ends at a given point, the View under that
point is sent this event, with the full ClipData of the payload.
ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global
broadcast that the drag has ended and all Views should return to their
normal visual state. This happens after the DROP event.
Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
/frameworks/base/core/java/android/view/WindowManager.java
|
| 464fb74e28b6d76d5e741abcdbb714eea2d9b4d1 |
|
27-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
am 9785bf0f: am 14a288da: Merge "Add suuport for splitting touch events across windows." into gingerbread
Merge commit '9785bf0f2b6b8758aed7ded3b996a2ef0be89919'
* commit '9785bf0f2b6b8758aed7ded3b996a2ef0be89919':
Add suuport for splitting touch events across windows.
|
| 01ce2e9eee41cc0c24b0d16465710a28ea337d5d |
|
27-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
Add suuport for splitting touch events across windows.
This feature is currently used to enable dragging the start and end
selection handles of a TextView at the same time. Could be used for
other things later.
Deleted some dead code in ArrowKeyMovementMethod and CursorControllers.
Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
/frameworks/base/core/java/android/view/WindowManager.java
|
| 529b60a3b16ac3dff24f2403d760ab8ebc9670ff |
|
04-Aug-2010 |
Romain Guy <romainguy@google.com> |
Add android:hardwareAccelerated to Activity.
Hardware acceleration can now be enabled/disabled locally on each activity
declared in the manifest. It can also be enabled/disabled directly on a
window through the WindowManager.LayoutParams.
Change-Id: I91dd0b26c4e7eb8cd7288e523ed6b7bda6d0990b
/frameworks/base/core/java/android/view/WindowManager.java
|
| 613dde4aa651e11dac3db859723cc6faf8fc0a82 |
|
21-Jun-2010 |
Daniel Sandler <dsandler@android.com> |
Revised "immersive mode" API.
No longer a window bit, FLAG_IMMERSIVE is now set on
ActivityInfo.flags and in the Activity's manifest as
android:immersive="true" (ActivityInfo).
[An "immersive" activity is one that wishes to avoid being
paused by full-screen notifications (like an incoming call).
An activity that sets FLAG_IMMERSIVE/android:immersive is
sending a signal to the notification manager, status bar,
etc. that they should try to find some other way to get the
user's attention in high-priority situations.]
[Originally: change Ie290c2e.]
Change-Id: I967bb10b930b8f0772b10f81f2957a03fa3f1736
/frameworks/base/core/java/android/view/WindowManager.java
|
| ae069f76ee65fd5d9252c8191429fa55296d0208 |
|
18-Jun-2010 |
Daniel Sandler <dsandler@android.com> |
Fix SDK docs build.
Change-Id: I2d11682cdf2cdcd48f0299f8c168fddd5994dc65
/frameworks/base/core/java/android/view/WindowManager.java
|
| 611fae4c39edbeb23b53f789a0219c539cf32fa6 |
|
17-Jun-2010 |
Daniel Sandler <dsandler@android.com> |
New API for "immersive" activity windows.
An "immersive" activity (as indicated by the new
FLAG_IMMERSIVE) is one that wishes to avoid being paused by
full-screen notifications (like an incoming call).
An activity that sets FLAG_IMMERSIVE on its window is
sending a signal to the notification manager, status bar,
etc. that they should try to find some other way to get the
user's attention in high-priority situations.
FLAG_IMMERSIVE should be used exclusively in conjunction
with FLAG_FULL_SCREEN (that is, only activities that hide
the status bar should consider themselves immersive).
Change-Id: Ie290c2e92fc391bcf55edfdb1fbd626cd284e3e2
/frameworks/base/core/java/android/view/WindowManager.java
|
| f10e6331e3bf01653235d93aa523056c146a85a3 |
|
11-Jun-2010 |
Scott Main <smain@google.com> |
docs: fix markup error
Change-Id: Icea017095f58068c55dd3c1c18cecbdf06afb595
/frameworks/base/core/java/android/view/WindowManager.java
|
| 20e9271cf25e48d8ea17bed74e87465ca3d77b8c |
|
02-Apr-2010 |
Daniel Sandler <dsandler@android.com> |
Add more WindowManager flags to ViewDebug.
Bug: 2567955
Change-Id: Ia34aaa3cbf6e2bc2e59fe9ae83e4c8a6498612ca
/frameworks/base/core/java/android/view/WindowManager.java
|
| 8f2bd4328a7cc9dd70e597b7cc011be22c6ca566 |
|
25-Mar-2010 |
Joe Onorato <joeo@android.com> |
Add window flags and window types to hierarchyviewer.
For debugging http://b/issue?id=2544870
Change-Id: I4b7775e6fd275bb7a9041bf5736e076122bfb5f1
/frameworks/base/core/java/android/view/WindowManager.java
|
| 95f7850a9d9c7c4f020d06986300f4740fb6a52c |
|
30-Jan-2010 |
Christopher Tate <ctate@google.com> |
Fix build: javadoc @link pointers need HTML-style #refname
Change-Id: I0e061516fce2bcf5dea401f58180f2ff396482ab
/frameworks/base/core/java/android/view/WindowManager.java
|
| ef73162887943e16587b8e737b19e59348338e8c |
|
27-Jan-2010 |
Mike Lockwood <lockwood@android.com> |
Support for triggering the lockscreen while the screen is on:
Add new ALLOW_LOCK_WHILE_SCREEN_ON window manager flag, which when set
causes the window manager to put up the lockscreen after the
normal screen timeout has elapsed.
Add plumbing to pass PowerManager.userActivity() to the window manager policy.
Change-Id: I05adc52bad39c56031a08e8ec3cbcf5c2d9b9827
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManager.java
|
| 980a938c1c9a6a5791a8240e5a1e6638ab28dc77 |
|
09-Jan-2010 |
Romain Guy <romainguy@android.com> |
Deprecate fill_parent and introduce match_parent.
Bug: #2361749.
/frameworks/base/core/java/android/view/WindowManager.java
|
| fb73f79340375013225618a5d87f46b958f698ef |
|
20-Nov-2009 |
Mike Lockwood <lockwood@android.com> |
Add window manager support for overriding button and keyboard backlight values.
The new backlightBrightness field works similarly as the existing WindowManager.LayoutParams.screenBrightness field
Needed for bugs:
b/2233655 (under low ambient light the touch keys remain illuminated during video playback and never timeout)
b/2221079 (Backlight for home/search/back/etc buttons should turn off when in dock in night mode)
Change-Id: I60dfecdc7bb653b0db38094464de651220b3d438
/frameworks/base/core/java/android/view/WindowManager.java
|
| badc47ecd1677d5f53bb16f8f30c158a879f5832 |
|
09-Nov-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2242440: Window screen brightness attribute is broken
Um okay, that was dumb. And I guess this means it is time to make 6.xml.
Change-Id: Ic42763b1c8a13448cf6db20b4cd6daadc7786ac1
/frameworks/base/core/java/android/view/WindowManager.java
|
| 3b3e145d3c41fd68974e08f799b1fd1f8f060cf0 |
|
25-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
A variety of work on animations.
- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
/frameworks/base/core/java/android/view/WindowManager.java
|
| 9bfb707597898f54722460b48588007b682f3e2a |
|
22-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Various fixes and improvements to window, activity.
- New meta-data you can add to a dock activity to have it launched by the
home key when the device is in that dock.
- Fix a deadlock involving ActivityThread's internal content provider lock.
- New window flag to have a non-secure keyguard entirely dismissed when a
window is displayed.
- New WindowManagerPolicy APIs to allow the policy to tell the system when
a change it makes during layout may cause the wall paper or
overall configuration to change.
- Fix a bug where an application token removed while one of its windows is
animating could cause the animating window to get stuck on screen.
Change-Id: I6d33fd39edd796bb9bdfd9dd7e077b84ca62ea08
/frameworks/base/core/java/android/view/WindowManager.java
|
| 93e462b79d6896da10e15e74c5aec6beb098dddf |
|
16-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #1780928: Need support hiding nav keys.
This implements support for devices whose hardware can hide
their navigation keys. It works much like the existing keyboardHidden
configuration, and for compatibility uses the same configuration
change bit.
Also add FLAG_TURN_ON_SCREEN for windows, which has the system
cause the screen to be turned on when the window is displayed.
Great fun when used with FLAG_SHOW_WHEN_LOCKED!
Change-Id: I0b867f19af85cfd8786a14cea194b34f7bdd9b7a
/frameworks/base/core/java/android/view/WindowManager.java
|
| 317a6280cc109e873646e4652be1582d870eedfd |
|
14-Aug-2009 |
Mathias Agopian <mathias@google.com> |
Surface::GPU and Surface::HARDWARE are now deprecated; they will be set automatically if needed.
this also ripples into the window manager API by making some constant there deprecated as well.
/frameworks/base/core/java/android/view/WindowManager.java
|
| 4c62fc0e1e5ea9c69a12a7d1cf8b3ec8b2d114a3 |
|
09-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Very primitive wallpapers in a surface.
This is all of the basic pieces:
- The WallpaperService now creates a surface with the window manager for its
contents.
- There is a simple service that displays a bitmap.
- The wallpaper manager takes care of starting and stopping the service.
- The window manager knows about wallpaper windows and how to layer them with
the windows that want to be shown on top of wallpaper.
Lots and lots of issues remain, but at this point you can actually write a
wallpaper service, select it in the UI, and see it behind an activity.
/frameworks/base/core/java/android/view/WindowManager.java
|
| 61324e58c549670c015010d0be14c6af76e3e9f7 |
|
22-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
cast is floor. Use round instead.
This fixes a few layout issues (that was due to smaller widnow size)
/frameworks/base/core/java/android/view/WindowManager.java
|
| 841f13c8e9ff3f7695b6c18a8abcec3c947983ff |
|
18-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
* Reverted the change in PackageParser that I checked by accident
* More surface view fix.
- correct event translation on surface view.
- use compatible window
* removed FLAG_NO_COMPATIBILITY_SCALE. It was my misunderstanding of how SurfaceView works, and this was not necessary.
* Added compatibility related info to package dumpsys
/frameworks/base/core/java/android/view/WindowManager.java
|
| 5a2b91dc14e4c92e91c6abcc795f54ac98ee5866 |
|
17-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
* Use Fede In/Out animation if one of opening/closing apps is in compatibility mode.
* preserve compatibility window flag when the app updates window's layout params.
* Added assertion in DEFAULT_COMPATIBILITY_INFO object to prevent unintentional modification.
* A few minor updates
* log/dump message improvement
* Removed unnecessary method in FadeInOutAnimator
* Fixed 100 char issue in WindwoManagerServer.java
/frameworks/base/core/java/android/view/WindowManager.java
|
| 1ecf5d28817f0a051e77488380dcd5bc622ea169 |
|
07-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
Re-implementation of large screen support using window manager.
* added background filler surface to fill the outer rim. Using the same layer as dim surface because
they never co-exists (in the same window)
* clean up the obsolete code in CompatibiltyMode/ViewRoot for support large screen support.
/frameworks/base/core/java/android/view/WindowManager.java
|
| 64f59342d41849bd365cb43fad7505d5e3daa417 |
|
21-Jun-2009 |
Mitsuru Oshima <oshima@google.com> |
* new screen resolution support impl.
* use full window for activities, and shift & clip the content
* refactored the compatibility code, and introdcued Translator class to handle cooridnate translations.
* removed a workaround to handle an activity with configChagne=rotation in old implementation.
* I'll fix background issue on rotation in next CL.
* removed unnecessary scaling code in SurfaceView, which I forgot to remove when I changed SurfaceView
not to scale the content.
/frameworks/base/core/java/android/view/WindowManager.java
|
| 7299807d1895ea25cbe45d32b6edfd9a5723ee7a |
|
22-Jun-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1933585. Don't dismiss ACTV's drop down when it's set to alwaysVisible.
This change also resizes the drop down automatically whenever the soft input
method is shown/hidden.
/frameworks/base/core/java/android/view/WindowManager.java
|
| e5fb328825995aa33b5b7ecf8b5bee2b17f81715 |
|
10-Jun-2009 |
Mitsuru Oshima <oshima@google.com> |
resolution support fix/improvement
* adding compatibility menu
* backup gravity
* set expanable=true if the screen size is hvga * density.
* added "supports any density" mode. I'll add sdk check later.
* disallow to catch orientation change event if the app is not expandable. This
was causing layout problem under non-expandable mode. I discussed this with Mike C
and we agreed to do this approach for now. We'll revisit if this causes problem to
a lot of applications.
/frameworks/base/core/java/android/view/WindowManager.java
|
| c4d5d02667af6989a3121072871f6a4b1e68b594 |
|
22-May-2009 |
Dianne Hackborn <hackbod@google.com> |
Add new window manager type for a hacking second-level media surface.
This adds a new window type that is a surface that sits between the
current media type and the application window, in theory allowing you
to have two surface views in your hierarchy and control their
Z-ordering. There is also another hidden API on SurfaceView to set
the type of your window.
All a big hack, but for the good of the commonwealth!
/frameworks/base/core/java/android/view/WindowManager.java
|
| d1a9337380cf9f40f1aa095457b11242d483295d |
|
15-May-2009 |
Suchi Amalapurapu <asuchitra@google.com> |
Add a new window flag to display a window when keyguard is shown.
/frameworks/base/core/java/android/view/WindowManager.java
|
| 3d91492d694cf00474fec792134e496be6ee0313 |
|
14-May-2009 |
Mitsuru Oshima <oshima@google.com> |
fix window layout problem in ViewRoot
* don't scale LayoutParams (this must be app's scale).
* scale the layout params' coordinates & size only when requesting layout.
In SurfaceView, window's x,y wasn't scaled before sending to window manager.
/frameworks/base/core/java/android/view/WindowManager.java
|
| 8169daed2f7a8731d478b884b1f455c747b88478 |
|
29-Apr-2009 |
Mitsuru Oshima <> |
AI 147976: Compatibility mode support. Part 2.
* 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
/frameworks/base/core/java/android/view/WindowManager.java
|
| 8d112675879a2b83197d3b4ae4fb623abd1a1ec3 |
|
27-Apr-2009 |
Mitsuru Oshima <> |
AI 147845: Compatibility mode support. Part 1
Adding supports-density tag to manifest file/ApplicationInfo.
BUG=1752478
Automated import of CL 147845
/frameworks/base/core/java/android/view/WindowManager.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/WindowManager.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/WindowManager.java
|
| 3001a035439d8134a7d70d796376d1dfbff3cdcd |
|
19-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@132276
/frameworks/base/core/java/android/view/WindowManager.java
|
| da996f390e17e16f2dfa60e972e7ebc4f868f37e |
|
13-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@131421
/frameworks/base/core/java/android/view/WindowManager.java
|
| d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/view/WindowManager.java
|
| 9266c558bf1d21ff647525ff99f7dadbca417309 |
|
16-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@126645
/frameworks/base/core/java/android/view/WindowManager.java
|
| f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/view/WindowManager.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/WindowManager.java
|