Previously, we show launcher when keyguard is dismissed.
It introduces these issues:
1. There can be no device lock
2. user could take a quick peek of the work app
Current behavior:
1. We now show launcher once the work profile is locked.
2. Lock profile immediately if there is no device lock
3. Add cancel "lockProfileLater" logic
Bug: 27241680
Bug: 27673460
Change-Id: I765aa22d4c8ae5017c1611f5a340a4b33d463b1e
Add a (configurable) delay between when we start a maintenance
window until the minimum time we will end it.
Also switch to using the alarm manager callback API. (Yay!)
Also fix a little printing problem in the alarm manager dump
so we put the package name and not some class hash in the
summary string of an alarm entry.
Change-Id: I4281e5c80bc8b26ebc1fb6f603ec33ec0e379daa
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
Print ActivityClientRecord state when ActivityThread#performStopActivityInner
is called for already stopped activity.
Bug: 25267624
Change-Id: I2b044e42d0188ef9eaf15422b6a05617ade802e2
It's easy for apps to throw custom Parcelables into Bundles, but
if the system tries peeking inside one of these Bundles, it triggers
a BadParcelableException. If that Bundle was passed away from the
Binder thread that delivered it into the system, we end up with a
nasty runtime restart.
This change mitigates this trouble by "defusing" any Bundles parsed by
the system server. That is, if it encounters BadParcelableException
while unpacking a Bundle, it logs and delivers an empty Bundle as
the result.
Simultaneously, to help catch the system process sticking its
fingers into Bundles that are destined for other processes, a Bundle
now tracks if it's "defusable." For example, any Intents delivered
through ActivityThread are marked as being defusable, since they've
arrived at their final destination. Any other Bundles are considered
to be "in transit" and we log if the system tries unparceling them.
Merges several Parcel boolean fields into a flags int. Add better
docs to several classes.
Bug: 27581063
Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
1. Instead of getting application info in runtime, just retrieve the
one in the context to avoid cross user operation.
2. Functions in PackageManager that retrieve badged icon now return
badged icon if the targer user is managed profile instead of checking
whether target user is a managed profile of the user in mContext.
3. Relax the restriction of getUserInfo, if the caller is asking a user
in the same profile group or having the manage user permission, we let
it go.
Bug: 26469166
Change-Id: Ia1ffc5743f7d94bd489cdb7571eaed51499ebdd9
Also make the minimum flex & period available via method call
rather than as hardcoded API constants.
Bug 27619643
Change-Id: Ib4afa427e9b21e13085d245e45b05d70d99724d4
Adding the Context hub service. This is the service that exposes
the context hub HAL to the system. The API exposed is a System API.
Change-Id: I854141714ecd21f6386e6b15b7bc9a997483ccf6
Added @throws tag in the javadoc for many APIs which might throw a
SecurityException in cases when such information might be useful for the
caller. E.g. when the caller has to be a device owner or must request
certain policies before making the API call.
Bug: b/27532288
Change-Id: I18e1a49a5e86a0322c035996ed7e9c3217da78c8
The regression was introduced by 39bfee5e36
which undid the fix to classloader construction.
This commit reapplies the fix from b9c9026bdd
Bug: http://b/27250344
Change-Id: I6c341d911ba0f311c63e380dd9dd064ba2faf391
In DeviceAdminReceiver fixed a broken link in javadocs and improved
javadocs for bugreport error codes.
Bug: 27532425
Change-Id: I6cf90b4109065615778e69ea9d21b1869841593b
Hides the wallpaper when it's not needed and fixes
the unlock animation to not unnecessairly show the
wallpaper if neither the Keyguard nor the underlying
app need it.
Also fixes a bug where the enter animation had a background
set, which led to uglyness when no wallpaper is involved.
Bug: 27533740
Change-Id: I667c6f7ca6c0e1ff7e9f793c6ddc13f6da8387b1
Bug 27142336
Using a type variable in a varargs leads to a javac warning
because type variables are treated as Object after compilation.
Because these uses do not require a specific typed array, we
can use @SafeVarargs to suppress the warning.
Change-Id: I860bcc79667a9c85c381c7994fd1d798209d7c66