Note that operators that wish to show "4G" instead of "LTE"
on these networks can set config_show4GForLTE to true.
Bug: 9265513
Bug: 9265217
Change-Id: If7f3580da7266b0d0c62639e30684393d4e03392
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
We do a lot of launch-app-then-collapse, and it's a game to
see whether the app's window activity animation starts
before the panel has a chance to finish collapsing.
The winning move here is not to play.
Requires change I2773601d in f/b.
Bug: 8666124
Change-Id: I3e3f1c5a4a505ad7d487c804139445ffd499d8d4
Previously, our method of announcing the expansion of the notification shade
and quick notification shade relied on populating a contentDescription
attribute on the highest-level container. This behavior is incorrect as it
causes accessibility services to infer importance and assign the view
accessibility focus. This change adds descriptive text to the
AccessibilityEvent fired when the shade opens without modifying the
container's description.
Bug: 8699624
Change-Id: Id909b60d63cdec96c307dea2624b0651ab4f1f36
Previous work in ImageWallpaper cached the bitmap for a user
to avoid reloading it (an expensive operation on large-display devices)
when we could simply re-use it. User switching still caused a reload, however,
since the place where we cache the bitmap (ImageWallpaper) is in an instance
that is re-created on user-switch.
A simple fix is to have the ImageWallpaper stop telling the WallpaperManager
to erase its own cache of the bitmap prior to re-loading it. That step is
unnecessary, since a bitmap that is cached can be assumed to be valid. A wallpaper
change will correctly null out that cached version, so if the cached bitmap
is non-null, then we can simply use it as-is.
The fix is to remove the call to forgetLoadedWallpaper() and allow the caching
mechanism to do its job.
Issue #7986933 user switching on lock screen is slow (sometimes like molasses)
Change-Id: I447754ab85337bc8ae59b4ad6c3e6c2b30e13735
- Wrap all public member variables in getters and make
slots private
- Rename clear* methods to cancel* to be more consistent
with existing public Notification API
Bug: 8656860
Change-Id: I84f7e71fbb627f859352a93089c6a531b44dac95
Fixes the problem where Settings->Display->Brightness for secondary users stopped
working after the reorganization of brightness dialog.
Bug: 8666220
Change-Id: I893954810f80383090733fc677266bfcad490703
The chief motivation here is to allow two lines of text when
necessary. So much refactoring over so small a thing, but
the result is satisfying: most quick settings tiles do not
need their own layouts. Additionally, tiles with odd-shaped
icons (I'm looking at you, alien potato mode) no longer fall
off the grid.
It should be possible to further reduce the complexity of
quick settings, but for now this will suffice.
Bug: 7216734 // vertical alignment issues
Bug: 7216868 // wrap text in QS tiles
Bug: 7365911 // NPE in some tiles
Change-Id: I0c6ef275e44f745dfac52c2a7303072ae48e3873
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
Fixes the KEYCODE_HOME case, awakes when home is
started for any reason.
Also awaken when toggling recents (and not locked).
Bug:8557212
Change-Id: I6578ae3971740a03c27596b838d27a5ab9b03752
This is the best and only way for apps to listen for
notifications: create a NotificationListenerService, wait
for the NoMan to bind to you (as a result of the user
checking a box somewhere in Settings and agreeing to a
scary dialog box), and you'll start receiving notification
posted and dismissed callbacks. Your service, while enabled,
will also be able to clear one or all notifications.
Use this power wisely.
This change moves StatusBarNotification out of
com.android.internal into android.service.notification.
[Internal customers, including System UI and early users of
the system-only listener binder API, will need to be
updated.]
Bug: 8199624
Change-Id: I1be46f823d4b3ddc901109ec1e085cd6deb740c2
Make sure that apps that have access to restricted accounts can see them.
If they don't have access, they shouldn't be able to add a new account either.
Show an error message in the account picker if the user/app is not authorized.
Change-Id: I117c0b14d7d06c5ac4e66506df156b174567f5f3
A previous fix made initializing GL work better by calling eglMakeCurrent()
prior to querying the max texture size. However, that fix worked by creating an eglSurface
earlier than we did before, which for some reason causes problems later if wallpaper creation
fails and we back off to a software solution.
This new fix creates a temporary pbuffer surface instead, which still allows us to make the
call to eglMakeCurrent() prior to querying the max texture size, but does not result in the
later canvas lock failure if the wallpaper creation fails anyway.
Issue #8319960 sluggish yakju animations over launcher
Change-Id: I394d672549260a354f03ad9fd1b9e1f9a161a371
ImageWallpaper was sometimes querying GL for a max texture size too early
(before the first call to eglMakeCurrent()). This problem caused the wallpaper
to then get created in software, resulting in noticeably slower performance
when the wallpaper was visible.
This fix ensures that the
makeCurrent happens before the query, ensuring that wallpapers of the right
size actually get created instead of failing due to this error at creation time.
Issue #8319960 sluggish yakju animations over launcher
Change-Id: I12a3eba9f1818bdf544691e0727fe12f7e820651
"[+>" more icon was never show in status bar because
the member variable for this icon was not initialized
from resources. This fix enables "[+>" icon to appear
in status bar when the number of indications in status
bar becomes large.
Bug: 8368569
Change-Id: Ieb3412eed831052d69c0cf63c9b4230c38171e4a
The normal LTR Recents interface in landscape
actually scrolls/behaves like a RTL interface,
so we hardcode the layout to stay the same in both
modes
Change-Id: I57e5e76de3260c6de1dd9e939797b7e1c23cca03
Once these get into the Animators, they freeze up and
disable the whole notification panel. Not cool.
Bug: 7686690
Change-Id: I04567417b3840a82d9cfe071c601e3078b2e3fe3
