Activities can be of various sizes in a multi-window environment.
This change allows them to have override configurations that allows
different resources to the loaded if needed.
Bug: 19002213
Change-Id: Ib2c7be0b427f5ce05e7a362bcdd496ddbc9164f0
CHANGE
isInsert, isDelete, isUpdate, isAssertQuery
JUSTIFICATION
The use of getType() in lots of unit tests means that
ContentProviderOperation#getType() can't practically be
removed.
Why not make it public? This allows 3p to use getType() in
unit tests. Plus it allows the unbundled contacts app
to continue using getType() in order to handle TYPE_INSERT
specially, without needing to awkwardly pass isInsert values
around.
Bug: 18777272
Change-Id: I6be5f325bbf6fbeb7817e9b1f7fa1a1ae2002e0b
CHANGE
isInsert, isDelete, isUpdate, isAssertQuery
JUSTIFICATION
The use of getType() in lots of unit tests means that
ContentProviderOperation#getType() can't practically be
removed.
Why not make it public? This allows 3p to use getType() in
unit tests. Plus it allows the unbundled contacts app
to continue using getType() in order to handle TYPE_INSERT
specially, without needing to awkwardly pass isInsert values
around.
Bug: 18777272
Change-Id: I3265193cda0c9405f6df896cd96a10df7225445a
Issue #18983662: API Reivew: clarify Intent docs for URI_ANDROID_APP_SCHEME
Issue #19019830: Bump up battery stats checkin version
Change-Id: I0bd8f32b9d8d5978bd01d421ea2232d20def340a
Establishes a clear contract regarding when exceptions will be thrown,
when default values will be returned, and when values will be coerced
to a different type.
Since we have both getInt() and getInteger() where one handles coercion
without throwing an exception, it seems reasonable that we should clearly
document the behavior so that developers can make an informed decision.
Once we document the behavior, there is no reason to log warnings on
coercion. If a developer chooses to use a particular API or data type,
that is still correct according to the API.
BUG: 18625719
Change-Id: I385f0b719182d3c0358943e1d6c3d7bedc756eb5
We insert null entries on cache miss, which can cause NPE on prune, but
we ought to remove these entries during prune.
BUG: 18842826
Change-Id: I9c0bca04f34575d1403de943abd8d12b18c9c032
Symptom:
Assume a foreground broadcast FG and a background BG.
If a recevier registers both FG and BG. When sending
BG and FG to the receiver, and the receiver BG receiver
completes first, its finishReceiver will trigger next FG
receiver rather than BG, and also deliver wrong result
code/data to the next.
More detail and sample:
https://code.google.com/p/android/issues/detail?id=92917
Root cause:
Due to BroadcastQueue:getMatchingOrderedReceiver will match
by receiver(IBinder), so the caller ActivityManagerService:
broadcastRecordForReceiverLocked will always match the first
queue(fg) if a receiver is both receiving fg and bg.
Solution:
Add a parameter flags to finishReceiver, then server side
could know the finished receiver should belong to which queue.
Another general solution but with bigger scope:
I60dce4a48e20c1002a61a979e4d78b9b0a8b94a0
Change-Id: I913ca6f101ac8ec6c7a8e42754e6781f80247b7f
This prevents our lint tooling from complaining that we're passing
invalid values when trying to get the MediaProjectionManager.
Bug: 18830590
Change-Id: I34633248e895b0ac7f5083e18a7d2385ca6f8adb
...testCallActivityOnNewIntent test fails with LMP-MR1 Release.
Check for null.
Also fix some small issues with converting intents to/from intents.
Change-Id: Ic391cc57552635935af9a271b2d09353257f6d14
Still to do:
Add MidiInputPort and MidiOutputPort classes
Schedule sending MIDI events in the future
Security/permissions
Reconsider interface for virtual devices
Look into performance optimizations
Change-Id: I9b7d63b196996a04be0a830efa913043da1328a8
This reverts commit 6aee1d2ba5.
But leaves in some of the improved documentation.
Bug: 18281970
Bug: 18573576
Change-Id: I320f2229456ac039bc8f3cd8bc8b4ea6cf0e80eb
...is installed with <provider> with empty string.
Don't allow empty authorities, just like we don't allow null authorities.
Change-Id: I5c64592a639efe4dba848bd6f0efe4257f1565a2
