Minor refactoring of RegisteredServicesCache for testability. Added
RegisteredServicesCacheTest which uses a mock version of
RegisteredServicesCache.
Bug:19321135
Change-Id: If18b794b28f03b4bf4bbdfbba9e9a57e808aaebf
Make Intent.ACTION_QUERY_PACKAGE_RESTART and Intent.EXTRA_PACKAGES
accessible from GmsCore so that location and context components can
properly respond to the broadcast.
BUG: 19298558
Change-Id: I4b5cf4991c69d3aa745d03271187c65794df10b2
The TaskStack override configuration is set based on the
stack dimensions so we can load the most acturate resources
for activities in the stack in a multi-window environment.
Also, disabled fixed screen orientation for resizeable
activities.
Bug: 19305402
Change-Id: I7b182554523b12f2ef77f8bbc7b16891231125bf
Make Intent.ACTION_QUERY_PACKAGE_RESTART and Intent.EXTRA_PACKAGES
accessible from GmsCore so that location and context components can
properly respond to the broadcast.
BUG: 19298558
Change-Id: I8377db7c347068cfdd534e8f85834674f77d4cf3
When updating the RegisteredServicesCache, don't remove any packages
that are not in the list of modified packages.
Bug: 19228972
Change-Id: Id4f264403b7ceca9005854dfbbc25abfd7b54889
Instead of using the ActivityInfo, use the ResolveInfo so that
any label or icon specified on the intent-filter is used.
Also handle the density param in getIcon()
Bug: 18482039
Change-Id: I65cb7adb34b2e472bfc68e7734f3a40fd0a6244c
In addition to receivers, primaryUserOnly is now supported for activities.
In queryIntentActivities method, activities with primaryUserOnly flag set will
be filtered out, when current user is not the owner.
Change-Id: I0b7168b8c96749cd6d23b8c95d5624589f5f2d86
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
