Let HAL implementation tell if geofencing/batching is
supported and which technologies (GNNS, wifi, etc)
can be used.
Still todo: Add ability for GmsCore geofencing to
tell which technologies are supported (instead of
just using it to update monitoring). This requires
SystemApi change + approval so will do in separate CL.
Note that the classes in the lib are not copied
directly into GmsCore. The instance will always
be whatever is in the platform. This is why
the callback is backwards compatible as long as
their is a default implementation (but not if
it's abstract).
Change-Id: I7d6adeb049b89935bc4443785df5d7ef4c730e5d
The paint of a layout may be reused with other things (in particular,
it can be passed to a BoringLayout), so make sure the hyphenEdit is
zeroed out after use.
Change-Id: If58c5588af9642c3ba827acefea7895e814daab9
The same behavior can be achieved by using a predraw listener, which
can be removed while the callback is called, so it doesn't crash.
Change-Id: I3a7138ba49936159dc95b7758c9603366dcf808c
crash info
Symptom:
This issue happens because the ANR process got killed
(because it crashed) before the ANR dialog dismissed.
In that case, the process record is marked as crashed
(ProcessRecord.crashing = true). When the ANR dialog
dismissed by user, it will cause NullPointerException
when writeToParcel while performing IPC because there
is no crash info (ApplicationErrorReport.crashInfo = null)
Solution:
Check crashinfo before access it
Change-Id: I2995de57684c1e13aab8297f5eea1e82ca3b7ad8
- add private API PackageManager.getAllIntentFilters(String)
for getting all IntentFilters from a given package
- update IntentFilterVerificationInfo to use an ArrayList<String>
for domains instead of a String[]
- if you make an App a default domain handler then make the
others as non default
- create an IntentVerificationInfo even if the App IntentFilters
do not need to be verified. This would be done only if the App
has some domain URLs defined and would allow to make it the
default handler for a domain
- a few code optimizations here and there
Change-Id: I4535372a0bb1a2c8e662e1485be8ca700003e9b3
Chnages to the ActionBar are now tracked so that new items,
items that go away, and items that change location are now animated into
their new state.
Issue #10863316 action bar items don't fade in correctly
Change-Id: Ia956b2b76958f02108c756dab2d1c2617a5904dc
The Choreographer carefully schedules animation updates to occur
after input but before traversals occur. This ensures that the
effects of animations are perceived immediately in the next frame.
The start time of animation is usually set the moment the animator
first runs. The start time serves as a reference for timing the
remainder of the animation.
Setting the start time during the animation callback works well except
when traversals take a long time to complete. In that case, we may
end up drawing the initial frame of the animation then skipping several
following frames (because a lot of time has already passed since the
animation start time was set), effectively shortening the duration
of the animation.
To resolve this issue, we introduce a new COMMIT phase within the
Choreographer. The COMMIT callback runs after traversals complete
and may provide an updated frame time that more accurately reflects
the time when the frame finished drawing.
In the case where an animation is just starting, we note the fact
that its initial start time has not yet been committed (the user
hasn't actually seen anything on screen yet). Then, during the
COMMIT phase, we adjust the animation start time to better reflect
the time when the animation's first frame was drawn, effectively
causing the animation actually start after the expensive traversal
operations occurred such that no frames will be skipped.
Bug: 17258911
Change-Id: I279603d01fd4ed1de8f51a77c62f4fec5e9b746a
Since there are no third-party apps expected to be using the visual
voicemail related apps at the moment, best to keep these hidden for now.
Bug: 19236241
Change-Id: I86f622208efcc89fab523f03d2bb70c244cdf867
