Since these alarms allow you to bypass the idle restrictions,
we don't want them to be so open-ended like other alarms. This
implements a policy where the alarm manager will only deliver these
types of alarms every X minutes to each application. For this
initial implementation, X is 1 minute under normal operation and
15 minutes when in idle mode.
To do this, I needed to introduce a new internal allow-while-idle
flag for system alarms, which applications can't get, and doesn't
have these new restrictions.
Also tweaked how the alarm manager handles the alarm window, so it
doesn't change if the alarm gets rescheduld; the window is now always
what as computed based on the time when the alarm was first
given to it.
Finally, fix TimeUtils to be able to correctly print times that
are > 999 days.
Change-Id: Ibad8c6a7c14b0624b54e82267be23224b4c31e84
This fixes a bug where key pair generation fails for RSA signing keys
which are not authorized for PKCS#1 signature padding, such as keys
authorized only for the RSA PSS signature padding scheme.
The issue was that the KeyPairGenerator was failing when attempting to
sign the self-signed certificate (needed by Android Keystore) using
PKCS#1 padding for which such keys are not authorized. The solution is
to not attempt to sign these certificates and instead use a fake
signature.
Bug: 21809600
Change-Id: I4f04fcf78174937046d2534e0485c6940eae673f
Apps may specify upgrade-key-sets which are different than their current signing
keys to prevent a future upgrade with the current set of keys. Every package is
re-scanned on boot, however, so the existing application would violate its own
recorded upgrade-key-sets. Change the key verification check to ignore
upgrade-key-sets on boot. Also default to the same-sig checks if the
upgrade-key-set meta-data has been corrupted.
Bug: 21785716
Change-Id: I5c0c1e2017ec780a745a74488620bfe95b052269
This makes Android Keystore crypto operations defer pulling entropy
from provided SecureRandom until KeyStore.finish, where appropriate.
Such as when performing asymmetric encryption or generating
signatures.
Bug: 18088752
Change-Id: I4a897754e9a846214cf0995c5514f98cf0edd76b
While authoring the CTS tests I discovered a few issues with the
VideoProvider.
1. The VideoProvider's default handler should be on the main Looper,
similar to other Telecom components.
2. When calling IVideoCallbacks, the try/catch for RemoteExceptions was
around the for-loop which iterates over the various VideoCallbacks. If
one was to fail, the other VideoCallbacks would not be called.
3. The mVideoCallbacks hashmap should use a ConcurrentHashMap; in CTS
tests I ran into a few concurrency exceptions related to the various
InCallServices registering callbacks while other methods on the provider
were being called.
Bug: 21802841
Change-Id: Ib0d46daf03554309044e9efaa991a15cb2c4b46b
Docs for translucent-vs-transparent-vs-opaque were confusing, especially since
the definition for those constants in PixelFormat are not the same as how they're
actually used in Drawable. This fix simply adds clarifying text to the method
comment for getOpacity().
Issue #21158891 Better document Drawable#getOpacity
Change-Id: I94725592f85e5d7874e3a3ac1c5bab969163fbf0
