We added new APIs to allow accessibility services to query all
windows a user can touch. Sometimes the window state change
event arrives before the window manager sent over the new window
state which leads to a case that the app gets the event and
asks for the window and the window is not there. To address this
if we do not have the window, we hold on to the event and
fire it as soon as the window arrives. This logic is correct
except we were wrongly expecting that the window should have
input focus.
bug:17464645
Change-Id: I1ef50ebddeb4416a6c0776b096bb16aee703700c
The BT and Wifi mechanisms for enabling Tethering did their own
permission checks. This set of changes unifies the check into
a ConnectivityManager function so they can be kept in sync.
bug:17435527
Change-Id: I8c157a5acf56ffbddd349cb6a45160ae7be8541b
Currently, carrier requirement is specified through CAPABILITIES key, whose original purpose is to indicate
the capability of the hardware, not to enable/disable features in GPS HW. With this fix, carrier requirement
on GPS features can be specified properly without messing up with the real capability. This will satisfy
VzW, Sprint and USC's requirement on SUPL mode, without sacrificing the capability of HW geofence.
Bug: 17423585
Bug: 17288144
Change-Id: I71173722d4b12bfc17562f7b5444d22b01ff4590
...give time in some cases
This switch to multiple stacks broke the check to determine if it
should actually wait for a new activity to be shown. The new check
now also requires that the top activity be resumed, which means
we may get some false positives where we decide to wait and shouldn't,
but that is better than consistently not deciding to wait in some
cases when we should. (And we will always finish waiting then next
time something becomes visible).
Also add another time, which is how long it took from the startActivity
call to return with the result. And fix when we decide to report that
we are done so that, in the case where we are bringing an existing
activity to the foreground, we don't wait until its animation is complete.
Change-Id: Id38ca0070f04e7bf8c73e131fb055808553a0e2f
Remove token from deferred list of tokens to be removed once token
is removed. Leaving it in the list leads to logging messages like
"WindowManager: removeAppFromTaskLocked: token=AppWindowToken{...
} not found" when an attempt to remove it a second time fails.
Discovered in logs from b/17512377.
Change-Id: Ic83d81841b9b74ae5c4c433d1086d3bbda8e1d64
CTS tests cause the TaskPersister queue to fill faster than it can
drain. Since it contains screenshots this can consume massive
memory. Monkey may also cause the queue to back up.
Several optimizations are added to drain the queue when it gets
large:
- High water mark to recognize when queue gets too deep. Queue is
completely drained at this point so that obsolete files can be
removed from storage.
- Use Thread.yield() to give the TaskPersister write thread some cpu
cycles.
- Remove images from write queue when TaskRecord is removed from
recents.
May fix bug 17177273.
May fix bug 17381033.
Change-Id: If21c03c8f380e5f6816cf4701a40fcfe34ace3f1
When HDMI-CEC system audio mode is activated.
1. Hide volume bar when volume button is pressed in TV
2. Show volume bar when TV receives volume notification from
Audio Receiver.
Otherwise, (system audio mode off) follows normal TV's behavior.
Bug: 17347499
Change-Id: I1f5bc14285d60d8626a8fbbef9e1959cae7d193b
Introduce a concept of a "root affinity" to a task -- this is the
affinity of the initial activity in the task. Use this instead of
the current affinity in findTaskLocked(), where we look for an
existing task to use for a NEW_TASK intent.
This changes the semantics of the new "relinquish task identity" mode
so that it doesn't relinquish the root affinity of the task. This
means when we are in the old style application-based recents matching
of findTaskLocked(), we will never count these tasks as the same as
the application's tasks only because they have relinquished their
identity to that application. This is probably okay, it is basically
putting a different line between new document-centric recents and
old application-centric recents when they are mixed together.
Change-Id: I73a22ead9bd08e98bf67ad035a017f828c6a6715
When TIF client tries to connect a session while TV input is being
updated, updateServiceConnectionLocked() may fail to bindServiceAsUser()
and the session state may remain indefinitely until a client tries to
create another session to connect the service. Reconnect the session by
calling updateServiceConnectionLocked() when package is updated.
Also, remove the session state when client dies before onSessionCreated().
This was causing the stale session in the above scenario (without
reconnection) to be connected to TIS even when client no longer exists.
Bug: 17518751
Change-Id: I5484df0d80c71649d22438521adf182ab59a6ce4
Fixes two bugs introduced by change
I7bd32531130d199c0734ffcb800194e77b7e16c3:
When the system window insets consumed by DecorView
change as a result of changing flags, the insets must
be redispatched to the hierarchy.
Also fixes a bug where, as a result of removing the wrong
implication of the SYSTEM_UI_FLAG_LAYOUT_STABLE flag by
FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS, the status bar was
being forced to black when returning from recents.
Bug: 17489047
Bug: 15046646
Change-Id: I127b0ff3b17c4873a7c28d67020f84298ed09db2
- Clear the logical address on the hotplug event.
- Don't reset mIsActiveSource flag on the hotplug event.
Bug: 17517438
Change-Id: Id129a9cce30323090ce21bbfc188b955bd32755b
For multi-user the issue was looking into the user ID of the current
process instead of the active user. The current process was the system
process and the call to UserManager was returning a user handle that
wasn't of any use while trying to map sound models to a user.
For language, the issue was that we were incorrectly just looking up the
model based on the keyphrase id, however we should have also taken the
enrolled model's locale into account.
Explicitly document that for model management the string representation of locales
is a BCP47 language tag.
Remove debug logging.
Bug: 16798166
Bug: 17462570
Bug: 17463511
Change-Id: Ieffb3e218de63f6e7f40af9705dced481a35b0ad
...irrelevant install state at the end
Quick and dirty impl just doesn't print any of that data when filtering
by package name. In the future that part of the dump should be smarter
to know how to filter by package name. (Probably also moved to a place
earlier in the dump, so the key information -- the overall package
data -- is still at the end.)
Change-Id: I094f7c2f25401438a68a6aa00d10b19c19eb7c7d
This is because of the 5 second timeout from when the user can bring
home to the foreground until regular third party apps can launch an
activity on top of it. Activities launched from notifications look
like they are being launched by the app, so get impacted by the timeout.
Fix this be also looking at the actual caller to see if they are
allowed to pop in front regardless of the timeout.
Change-Id: I63fbc2bcabf585e6d2810a2309f0613fdf91fdf5
Since all TV devices are required to have a DPad as a form of
navigation we should suppress any configuration instances where it
claims one doesn't exist just because it isn't currently connected.
This prevents applications from going through a configuration change
and potentially an app restart when a remote disconnects to save
battery.
Bug: 17493314
Change-Id: Ice87b7056984afe02917ccba9196fdbcac9985fc
I got distracted in the middle of it, and forget to finish
up with the test to not kill processes if they aren't using
an auto create binding.
Change-Id: Ieecfe97fa3208e50cb91ba94be2a8659d128b0de
...are killed over eagerly.
When the current foreground activity is moving to the background,
it was briefly going through the CACHED_ACTIVITY state before the
correct LAST_ACTIVITY state, allowing its bound service processes
to be killed (because they went in to the cached list). To solve
this, as long as a process has stopping activities, it won't go
lower than LAST_ACTIVITY.
Also fixed a problem where we could put a process in CACHED_EMPTY
instead of CACHED_ACTIVITY_CLIENT. There were a number of cases
in the binding flow and also the client process state transitions
where we would not correctly updateing the bound client activity
state.
And add some sanity code so that if a process hosting a
service is killed, and a client process of that service is in the
cached state, we kill the client process. This avoids situations
where we can start thrashing around in the cached list because we
are restarting process for no reason -- since they will just
continue to be cached.
Finally, tune the process LRU list to allow twice as many cached
activity processes (from 8 to 16), so we can make better use of
the RAM we have available these days.
Change-Id: Ib0cdf78c321cbb035259fc9dd6ee27b5ba1f90c5
Found a regression in volume handling. Previously we handled
volume commands as long as the media stream was active but we were only
handling them when there was an active session on L. This adds a check to
make sure we handle volume if anything is playing on the media stream.
bug:17498479
Change-Id: Iddd745c8a762cf7ebedb37f1b26fc934db01fba0
- Add an explicit power manager call to set the low power mode state,
instead of trying manage everything around a single setting.
- When low-power mode is triggered by falling below the configured
threshold, it does not update the setting.
- The "is-enabled" api returns setting || below configured trigger.
- Move the snooze management into the new api call.
- Callers (sysui + settings) updated to use the api instead of the
setting.
- Handles the case where the level does an unpowered leap out of the
low battery level. (Possible if powered in-between while the device
is off)
Bug:17460535
Change-Id: Ic030504c9cad9868a7137abbe837b170da37852b
