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
This is for debugging purposes to verify the effects of
change Id45abeba1b1e843053ac2c946861b439ca568de4.
Bug: 5670680
Change-Id: Ia065dec6ba651e7e77205f812b7606b15eebdc17
- Add delayed disk write in WifiConfigStore
- Remove synchronization and keep all access to config store
throught the state machine thread
Change-Id: I53768a17895e48da7b99542ac95c6c2fddbcb021
- Don't get and cache phone tpe at the initialization time. At this point
TelephonyManager is probably not ready yet.
- Refresh MCC whenever we get the service state changed callback, even when
the state hasn't actually changed, in order to make sure we get refresh
country properly when MCC changes.
- Also remove the initialization of mPhoneStateListener, which prevented us from
registering phone state listener properly.
- Also fix tests which were already failing.
Bug 5670680
Change-Id: Id45abeba1b1e843053ac2c946861b439ca568de4
This fixes a complaint from carriers (that we used 8.8.8.8), but also
fixes the case where there is only room for one live radio
connection: the secondary connection (tethering) doesn't have a
default route to prevent on-device traffic from slipping out on the
tethering connection, but tethered dns is proxied through dnsmasq, so
it is appearing as on-device traffic and is unroutable. By switching
to the carrier-indicated dns servers we can use the host-routes
already set for those and kill two bugs with one fix.
bug:5525764
bug:3045311
Change-Id: Ib1ccea81e0c0ed2d1462dc9721c2647124a790da
* commit 'a21ce1f1107e1aad19335bebe4aed915158b5ca6':
Workaround for issue where the notifyDatasetChanged call chain is broken when Launcher is killed. (Bug 5703782)
... a different app opens
In some cases when reparenting activities we could end up with a reply
chain that crosses task boundaries, so if an activity below that needs
to be reparented we pull that and the activities above it up into the
new task.
Change-Id: Ia4fa041ab7069e39dac162ddbf5b8e1de98675b9
New API to let you build an Intent whose base configuration is correct,
but has an additional "selector" to pick out the specific app that you
would like launched.
Change-Id: Ide9db6dc60e2844b7696cfe09b28337fe7dd63db
Uses argument escaping inside NativeDaemonConnector, using varargs
to separate boundaries.
Bug: 5472606
Change-Id: Ie107a90df7e2b3bd3eaaf04c8367248ab40136f4
Uses argument escaping inside NativeDaemonConnector, using varargs
to separate boundaries. Also introduces Command object to help build
argument lists.
Bug: 5472606
Change-Id: I357979fc19bb0171a056e690064e01b5a7119501
This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).
This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.
Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
As it turns out, it used to be possible for there to be multiple
input events simultaneously in flight in an application. Although
it worked, it made it hard to reason about what was going on.
The problem was somewhat exacerbated by the introduction of a
queue of "InputEventMessage" objects as part of an earlier latency
optimization.
This change restores order from chaos and greatly simplifies the
invariants related to input event dispatch within the application.
Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
Setting it when a new activity is being resumed is too soon, because
things like an activity launching an exiting (without being seen by
the user) can knock out the real previous app that we want.
So now we set it when an activity is stopped. At this point it is
going to move from the preceptible to background oom adj, so it is
a good point to determine whether it should be a previous app to
instead put it to that oom adj. This also avoids things like
activities that start and immediately finish from impacting the
previous app.
Further, we keep track of the time each activity was last shown, and
use this to further filter what is set as the previous app.
Change-Id: I72d1cac4de0cc2d4598170296028f11b06918d4f
