In framework views where we're handling the new visibility aggregated
call we only update the drawable visibility when we're attached to a
window. For old outgoing drawables being replaced, gate this on
whether the drawable is already marked visible instead.
This catches a case where views being inflated might set drawables in
in a superclass constructor and have them replaced in a later
constructor. Gating the call into a drawable that might invoke its
callback (the view being constructed) avoids potential problems where
overridden methods are called unexpectedly on a view subclass that has
not finished running its constructor.
This is a better check than isAttachedToWindow, as isAttachedToWindow
will return false if the view has been temporarily detached from its
parent by a view-recycling container. In those cases, the view would
not correctly update the outgoing drawable.
Bug 27461617
Change-Id: I733a2dd3e3df0a8d80d5dc542ca7b30064159d5d
This causes scaling to be applied in the relayout window since the
requested size won't match the window size. Apply the requested size
in repositionChild instead.
bug: 27676101
Change-Id: I03beee2b9fe118a6be329b5fd1338d54e48d9a22
Right now we pass all services, characteristics and descriptors one by one.
This patch changes that - now we pass whole GATT database at once.
Bug: 27455533
Change-Id: Ie42cd80072538e411904b9c9b011a978f26158b9
The previous default location of "/sdcard" became painful to use
starting in M, because it required a runtime permission. So now we
default to storing trace files in app-specific directories on shared
storage, which apps always have write access to with no additional
permissions.
Update docs to be consistent between all overloads.
Bug: 22807654
Change-Id: If4feca7c8778dfdf4ccce8cfb68418dc416260b5
A new addLinks function is added that accepts a default scheme and a
set of known schemes. Default scheme is applied whenever the link found
does not start with one of the given known schemes.
Moreover, previously JavaDoc for addLinks functions with a single scheme
parameter described that the scheme attribute will be prepended to the
links that do not have 'a' scheme. The code actually checks if the link
starts with the given scheme and prepends if not. JavaDoc updated
accordingly.
Bug: 26985901
Change-Id: I94ea81dcf83ba7a6b6cd47c10fe8fb277964eb15
Previously, we show launcher when keyguard is dismissed.
It introduces these issues:
1. There can be no device lock
2. user could take a quick peek of the work app
Current behavior:
1. We now show launcher once the work profile is locked.
2. Lock profile immediately if there is no device lock
3. Add cancel "lockProfileLater" logic
Bug: 27241680
Bug: 27673460
Change-Id: I765aa22d4c8ae5017c1611f5a340a4b33d463b1e
