Includes the following commits:
==
New system feature: eUICC.
Presence of this feature implies that eUICC-related APIs are expected
to function as long as an eUICC is present in the device. Note that an
eUICC may be embedded in the device but may also be removable.
==
Add empty EuiccManager API and plumbing.
==
Add stub EuiccService.
EuiccService is the class that the LPA app must implement; for now,
just define the action and priority so that the implementation can be
found. Actual methods will come later.
Also declare two relevant permissions: BIND_EUICC_SERVICE, which the
implementation must require (so that nobody else can bind to the
service directly), and WRITE_EMBEDDED_SUBSCRIPTIONS, which permits
signature|privileged apps and CTS (via development) to access
EuiccManager APIs.
==
Add UiccAccessRule based off UiccCarrierPrivilegeRules#AccessRule.
This class can be used to transfer access rules between an
EuiccService implementation and the platform.
We also add a simple encoding/decoding of a list of rules so that they
may be stored in the subscription info table.
==
Add getEid() to EuiccManager/EuiccService.
getEid() fetches the EID. It requires either a privileged permission
(READ_PRIVILEGED_PHONE_STATE) or carrier privileges on the
currently-active profile. Until there is a use case that requires
opening this up to apps with only READ_PHONE_STATE, we shouldn't do
so.
To avoid churn in the future, the API signatures for EuiccService
include a slot ID to identify which SIM slot is being used. However,
this parameter is currently not populated correctly (nor is it usable,
as no Telephony APIs accept a slot ID to address commands). There is
no need to expose it yet in the EuiccManager APIs as we expect to
follow the TelephonyManager pattern of allowing per-slot instances of
EuiccManager in the future while keeping other method signatures the
same.
==
Define Euicc UI actions in EuiccManager/EuiccService.
The EuiccManager actions are to be implemented by the platform (and
only the platform), which forwards the actions to the active
implementation.
Also, remove our explicit priority meta-data tag as we can just rely
on android:priority in the corresponding intent-filter.
==
APIs for downloading embedded subscriptions.
Includes:
-getDownloadableSubscriptionMetadata, used by the platform and LUI to
fetch metadata about a downloadable subscription. The platform will
use this to perform the necessary permission checks (only allowing
otherwise-unprivileged apps to download profiles that are permitted
per the subscription metadata), and the LUI can use this to present
the name of the profile.
-downloadSubscription, to actually perform a profile download.
The stub for startResolutionActivity is included but not implemented;
resolution activities will be handled in a follow-up change.
==
Test: TreeHugger
Change-Id: I47b1da5a69f0736012cb137e02cd6c4e07fdaace
Yum!
Also needed to have a Context.revokeUriPermission() variant that is sane,
so reasonable CTS tests can be written.
Test: new ClipDataJobTest added.
Change-Id: Ia3135ea788a6e32c971bae7dab3a844d0ef4139c
When in VR mode, launch all activities into the virtual display ID as
provided by the Compatibility display. This includes two cases -
- New activity launches
- Existing activity in the background.
Testing Done: Tested with PlanarVirtualDisplay app and Settings,
Calculator and GestureApp with different intent flags.
Bug: 36071574
Bug: 36071445
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testVrActivityLaunch
Test: #testVrActivityReLaunch
Change-Id: Ic590a7cbd6f9b339dc83b22a8ffb1252219ef22e
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
The method delegates to ActivityMonitor.waitForActivityWithTimeout,
which takes milliseconds.
Bug: 6150572
Test: JavaDoc only.
Change-Id: I5a7c7634ddc6ac45bc6e64c9f1bd568c38d0b75f
The ViewStructure typically represents a View, but it it can also be a virtual
view; in particular, WebView uses virtual views to represent HTML elements.
Although most of the properties of the HTML element maps to properties of
Android Views, some properties (such as 'name' and 'id' on <INPUT> fields)
don't, and those are crucial for autofilling web pages.
Rather than trying to artificially map these properties, it's better to create
a generic representation, for the following reasons:
1. Web standards move in a different velocity than Android APIs
2. Android APIs cannot be changed easily. Deprecated APIs continue to work,
and new added APIs don't work in older versions
3. The data used for autofill is opaque to the Framework - it's only relevant
to the node producers (like WebView) and consumers (Autofill services).
Also removed the setIdEntry() that was used for the same purpose.
Fixes: 36696757
Bug: 36718508
Test: VirtualContainerActivityTest with new checks pass
Change-Id: Ia626bd1f640b0b5861e81a5915504b95029874c9
Rather than require an a-priori Notification be supplied in order to
start a service directly into the foreground state, we adopt a two-stage
compound operation for undertaking ongoing service work even from a
background execution state. Context#startForegroundService() is not
subject to background restrictions, with the requirement that the
service formally enter the foreground state via startForeground() within
5 seconds. If the service does not do so, it is stopped by the OS and
the app is blamed with a service ANR.
We also introduce a new flavor of PendingIntent that starts a service
into this two-stage "promises to call startForeground()" sequence, so
that deferred and second-party launches can take advantage of it.
Bug 36130212
Test: CTS
Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
(cherry picked from commit 79047c62b5)
We were properly re-running jobs if the app hung during their
execution, but outright crashes wound up with the scheduled job
being dropped. That's bad; it can easily lead to broken monitoring
in the case of content-triggered jobs.
We now reschedule with backoff when this happens. In addition, to
mitigate the impact of repeatedly crashing apps, we now enforce a
minimum backoff interval of 10 seconds for automatic reschedules.
Bug 36030229
Test: manual
Change-Id: Ib5da583d7901d1255066c48558b35186eb641e17
It was consuming all keyShortcuts which broke system hotkeys
like shift+tab.
In order to prevent the decor/phonewindow from creating menus,
this creates a dummy view in onCreatePanelView.
This also includes a change to Activity to not send KEYCODE_TAB
keystrokes to the defaulthandler. This was preventing keyboard
navigation from working on any activity that had a default
search fallback.
Bug: 32482282
Bug: 18021345
Test: Added a CTS test (ToolbarTest#testKeyShortcuts) for toolbar
keyShortcuts. Verified Tab-navigation works in Play Store.
Change-Id: I5c732a2b21219157818bed49576debd20d5a8178
(cherry picked from commit b22faf524e)
Bug 36679897
When restoring the non-config fragments, the wrong index was
being used to lookup the fragment fromt the list of active
fragment states.
Test: Ic862fd9670408dab09ab5817cdec21e91aef001b
Change-Id: Ic5a8e723041949e6d01d4f5ddc6d54e491143b59
Rather than require an a-priori Notification be supplied in order to
start a service directly into the foreground state, we adopt a two-stage
compound operation for undertaking ongoing service work even from a
background execution state. Context#startForegroundService() is not
subject to background restrictions, with the requirement that the
service formally enter the foreground state via startForeground() within
5 seconds. If the service does not do so, it is stopped by the OS and
the app is blamed with a service ANR.
We also introduce a new flavor of PendingIntent that starts a service
into this two-stage "promises to call startForeground()" sequence, so
that deferred and second-party launches can take advantage of it.
Bug 36130212
Test: CTS
Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
