In the past it's been a recommended approach to avoiding overdraw for
apps to set their window background to null at runtime if their
content view fully covers their window surface. The problem with this
is the IME.
The IME can force a resize of the window at unexpected times and
unless an app has been configured to fit system windows and manually
cover the padded area that the IME window covers, the asynchronous
nature of the IME-show process can leave surface buffer garbage
visible to the user. In previous platform versions this wasn't an
issue since pre-renderthread we would always animate a crossfade from
the closed to open state. This animation was always a bit of a hack
since it could break the contract of requestLayout/invalidate on the
view hierarchy - it could result in a draw happening into the saved
"before" state of the crossfade before a pending layout.
Now that this has been cleaned up the buffer garbage is sometimes
visible.
To prevent this, PhoneWindow now detects the state of a null window
background and draws solid rects into the area not covered by a
window's content. Which color is determined by the window context's
theme, though this is not a public API available to apps.
Bug 17006497
Change-Id: I714439a1608c4ae135f3d9d49bb165330d9fbe9f
ActionBarContainer was setting the bounds of its background assuming the
visibility of the ActionBarView. But that view becomes GONE when the
ActionBarContextView is visible, causing artifacts such as wrong shadows
when resized (as in custom configuration changes).
Issue #17280341 Quantum: drop shadow on CAB has wrong width after rotation on L, when configuration change is handled by the app
Change-Id: I07e57f00e27b41d5370cb9440b35734a8ec10f3a
Sometimes the pipe has been closed when it's thread tries to access
E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: TransferPipe
E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method 'java.io.FileDescriptor android.os.ParcelFileDescriptor.getFileDescriptor()' on a null object reference
E AndroidRuntime: at com.android.internal.os.TransferPipe.run(TransferPipe.java:184)
E AndroidRuntime: at java.lang.Thread.run(Thread.java:818)
Change-Id: I0fcd4a3334b49972903f2cb0edb51323ba3f49e5
Previously the system tried to enable at least one auxiliary IME
even when the system is not ready. However, this doesn't make
much sense because the user should be able to set up their phone
without auxiliary IMEs. Also, IMEs enabled before the system
becomes ready are kept to be enabled after the system becomes
ready. Thus, we should minimize the number of enabled IMEs
until the system becomes ready.
BUG: 17347871
Change-Id: Ife93d909fb8a24471c425c903e2b7048826e17a3
- Changing package from android.telecomm to android.telecom
- Changing package from com.android.telecomm to
com.android.server.telecomm.
- Renaming TelecommManager to TelecomManager.
Bug: 17364651
Change-Id: I192cb5d189f55db012ea72ee82ccc5aedbc21638
This gets rid of the spam from the battery history, by not creating
an event unless the wall clock time has changed by more than
+/- 500ms.
We'll do the remaining work in MR1.
Change-Id: I8d1cc41b5504261033d3b0ccdcf9e7cf70df9d04
Basically this CL does following clean-ups as groundwork.
- Embed isDefaultEnabledIme into its only one caller
- Fix a typo in isSystemAuxilialyImeThatHashAutomaticSubtype()
- Use exit-early style in getMostApplicableDefaultIME()
No behavior change is intended by this CL.
BUG: 17347871
Change-Id: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
Right now different code in System UI, Settings app and other places replace the
user icon with their own default. This tries to make it consistent by moving the
mechanism used in Settings in a helper class.
Bug: 17311038
Change-Id: Ic858c65bf82a98b9806dbba029e7cdcf441f372e
This CL removes old API signatures marked as @removed
in the follow CLs.
- Ic8c6fab58c01206872a34e7ee604cdda1581364d
- Ia8cbb9f6b41cd9509fc0147fd68763dfde593ffc
- I772c48ff18918e48a81e807b48ff907614485c09
This is just a clean-up CL. No behavior change is intended.
BUG: 17200900
BUG: 17320996
BUG: 17365414
Change-Id: Ibfbd5cc1cdebb8851c73477cff55c9b2d631fdea
On the minimal framework start, don't mark ro.runtime.firstboot, allowing
the real framework to properly create the dropbox files in the real /data
Bug: 17450632
Change-Id: Ic53b3471b44e69f3eea7e3f3de18e789f51192bc
...hundred milliseconds.
Rework the locking so that no critical paths block on the cpu collection.
Change-Id: Ie615a033f7f8b523b67abee62c581d1a8fce324c
Equivalent behavior, improves performance since
Object.hashCode has a fast path in the java side that does not
require JNI.
According to traceview sampling profiler:
Calendar had 6.8% time in System.identityHashCode during launch.
0.4% time in System.identityHashCode after the change.
Bug: 16828525
Change-Id: I1ed1d1283a990f990b0d4352cc1f4822b1dadf7b
Switch back to using a list as the grid and differently positioned
activity icons were confusing to users. Keep the distinct "last used"
presentation but align icons and titles with the further choices
below. Adjust this to make the fold more apparent. Remember
open/closed slider state across config changes.
Fix some bugs in nested scrolling and flinging.
Bug 17301272
Change-Id: I175937d5821df27b6ac7ffad7f01cd9a6ed3e3e3
For restore use-case, session creation needs to complete quickly, so
delay ASEC allocation until session is opened. When preflighting
size checks, only consider external when we have a known size for the
container. Also relax size checks when using MODE_INHERIT_EXISTING
on external, since we don't know how much of existing app will be
copied over.
Consider session as "active" while commit is ongoing, until we're
either finished or pending user interaction.
Always publish first client needle movement away from 0. Use 25% of
internal progress to reflect ASEC allocation.
Avoid CloseGuard messages about leaking PFDs.
Bug: 17405741, 17402982
Change-Id: I6247a1d335d26621549c701c4c4575a8d16ef8c2
Dumb, dumb, dumb mistake.
Also fix battery stats wakeup reason tracking to use a SamplingTimer
(like kernel wake locks) so we can track both the duration and count
for each wakeup reason.
Change-Id: I89d69661006dc533622b1b7e68a139166d3a6975
Pass through the menu mode change events and make sure Activities get
prepare/open/close events properly.
Bug 17326424
Change-Id: I0ac2f56e4d0054ef01720b2ff1c41ded053750c7
Wire through the callbacks that result in onPrepareOptionsMenu being
called properly when an activity overflow menu is opened.
Bug 17326424
Change-Id: Ifc5b67af0d215f210bb00326f82f60ba55a36d52
In an effort to reduce glyph proliferation, change the "done"
checkmark from the CAB to the up-navigation arrow, placing the CAB
firmly in the current navigation hierarchy. This matches behavior for
expandable action views such as SearchView.
Allow the use of different CAB "done" layouts by theme; the material
layout should not include the "done" text and should use the standard
borderless selectable item background.
Bug 17372188
Change-Id: Icfb3e0bbc6a718e22ab27f9d520da5fe4eb833e7
The isGrayscale family of methods is designed to identify
drawables and bitmaps that apps are using in the largeIcon
position to pose as small icons in order to get the
appropriate background treatment (a solid blue or gray block
in KK/JB, or geniune selvedge denim in ICS/HC).
We can optimize this search two ways:
(1) Reject immediately any largeIcon that is larger than
largeIcons should be (64x64dp). We could one day simply
reject, or resize, these in the notification manager,
but regardless these are not plausible smallIcon
subsitutes. This new constraint is commemorated in the
new name, isGrayscaleIcon().
(2) Shrink the bitmap even smaller before scanning it slowly
in Java. This lets native_drawBitmap do the heavy
lifting across the entire bitmap; we need only scan a
few pixels.
Bug: 16513124
Change-Id: I3a2b79130ed2465a4aedfbb5a556db7f8a7aa132
This CL does nothing but rename some L API candidates
in InputConnection class, as per requested.
- requestUpdateCursorAnchorInfo()
-> requestCursorUpdates()
- REQUEST_UPDATE_CURSOR_ANCHOR_INFO_IMMEDIATE
-> CURSOR_UPDATE_IMMEDIATE
- REQUEST_UPDATE_CURSOR_ANCHOR_INFO_MONITOR
-> CURSOR_UPDATE_MONITOR
BUG: 17320996
Change-Id: I772c48ff18918e48a81e807b48ff907614485c09
If the developer hasn't set a navigation content description on the
Toolbar assigned to be an action bar or a home-action content
description via the ActionBar interface, use the framework default
"navigate up" string.
Also make sure that the default Up description is supplied in the
screen_toolbar window decor layout and that it is parsed properly in
all toolbars, even if we don't have an icon set during construction.
Bug 17298370
Change-Id: Ie2f9e34f92046d4d4ffb9a07e38fa89581891f7b
- Fix documentation to mention units of time in APIs.
- Return a Map instead of an ArrayMap
Bug:17289531
Change-Id: I0a2cfdc0bc003eeeb65a16e37bb7b991624b2853
Currently EditableInputConnection#requestUpdateCursorAnchorInfo
never returns false unless InputMethodManager is somehow
unavailable.
This is problematic, especifially when we add a new flag to
EditableInputConnection#requestUpdateCursorAnchorInfo in a
future release.
With this CL, #requestUpdateCursorAnchorInfo does nothing and
immediately returns false when one ore more unknown bits are
specified.
BUG: 17324806
Change-Id: I5601714b481e8efa0ad3337c0d093cfcf55eade3
It would be good to actually bring the task to the front.
Also, make the flow when inTask is provided better match what happens when
we go looking for a task on our own.
And this includes another fix that was supposed to be part of a different
change but I forgot this class is part of the framework project now.
Change-Id: I3cf05f2e585c0fd7a0dbb7c7cf9fb1655764dd93
