BUG=5614887
This fixes a timing issue where we could calculate a delay of 0 (indicating
wait forever) when we have no pending commands to actually execute. In such
cases, we should just break out of the playback loop.
This also fixes a small issue with returning whether or not to redraw.
Change-Id: Id1e481679341773256b7287062c68925e2bc8f9e
Was a mix of audio_source_t, uint8_t, and int.
Related fixes:
- fix comments in MediaRecorder.java
- AudioPolicyService server side was not checking source parameter at
all, so if the client wrapper was bypassed, invalid values could be
passed into audio HAL
- JNI android_media_AudioRecord_setup was checking source for positive
values, but not negative values. This test is redundant, since already
checked at Java and now checked by AudioPolicyService also, but might
as well make it correct.
Change-Id: Ie5e25d646dcd59a86d7985aa46cfcb4a1ba64a4a
Remove NdefMessage from dispatch(). It's already in the Tag.
/*package*/ cleanup
Fix sitemap after removal of NFCDemo
Change-Id: Ie1f6d9ea98144aa97f56bb709a33f5d0ef916e8b
The comment of this field is also aggregated in the android.R.styleable#View
description. As a result, the @deprecated in the comment of this field also
applies to android.R.styleable#View which incorrectly appears deprecated.
This fixes the problem, although fadingEdge will no longer be marked as
deprecated in IDEs. I believe it is less important that to make View
deprecated.
Change-Id: I96d8e868001c4c853eb1536f8401275b9b1e689b
Previously, we'd pass in a scale factor (based on whether the app was
being scaled by the compatibility mode) to Animation.getTransformation().
This scales the pivot point of the animation based on thes cale factor.
However, the pivot points were already using information that took the
compatibility mode scale into account. For example, using ABSOLUTE and basing
pixel values on the width/height of the view would give you values relative to the
width/height of the view (pre-scaled). Using RELATIVE_TO_* would use percentages
for the pivot point, again taking the scaling of the view into account. So scaling
the pivot point added in another scale on top of that already being applied.
The net effect was to scale the pivot point in cases where it should not be scale.
For example, setting a pivot point to half-way (.5 and RELATVE_TO_SELF) would
end up with an animation that would pivot around the bottom/right of the view.
The fix is to simply remove the scale factor being passed in; we've already accounted
for it in the pivot point, so we shouldn't concatenate it into the transform
calculated by the animation.
Change-Id: I9daa7581b1b9d0dfb10515e96947160c28c5130e
Carrier name is shown if
- in service and connected to mobile data
- in service and connected to wifi
Carrier name is blanked if out of service and connected to
wifi.
"No internet connection" is shown if out of service without
any other route.
Bug: 5903914
Change-Id: I59d4d0c90e4153d73c38f7f0e150becf7e021a5b
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused. Also note that at the end the View did not
clear its focus, hence no focus change callbacks
should be invoked.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
This fixes a bug where the device would show pattern unlock after the user
entered the SIM PUK unlock code. The code now correctly determines that
the device isn't secure and thus shouldn't show the unlock screen.
Change-Id: I49fd749592154a4c5840038b92d54ca7ca086074
BUG=5888007
rsAtomicMax/Min did not have proper semantics for unsigned integers. They were
always using signed comparisons. rsAtomicCas had the wrong function signature
in our math library, leading to no way to properly link/execute it.
Change-Id: I336cdd8cd9f2d8093f12e101b55b2797515f039b
