Real libraries will be built correctly, but since we are not doing that
yet, support the old way and allow a flag --non-final-ids to remove
the final modifier from R.java.
Change-Id: Iad55fb9140e55dbb0f41d0d55f2e2bd958294c8e
Only the commands related to restrict background whitelisting were
initially added, so they can be used in the CTS test for the new APIs.
BUG: 26451391
Change-Id: I5479073d85c44b99368497448f1f8e36cd99e63c
And ensure that the listeners are informed of app standby transitions
that might occur during time changes.
Fix for apps that sometimes don't have network access until reboot.
Bug: 26488100
Change-Id: Ic342c188a6cd19faee88f50b2c6a342a6968cb23
The Storage Access Framework currently provides an
API (OPEN_DOCUMENT_TREE) that lets the user pick a directory to be used
by the application. Although this APIs is very powerful (for example, it
allows the user to create sub-directories, delete and share files,
etc...), it's too complex for simpler use cases like a camera
application trying to have access to the standard Pictures directory.
The new API (OPEN_EXTERNAL_DIRECTORY) simplifies this scenario by
letting the application select a standard, pre-defined directory (as
defined by android.os.Environment). The user still needs to grant access
to the requested directory, but the resulting UI will be simpler and
more straightforward.
Usage example:
// ...
int requestCode = 42;
Intent intent = new Intent(Intent.ACTION_OPEN_EXTERNAL_DIRECTORY);
intent.setData(Uri.fromFile(
new File(Environment.getExternalStorageDirectory(),
Environment.DIRECTORY_PICTURES)));
startActivityForResult(intent, requestCode);
// ...
@Override
public void onActivityResult(int requestCode, int resultCode, Intent data) {
if (resultCode != Activity.RESULT_OK) {
return;
}
Uri uri = data.getData();
int modeFlags = data.getFlags()
& (Intent.FLAG_GRANT_READ_URI_PERMISSION
| Intent.FLAG_GRANT_WRITE_URI_PERMISSION);
getContentResolver().takePersistableUriPermission(uri, modeFlags);
}
BUG: 23011462
Change-Id: Ie832026532f74e681ef220b761667eb66ff3c8b0
Service Workers are not tied to WebView instances so currently
there is no mechanism to capture callbacks originating from
within Service Workers.
This patch adds the necessary classes to capture callbacks
and allows to set settings specifically for Service Workers.
The main idea is that to control service workers the embedding
app would obtain an instance of ServiceWorkerController using
ServiceWorkerController.getInstance() first. After that it would
be able to set a custom ServiceWorkerClient and change
ServiceWorkerWebSettings via the controller object.
BUG: 22709088
Change-Id: I0eb17be46b767851676b77a94757771611fa3a1b
usage while running in background.
The new API is 'int getRestrictBackgroundStatus()' and returns the
following values:
- RESTRICT_BACKGROUND_STATUS_DISABLED: no restrictions
- RESTRICT_BACKGROUND_STATUS_WHITELISTED: restriction but app is
whitelisted
- RESTRICT_BACKGROUND_STATUS_ENABLED: full restriction
The proper way to interprete these values for using metered networks
while running on background is:
- When disabled, there is no restriction and the application could use the
metered networks freely.
- When whitelisted, the application can use the metered network, but should try
to minimize the usage.
- When enabled, the application should not try to use metered networks at
all, since the usage will be denied.
BUG: 26451391
Change-Id: If07d42bb88e4c02802df0234861f38aef2cfead7
When the system language is changed by the Settings app, we need to call
LocaleList.setDefault() to change the default locale list
since components like TextView should be able to assume that
LocaleList.getDefault() returns the latest system locale list.
BUG: 26731035
Change-Id: I482567476e1b14cd9b4716343183627f81d96ace
