Previously we were only partially transforming the focus rect into
window coordinates, so it was offset when the window was panned (for
example, when the IME was showing).
Bug: 20113389
Change-Id: I41f5ed20cb1404232b7042d37ca2fc725f9ee476
Hide the floating toolbar when the content rect is outside the
source view's visible area.
Bug: 21304845
Change-Id: I0dd10ad2cda7a8d9b05c81334cdfbd68c22dbc6a
- Track the calendar provider for the managed profile user if found.
- Add userId to the shared data structure to disambig calendar ids.
- Delay rule update a bit to guard against chatty updates.
- Fix logging in calendar rule.
Bug: 21155107
Change-Id: Id2303fcc39b1fa7417b1844b7869d773ef92434c
Changed name of service to avoid using the actual class name
ChooserTargetService as the example service's name.
Issue #21418354 Clarify doc example for ChooserTargetService
Change-Id: I59bf67299fe7a8307504baf5e999c14f84a1e50d
Fixing lots of bugs related to the ChooseAccount Activities.
1. Fix jank which is seen when no accounts are present on the device.
2. After addition of the account, return to the user.
3. Don't crash when the user provides null to allowableAccountTypes.
4. Updated documentation of AccountManager#newChooseAccountIntent.
5. Fix NPE.
Bug: 13104800
Bug: 17926560
Bug: 9626001
Change-Id: I0d1913e46560cfb458526a7c930a38049602d8f1
When we update drawable visibility has changed to be part of
View.onVisibilityChanged instead of an overload of
setVisibility. While this covers more cases that we were previously
missing, it also means that we now set drawable visibility from the
View constructor via the call chain view.setFlags to
view.onVisibilityChanged to drawable.setVisibility, resulting in us
passing a 'this' pointer all over before the object is fully
initialized. (i.e. a Bad Thing.)
In general we've gotten away with playing fast and loose with this
sort of thing as a part of view inflation - calling various non-final
setters that may invoke callbacks as needed rather than initializing
view fields directly. Unfortunately it also means that we can cause a
lot of hard to trace bugs and in the long run we should try to clean
up as much of it as we can.
In this case, some apps were expecting inflation to have finished
completely before any drawable visibility changed. If a view's
visibility changes but it's not attached to a window, does it make a
callback?
The fix: no. We won't dispatch onVisibilityChanged to detached views,
but we will dispatch it when a view becomes attached.
Also fix a bug where we could end up telling a view its visibility
changed to (INVISIBLE | GONE), which just doesn't make any sense.
Bug 20103422
Change-Id: Ifba54c36114e85cf64869afcca766c30d601a16c
