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
The root cause of memory leak crbug.com/595613 was that Chromium and
WebView have called InputMethodManager#showSoftInput() with
ResultReceiver thta has a strong reference to application logic class
named ContentViewCore. In this particular case, ResultReceiver in
question will be copied to InputMethodManagerService and the current
InputMethodService, which means the original receiver object will not be
collected until the copied objects in other processes are GCed.
Probably there might be several ways to oprimize the performance in
Framework side because the corresponding ResultReceiver objects will be
always handled within the Android Framework unless IME developers
explicitly override the following method.
InputMethodService#onCreateInputMethodInterface()
Anyway, it is probably a bit too late to do such an optimization in N,
and application developers need to support existing versions of Android
anyway. For N, probably making it clear in JavaDoc would be the only
realistic improvement we can do.
Bug: 27658034
Bug: 27727645
Change-Id: I6fc6b88c91a4b1e0a29e94b99a9f0e35605c01b2
Helps avoid a continuous launch cycle if a resolver activity resolving
the home intent is the only activity in the system and the lock screen
is up which will put the activity in the stopped state. The activity
then finished itself onStop, but is then relaunched by the activity
manager since there are no other activities in the system and the
home activity should be present.
Bug: 27674536
Change-Id: Iaca67a00c4a37f70aafd18aedcbd8dba2f561203
Add a (configurable) delay between when we start a maintenance
window until the minimum time we will end it.
Also switch to using the alarm manager callback API. (Yay!)
Also fix a little printing problem in the alarm manager dump
so we put the package name and not some class hash in the
summary string of an alarm entry.
Change-Id: I4281e5c80bc8b26ebc1fb6f603ec33ec0e379daa
