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
Lots of code refactoring, include:
- no longer watch for on-link proxies (only routers and DNS servers)
- keep track of NUD state of neighbors of interest
Bug: 18581716
Change-Id: Ia7dbef0690daf54f69ffecefc14e1224fd402397
If the app tried to do various things with too much data --
starting an activity, starting a service, sending a broadcast --
this would fairly silently fail with little indication of what
was going on. Fix this in two ways:
- Now when the native code generates a TransactionTooLargeException,
it may include an additional message in it telling you how much
data was in the parcel being sent, to help you understand why
this happening.
- In all the framework code paths where we call to the system and
may fail, convert these failures into a a runtime exception and
rethrow them back to the app so that it will clearly get the
above message.
Change-Id: I745159b97d3edb6fca86aa09cbc40c1f15a7d128
This adds a new ActivityOption for the caller to ask the
system to track the time the user is in the app it launches,
delivering the result when they are done.
The time interval tracked is from when the app launches the
activity until the user leaves that app's flow. They are
considered to stay in the flow as long as new activities
are being launched or returned to from the original flow,
even if they cross package or task boundaries. For example,
if the originator starts an activity to view an image, and
while there the user selects to share, which launches gmail
in a new task, and they complete the share, the time during
that entire operation will be included.
The user is considered to complete the operation once they
switch to another activity that is not part of the tracked
flow. For example, use the notification shade, launcher, or
recents to launch or switch to another app. Simply going
in to these navigation elements does not break the flow
(although the launcher and recents stops time tracking of
the session), it is the act of going somewhere else that
completes the tracking.
The data is delivered to the app through a PendingIntent,
which includes the total time the app was in the flow along
with a time break-down by app package.
Change-Id: If1cf8892d422c52ec5042eba0e15a8e7e8f83abf
Previously getHomeActivity() returned the topmost home activity
independent of which user was currently running. That defeated the
purpose of the method. This fix returns the home activity of the
current user or null if one has not yet been created.
Also remove some cruft that accumulated.
Fixes bug 21055376.
Change-Id: Ic1d58129aedbe3624f8a9d12c05c84674687b0a4
As per API council request, factory methods should be used instead of using
boolean.
Bug: 21343772
Change-Id: Ia0889e46916f4ed7edb942217880cdf9c27771c2
This is a follow up CL for I219394178e4172bc47864297f1418e677dba.
As explained in the commit message of I219394178e4172bc47864297f,
IMM#mCurRootView needs to be synchronized with the actual window
focus more precisely to fix Bug 20820914. Hence we should not
clear IMM#mCurRootView in IMM#finishInputLocked() anymore.
Ideally this CL should have been included in the previous CL.
Manually tested following scenarios.
- Repro steps in Bug 6413553. Made sure that IMM#mCurRootView
is cleared after switching back from the current application to
the previous application with back key.
- Test application that calls WebView#showFindDialog(). Made sure
that LatinIME works fine when switching text fields. This is
non-trivial because android.webkit.FindActionModeCallback is
changed in the previous CL I219394178e4172bc47864297f1418e677db.
- Repro steps in Bug 21144633. Made sure that we can enter
recipient's name in the messaging app.
This CL depends on I219394178e4172bc47864297f1418e677dba25e5.
Bug: 20820914
Change-Id: Id6afc8fc64512225578c62557b96c7dc2e969adf
Currently was using toString(), switch to "flattenToString" so it is
consistent with the call log.
Bug: 20954214
Change-Id: Ia9ed67bf463e4a2d4d9a02e00243d49238be17fe
