There are two bugs one is I was clearing the notification in
CaptivePortalTracker when entering the ActivateState. (double check
according to bug 5021626 we should be calling enter)
Second is we could have the need to display both icons but can't
because we only allow one.
The solution I'm proposing here is to allow two notifications and
have then controlled separately.
Bug: 10886908
Change-Id: I30e7130bc542535492d175640a4990c592f32806
The scale gesture detector has a new behavior to make onScale
callbacks during swipe after a double tap. The screen magnification
is triggered after a trippe tap so if the user trippe taps and
holds to do a temporary magnification and tries to change the
zoom level with another finger, erroneous results are obtained.
The ScaleGestureDetector uses an APIs level check for the new
behavior but the ScreenMagnifier is a platform feature. We now
explicitly ask for the old behavior.
bug:11033376
Change-Id: I0dfb14dd3abcaa34ad1f40447c631b4203797378
Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
Previous TAG was "WallpaperService", which conflicted with the
WallpaperService class' tag, making debugging wallpaper issues more
confusing than necessary.
Change-Id: I0f60ff472304a1d8792d9941ddab7ce0304a2276
After a reboot, KeyStore is locked, and certificates encrypted with user
PIN are not accessible. So statemachines are not able to connect to
EAP-TLS networks. This change makes the problem less severe by
1. Not signing certificates with user PIN on devices with hardware backed
KeyStore.
2. Issuing a reconnect upon first USER_PRESENT event.
This means HH (which has a hardware backed keystore) can connect to
EAP-TLS networks without requiring user intervention and other devices
will automatically connect to those networks after user punches PIN.
Bug: 10325089
Change-Id: I023d60e58d8214152f051bd9ec84b85b702d829a
Only use the stack bounds for the DimLayer bounds if there is more
than one stack on a layer. Otherwise cover the entire screen (and
more) with the DimLayer. This way there are no exposed regions when
rotating.
Fixes bug 10428085.
Change-Id: I7bfff12b69d59e86610621c498dab35cf0db8eb5
Newly added private flags were being masked in the public flag variable
as opposed to the correct privateFlags variable.
bug:11033280
bug:11043194
Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
Instead of keeping a single global system decor rect around
in WindowManagerService, calculate and store policy-defined
system-decor frame for each window.
The per-window decor rect is useful for smooth transitions, since it
determines window cropping during transition animations.
Bug:10938001
Change-Id: Ice6652aa5946027c45c0b7ab4e46473a0f8e3f90
First, startTime's default value is -1 and not 0, so use it to test
if the startTime is set. Also, startTime isn't being set when connecting
legacy VPN; this change fixes that too.
Bug: 10985174
Change-Id: Ibf52b8f489b18c96efba501b76aa73e9a9e0e3e8
The activity manager can create a new task under certain
circumstances in resetTargetTaskIfNeededLocked(). In that case the
window manager was not told to create a new task. This fix creates the
task in window manager when it recognizes that there is a new task
required.
Fixes bug 10412588.
Change-Id: Ife9ecfeb7f53f9df5950322c9359c836adc258a2
The main problem here was a mistake when turning a single process
structure to a multi-package-process structure with a common
process. When we cloned the original process state, if there were
any services already created for the process for that package, they
would be left with their process pointer still referencing the
original now common process instead of the package-specific process,
allowing the active counts to get bad. Now we switch any of those
processes over to the new package-specific process.
There was also another smaller issue with how ServiceRecord is
associated with a ServiceState -- we could be waiting for an
old ServiceRecord to be destroyed while at the same time creating
a new ServiceRecord for that same service class. These would share
the same ServiceState, so when the old record finally finished
destroying itself it would trample over whatever the new service
is doing.
This is fixed by changing the model to instead of using an "active"
reference count, we have an object identifying the current owner
of the ServiceState. Then when the old ServiceRecord is cleaning
up, we know if it is still the owner at that point.
Also some other small things along the way -- new Log.wtfStack()
method that is convenient, new suite of Slog.wtf methods, fixed
some services to use Slog.wtf when catching exceptions being
returned to the caller so that we actually know about them.
Change-Id: I75674ce38050b6423fd3c6f43d1be172b470741f
