When having an app docked and then going home, and then launching
the app from the homescreen, we had a wrong transition because
getTopMost task was already set to the launched app, because
getRunningTasks doesn't exclude the docked stack. Instead of adding
flags for getRunningTasks, which sounds risky, we just pass a "force"
value when we launch recents in this state.
Bug: 27154882
Change-Id: Iee4512fed13115dbbe8b74413ff1fa9b87afa0ef
Because we only "carve" out the area for the IME once it's actually
visible now, we need to relayout the windows when we show it - else
they won't update the insets until the next real layout happens.
Bug: 28175599
Change-Id: Ie0af1225da03905bfcb52044e212812c892c88a9
When tests run for the first time, the list of activities that can
handle ACTION_SEND_MULTIPLE might not be scrollable, which was cause the
scrollForward() method to fail.
BUG: 27431998
Change-Id: I5992bc9fec6291c74c4af7887ee66eb4f96e87c0
Per feature council decision, the multi-endpoint APIs will be @hide for
the N release.
Bug: 28196918
Change-Id: Ia80b089bc754ce87ca208382eb79442b5265844d
Framework edition
Previously we would throw away any stopped LoaderManagers when we went
to retain instances to pass along as nonConfigurationInstances during
config changes or similar activity restarts. This causes loaders to do
more work than they need to when a calling activity starts a new
activity on top, a config change happens (e.g. screen rotation) and
then the top activity is finished, restarting the caller in a new
configuration. The loaders would go through onReset unnecessarily,
potentially throwing away data to be reloaded again after the config
change completes.
Instead of throwing away stopped LoaderManagers in this case, restart
them and retain them across the config change so they can resume where
they left off.
Bug 27176186
Change-Id: Ia52c6448d2ad41dcb25d493770d9ffae20a19d2a
In assignAndIncreaseLayerIfNeeded we need to always
restack the special windows, even if we are stacking them
downwards, otherwise they could be left at too high of
a value from a previous pass. This check was added by
me originally, as a now revealed poorly thought out attempt
to avoid changing existing behavior too much.
Bug: 28139028
Change-Id: I305499e194f2c6bcf7a38c80af1e64bd1fc20943
Case was omitted in dialog, resulting in UnsupportedOperationException.
Remove a redundant flag check.
Bug: 28204292
Change-Id: I313d61c72596d4a127f61d557af7300f50d26bf0
Setting PARSE_IS_SYSTEM to the parse flags happens long after the
APK is actually parsed. So, we fail to pick up the boot aware and
protected storage attributes. Instead, always pull them from the
manifest, but, remove the flags if the package is not actually a
system package.
Also, we were incorrectly skipping certificate verification if
the flag PARSE_IS_SYSTEM was set. However, this flag is used for
_any_ system package -- whether it's physically on /system or if
it's an unbundled update. Instead, we should only skip this step
if the flag PARSE_IS_SYSTEM_DIR. We can implicitly trust any
APK actually stored in /system.
On a different note ... At some point, we will break apart the
parse flags into actual parse flags [i.e. those that change
physically parsing an APK] and policy flags [i.e. those that
change the interpretation of the APK contents].
Bug: 28116074
Bug: 28088617
Change-Id: I85246b0cb18fb5647df3618107910e288137fbc7
HdmiControlService manages listeners in listener record instances, and
remove them when binders become disconnected. However, if the listener
and its record are replaced due to new listener, the record for the new
listener should not be set as null by previous binder's disconnection
signal.
Bug: 28069465
Change-Id: I2984d8f93d6443048cf5d3f2988b3c6cf362f012
(cherry picked from commit f5c2a1f58dc95b9800ffb6ebf405c11acc6626b2)
This avoids making expensive netd calls while holding the mRulesLock
Doesn't fix the problem of turning on hotspot while WiFi was connected.
It is no longer blocked on isNetworkMetered() call though.
Partial fix for following bugs...
Bug: 27857665
Bug: 28201280
Change-Id: I62f3c0b0571292cc1e156b48ce3329def41cdd07
APF version 2 and prior versions fail to execute JNEBS with R1 argument.
The APF interpreter tries to use R1's value as the number of bytes to
compare, as well as the offset within the packet to compare at.
This change makes ApfFilter avoid using this and makes the APF generator
throw if this is used. This was limiting the IPv4 filter, causing it to
only drop multicast (when multicast filtering was enabled), rather than
a wider range of broadcast packets.
Bug: 28206777
Change-Id: I8d116e024e8bd641b21053c6b1defc734d744467
When quiet mode is disabled for a user and that user is not currently
decrypted, we show a confirm credentials screen to trigger decryption
of that user. Only if that was successful, do we actually disable quiet
mode.
Bug: 27764124
Change-Id: Ib1f649194d89e225dad62c14f3ddba1fa3d79da2
This CL defines new extras that can be set in a call's intent extras.
These extras track the following:
CALL_CREATED_TIME_MILLIS - the time when the call was created by
telephony (or another connection service)
CALL_TELECOM_ROUTING_START_TIME_MILLIS - the time when telecom
started processing the call
CALL_TELECOM_ROUTING_END_TIME_MILLIS - the time when telecom
finished processing things like call blocking and was ready to
connect to the UI
These extras can be used by the dialer to track how long it takes for
calls to be shown to the user.
Bug: 28202119
Change-Id: I8fca259d449adedaeb4ff91d35bf59a7409be866
The JavaDoc for many of the requestNetwork and
[un]registerNetworkCallback APIs incorrectly mentions the
PendingIntent version of the APIs instead of the NetworkCallback
version.
Also fix a minor issue in the registerDefaultNetworkCallback
JavaDoc: the default network request is an implementation detail,
so don't mention it. Instead, talk about the "system default
network".
Change-Id: Id94d98261daa2bd768c10e033cb8092729b21c91
