- Allows several callbacks from different processes to register with
the ContextHub service.
- Add an 'internal' callback that can be used for primary clients.
- Fix issue with parceling NanoApp info
Change-Id: Iec203e8b8bc847cb9274f3f4157d0773984dd87c
Register docked stack listener in ActivityManagerService.
If the docked stack is leaving minimized state, check whether the user
of the docked stack is locked. If yes, show credential confirmation.
Also, we now show work challenge in home task.
And we now scan the entire top task to handle the case the work app is
somewhere in the middle of the task. (eg: open personal camera in work app)
Bug: 27565539
Bug: 28094505
Change-Id: Iaf0738f43ae916a535b17949ec0f322bbfb194dc
This patch changes how Event classes are organized:
- Base IpConnectivityEvent class does not implement Parcelable because
it cannot be final (has children). It also becomes abstract because
it is not supposed to be instantiated and logged directly.
- All children classes becomes final because they are Parcelable.
- All constructors of all children classes become private, because they
are supposed to be instantiated with their associated logEvent()
methods.
- All instance fields of all children classes become public final.
Rational: if private, the ConnectivityMetrics app cannot read
their data.
Bug: 28204408
Change-Id: I1a4689c422230c6ed034307dec54a61daf8a6598
This patch moves the event logging of DHCP response packet parse errors
to DHCPClient in a single place. It also logs receive IO errors as
DHCPErrors instead of DHCPClientEvents.
BUG=28197345
Change-Id: I7ad666cff4d8b97915880477347fbb3f588fdb2a
Stop repeating request if any of its output stream is abandoned
and notify that repeating request has been stopped.
Update binder tests for binder interface changes.
Update CameraDeviceImpl to expect an exception when canceling
a repeating request that is already stopped.
Bug: 21270879
Change-Id: I9fa72ae7218948aac88cb1a8e57839bd022c4a5e
Don't return null from createUserCreationIntent()
Provide a way for apps to query if the device
supports multiple users.
Some additional documentation for UserManager class to
make things clear about the types of users and relationship
with accounts.
Change-Id: I768d816e73a1d7f61cdc415f9e482adc79e2715a
Fixes: 28150359
- Allow SearchView to expand to 48dp height if possible.
- Make the search clear button have 48dp height if possible.
- Expand the search TextView touch target height to 48dp is possible.
Framework version of patch ag/912646
Bug: 19479861
Change-Id: Ibaaef2afa20b8c05eaac8f028df4f616f2f96eb1
Fixes: 28074239
Need to convert from scaled window to screen before
updating position of the SurfaceView
Change-Id: I75dec23408c32ec01e88193ea38b1fb253b3fd6f
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
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
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
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
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
We need to remember task which requested to be locked
because we can accidentally lock another task after
user interacts with pinning request dialog.
Bug: 27876860
Change-Id: Ie8e607df4380dd33ea9b3474afc247b02e31de07
- Make FingerprintService more closely track the expected state of fingerprintd.
- Don't switch to a new operation until fingerprintd completes previous operation.
- Refactor clients into separate classes and add tracking logic.
- Add missing enumerate()/cancelEnumeration() methods to IFingerprintDaemon
- Make late-binding decision of "foregroundness" of activity so that it's
decided in the order the events are actually handled.
- Add more logging so we can determine FingerprintService state when errors occur.
- Cache a copy of authenticator_id from the last time it was set so we don't
interrupt the driver during actual authentication.
- Don't allow clients to access authenticator_id unless they're current.
Fixes: 27902478, 26273819
Change-Id: Ic1f9e30bd89bcdbb8fe7f69e0545e68339317721
