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
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
This new test is required since the suggestion popup is now triggered by a
Runnable. We have to make sure there is still at least one SuggestionSpan
at that position.
Change-Id: I5c84ba0ca412f51a0201bee5c2e63b5bd3717338
Bug 5916225
Duplicates were removed when received from SpellChecker, in a way
that could move the top candidates lower in the list.
Moved that code to the part that creates the actual suggestion list,
to make it more generic. The order of the first SuggestionSpan is
guaranteed to be respected.
Also mentionned non null suggestions and fixed a problem in SuggestionSpan
constructor.
Change-Id: Iaa3b1b84ae512451e439e5c5e63448c2a19145b5
o Add NdefRecord.toMimeType()
Maps the record to a MIME type
o Add NdefRecord.toUri()
Maps the record to a URI
o Add hidden NfcAdapter.dispatch()
Helps test the dispatch path.
o Modify createMime(), createUri() and createExternal():
Do not try and strictly follow RFC requirements for URI or MIME content
types. This just leads to heartbreak - the RFC requirements are too strict.
For example RFC1341 forbids the use of '.' in a MIME type, however this is in
common use in types such as "application/vnd.companyname". I think the best
approach is to only remove 'obvious' whitespace issues, and to convert
uppercase to lowercase as per Android guidelines.
Change-Id: Id686f5f3b05b2dceafad48e1cfcbdb2b3890b854
Helps developers create well-behaved intents:
- lower case MIME data type
- strip parameters from MIME content types
- lowercase URI scheme
The new API's are
normalizeAndSetType()
normalizeAndSetData()
normalizeAndSetDataAndType()
Uri.normalize()
normalizeMimeType()
Change-Id: Ib5c907897f39b1f705bcc4c9103ba1e6f316380b
