Loading the avatar icons and drawing them into the sized bitmap
turns out to be quite expensive and the cost increases with number
of users. Caching them shaves off several hundred milliseconds from
Keyguard inflation time during user switching on the lockscreen.
For instance, 15ms vs. 750ms with 3 avatars on a certain 7" tablet.
Bug: 7986933
Change-Id: I3e2065bfa25aa263133ba204ca364c3b04d7c0ff
1. The scheduling was relying on receiving battery level broadcasts
which however are not sent if the device is asleep. The maintenance
window was not bound and we could miss a frame if the user did
not interact the device longer than the min time between two
maintenance windows.
2. Hide the idle maintenance intents since this will be rewritten
to user services.
bug:8688454
Change-Id: I17b421b09823cb46ec218cabda19e02432d94f8c
By adding these stubs, they will be automatically added to framework.aidl
in sdk builds.
This makes it easier for unbundled apps to pass these objects across
AIDL calls.
ContentValues & CursorWindow are already public Parcelables. It is an
oversight that they were not already in framework.aidl.
There are a lot of other public Parcelables that are missing from
framework.aidl. This just fixes two commonly requested ones.
Change-Id: If61e19b1206da1680413d9ea03de87a90b6d233e
Only allow through changing direction configs for drawables.
Explicitly map layout direction values to an index in the
preload arrays.
Drawables that don't vary by configuration should go in to both
the rtl and ltr preloads.
Change-Id: Ib92dd11738082a795e02d1d4191adb54702d651c
API for querying accounts visible to a specific package.
Improve API and docs for device owner.
Bug: 8657158
Change-Id: I01b8701534f64b383391508a49ae93ed21f22ae0
- populate the preloaded drawable cache with only LTR drawables
when the layout direction during preloading is LTR. Populate
the cache with only RTL drawables when the layout direction during
preloading is RTL
- only preload drawables that dont have a dual LTR/RTL version
Change-Id: I7807bdc031b99102609efda75042a9500d96065c
Use a Bundle for persisting and passing to the application, but use a
list to return data back from an application that's exposing restrictions.
Changed the xml reading/writing code to store the value type in the Bundle
so that it can be reproduced when reading. Earlier we were assuming only
String and String[].
Bug: 8633967
Change-Id: I523d5553728edcf28a1e9d432f490b4956f34215
Anyway they need to request account access and user will be asked to approve access to the account
at runtime.
Bug: 8617168
Change-Id: I31de852b9bb25f496becc3e6470265b5c330e6ad
This can be used by apps that won't work without an account of that
type in the limited user environment. This way we can avoid letting
users select these apps when setting up a limited user.
Bug: 8600261
Change-Id: Iaa0dd5ff88e89fa7a1d8a4e70317290268411bdb
...to allow for orientation locking
This doesn't add an API to get the current orientation, since that is
inherantly racy. Instead there is a new "locked" orientation mode that
locks the screen into whatever the current rotation is.
While at it, added a few other useful orientation modes.
Change-Id: I5c369e6511cb72294e9e922ea8acffd770df9440
- fix DrawableContainerState.getChangingConfigurations() to take care about its children
- make Resources.verifyPreloadConfig() return false when the changing configuration
contains layout direction bits (this is when a Drawable is having different version
for LTR and RTL layout directions)
- use constant state instead of the resource type value for checking if we can
preload the drawable
- fix typo
Change-Id: Idd64caf0fbe0f5cfd5ffe09343e84bafa9446ea5
Redesigned how ViewRootImpl delivers input events to views,
the IME and to native activities to fix several issues.
The prior change to make IME input event delegation use
InputChannels failed to take into account that InputMethodManager
is a singleton attached to the main looper whereas UI may be
attached to any looper. Consequently interactions with the
InputChannel might occur on the wrong thread. Fixed this
problem by checking the current thread and posting input
events or callbacks to the correct looper when necessary.
NativeActivity has also been broken for a while because the
default event handling logic for joysticks and touch navigation
was unable to dispatch events back into the native activity.
In particular, this meant that DPad synthesis from touch navigation
would not work in any native activity. The plan is to fix
this problem by passing all events through ViewRootImpl as usual
then forwarding them to native activity as needed. This should
greatly simplify IME pre-dispatch and system key handling
and make everything more robust overall.
Fixed issues related to when input events are synthesized.
In particular, added a more robust mechanism to ensure that
synthetic events are canceled appropriately when we discover
that events are no longer being resynthesized (because the
application or IME is handling or dropping them).
The new design is structured as a pipeline with a chain of
responsibility consisting of InputStage objects. Each InputStage
is responsible for some part of handling each input event
such as dispatching to the view hierarchy or to the IME.
As a stage processes an input event, it has the option of
finishing the event, forwarding the event to the next stage
or handling the event asynchronously. Some queueing logic
takes care to ensure that events are forwarded downstream in
the correct order even if they are handled out of order
by a given stage.
Cleaned up the InputMethodManager singleton initialization logic
to make it clearer that it must be attached to the main looper.
We don't actually need to pass this looper around.
Deleted the LatencyTimer class since no one uses it and we have
better ways of measuring latency these days using systrace.
Added a hidden helper to Looper to determine whether the current
thread is the indicated Looper thread.
Note: NativeActivity's IME dispatch is broken by this patch.
This will be fixed later in another patch.
Bug: 8473020
Change-Id: Iac2a1277545195a7a0137bbbdf04514c29165c60
Don't install packages where we have multiple, conflicting
<uses-permission> lines for the same permission.
For example, a package which contains:
<uses-permission android:name="android.permission.INTERNET" android:required="false" />
<uses-permission android:name="android.permission.INTERNET" android:required="true" />
will now fail to install.
In addition, this change slightly refactors the code, and creates a new
parseUsesPermission() method.
Change-Id: I0f4bb8b51dc4a0c5b73458a70f706e19829275d2
Don't honor <uses-permission android:required="false"> on older apps.
Lots of apps in the wild are improperly using this, and we don't
want to break them.
Bug: 8528162
Change-Id: I6e0a10bc9feac58d13ef624239c6b91e9fc34590
