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
Add a useful (if somewhat dangerous) method which will help
replace similarly dangerous code patterns in a few different places.
Change-Id: If1295f7ab9652c906ce718d94eb7914d143e1939
This solves the problems around active pointer tracking when the
caller may skip events in the MotionEvent stream and replaces the
old implementation with a much simpler algorithm.
Change-Id: I6b15a2e215cab7b9559db800fcc57374702357fc
The WindowManager retrieved from the activity Context with
getSystemService is incorrect for a Toast. Because it contains
a parent window when addView is called its LayoutParams.token
is set to the value of the parent window. Then when an Activity
is dismissed WindowManagerGlobal.closeAll() sees the incorrect
token and incorrectly closes the Toast.
This fix uses the application Context instead of the activity
Context to retrieve a WindowManager with no parent window. This
leaves the token unchanged and keeps from dismissing the toast when
the activity is closed.
Fixes bug 7048792.
Change-Id: I92c3095d8fabd6e9e4206e9bc8e917885ab322a9
Ensure that only applications with
android.Manifest.permission.PACKAGE_VERIFICATION_AGENT can call application
verification APIs, like PackageManager.verifyPendingInstall and
PackageManager.extendVerificationTimeout
Bug: 7049083
Change-Id: I5fc28b37e864d67cd319a1ed9d03a90dd15ad052
* commit 'e8f24cc2678240c502d6d6156fd88bc0fa129de1':
[Audio]Press camera button during Http live Audio playing, then return Browser, DUT display abnormal.
* commit '337756fa6587bca84afdfdc964805f962ea534ed':
[Audio]Press camera button during Http live Audio playing, then return Browser, DUT display abnormal.
* commit '78ad66b43cf5b649869de18ee9c246c95b135c10':
[Audio]Press camera button during Http live Audio playing, then return Browser, DUT display abnormal.
This fixes the issue where one thread calls .stop() on
mAudioTrack that was released (or being released) by other thread.
Bug: 7029291
Change-Id: Ia6db803e8ee40379b63327acf578466127cfabcb
We now notify the user of a captive portal before switching to the network as default.
This allows background applications to continue to work until the user confirms he
wants to sign in to the captive portal.
Also, moved out captive portal handling out of wifi as a seperate component.
Change-Id: I7c7507481967e33a1afad0b4961688bd192f0d31
