The runtime expects them to exist before it's launched.
The boot image / art files are created during the first
zygote launch.
(cherry picked from commit da738713e4e2120a324e8ab6fd11aa0e54a3c66e)
Change-Id: I7472aa25c16a1cf95791af2bdf80ed0d73123872
FileMap memory is never released until application exit
Release it now as the texture is already loaded and the memory
used for the packed resource can be released.
Change-Id: Id08a1e466337b3a0179684eb6a444e18147ee343
The runtime expects them to exist before it's launched.
The boot image / art files are created during the first
zygote launch.
Change-Id: I5ed0ad4854dc7785246344c8f6eaf54e560feb7d
When app_process/zygote starts, make sure PR_SET_NO_NEW_PRIVS is set.
This prevents zygote spawned apps from acquiring new privileges
on exec.
In particular, this allows the CTS test
android.os.cts.SecurityFeaturesTest#testNoNewPrivs() to pass if ART is set
as the default runtime.
Change-Id: I81139cda999c7b1430242561aad28f566e9b6da0
Add new "ro.config.wallpaper" and "ro.config.wallpaper_component"
properties which may be defined outside of the bundled framework
resources. Falls back to bundled resources when properties are
undefined.
Also look for boot animation under OEM partition.
Bug: 13340779
Change-Id: Ibdc9935dbdaae3319bf63b40573de0503d82ae67
This gives a basic working implementation of a persist
running service that can start a voice interaction when
it wants, with the target activity(s) able to go through
the protocol to interact with it. It may even work when
the screen is off by putting the activity manager in the
correct state to act like the screen is on.
Includes a sample app that is a voice interation service
and also has an activity it can launch.
Now that I have this initial implementation, I think I
want to rework some aspects of the API.
Change-Id: I7646d0af8fb4ac768c63a18fe3de43f8091f60e9
Define new FLAG_GRANT_PREFIX_URI_PERMISSION which indicates that a
Uri permission grant should also apply to any other Uris that have
matching scheme, authority, and path segments. For example, a prefix
grant for /foo/ would allow /foo/bar/ but not /foo2/.
Allow persistable and prefix grants to be issued directly through
grantUriPermission(). Relaxing persistable is fine, since it still
requires the receiver to actively take the permission.
Since exact- and prefix-match grants for the same Uri can coexist,
we track them separately using a new UriGrant key. (Consider the
case where an app separately extends READ|PREFIX and WRITE for
the same Uri: we can't let that become READ|WRITE|PREFIX.)
Fix revoke to always take away persisted permissions. Move prefix
matching logic to Uri and add tests. Add new flags to "am" tool, and
various internal uses around Intent and Context. Switch some lagging
users to ArraySet.
Bug: 10607375
Change-Id: Ia8ce2b88421ff9f2fe5a979a27a026fc445d46f1
Use String8::isEmpty instead. Note that this code path is hit
only if the zygote calls ::exit, and that never happens unless
the VM invocation fails.
Change-Id: I0e7d3a86a79b12b2174ca3bf0dbe1904e33c041a
- Use different process names for the 32 / 64 bit zygote.
- Pass command line arguments correctly. The first unmatched
argument must be passed through to the java main class.
Change-Id: I952ebbdbba941f118d992354b9bd0ada2dade417
Query system properties for the list of ABIs and pass
it as a command line argument to ZygoteInit.
Also add a new Zygote command that returns this list of
ABIs to peers.
Change-Id: I68034c6f63fa626911122579a011a0a25a8cda94
- Make copies of argc, argv before argv is potentially
overwritten with the process name.
- Allow multiple command line arguments to be passed to
ZygoteInit (this is required for some of the 64 bit
zygote work).
- Add an explanatory comment about how these argments
are processed.
Change-Id: I752be69c5c0f97ed17d1a3dded19f46ee00929b0
These look like historical oddities, and weren't really being
used for anything useful.
Process:setArgV0 was being called by android.util.Process, but
that functionality can be moved directly into the implementation
of that class.
bug: 13647418
Change-Id: I216c8f8a4c065f0cf3a61f19f9e32decd26f93f6
Rename the related user concept as profiles.
When returning profiles of a user include the
user as a profile of itself.
Change-Id: Id5d4f29017b7ca6844632ce643f10331ad733e1d
...and now fail conservatively when two apps both attempt to define
the same permission. Apps signed with the same certificate are
permitted to redefine permissions.
We also finally have a (hidden) interface class for observing package
installation so that we can now rev the interface without breaking
existing callers.
Bug 13551375
Change-Id: Ifa4e59154dcccbb286ee46a35a6f25e4ad0f0f01
Use LOCAL_MULTILIB := both to build app_process64 instead of
duplicating the build rule.
Also causes PRODUCT_PACKAGES := app_process to install both
versions on 64-bit platforms, as the module names for both
app_process and app_process64 are now app_process.
Change-Id: Ia3c3265d15475771b0cae8bace53b8fbf351c186
...and now fail conservatively when two apps both attempt to define
the same permission.
We also finally have a (hidden) interface class for observing package
installation so that we can now rev the interface without breaking
existing callers.
Bug 13551375
Change-Id: I3a286d024a30e812ee4b098f345401df3c00e178
Shared libraries can now export resources for applications
to use.
Exporting resources works the same way the framework exports
resources, by defining the public symbols in res/values/public.xml.
Building a shared library requires aapt to be invoked with the
--shared-lib option. Shared libraries will be assigned a package
ID of 0x00 at build-time. At runtime, all loaded shared libraries
will be assigned a new package ID.
Currently, shared libraries should not import other shared libraries,
as those dependencies will not be loaded at runtime.
At runtime, reflection is used to update the package ID of resource
symbols in the shared library's R class file. The package name of
the R class file is assumed to be the same as the shared library's
package name declared in its manifest. This will be customizable in
a future commit.
See /tests/SharedLibrary/ for examples of a shared library and its
client.
Bug:12724178
Change-Id: I60c0cb8ab87849f8f8a1a13431562fe8603020a7
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
