Skip to content
Commit ca3872ce authored by Dianne Hackborn's avatar Dianne Hackborn
Browse files

Fully implement "install" and "install-write" in PackageManagerShellCommand.

We can use the new mechanism to ask the calling shell to open
a file in order to implement the rest of these commands, allowing
you to give the path to an apk to install.  That API is thus
extended to allow you to open readable files, not just opening
file for writing.

Doing this however means we no longer can pass a file path to
AssetManager for the apk to parse, we only have an already open
fd for that.  Extending AssetManager to allow adding apks from
fds is not that hard, however, since the underlying zip library
already supports this.

This main thing this changes is in AssetManager.cpp where we
retrieve the open zip file for a particular apk that has been
added.  This used to look up the zip file by path every time
it was needed, but that won't work anymore now that we can have
things added by fd.  Instead, we keep track of each opened zip
in the AssetManager, so we can just directly retrieve it from
the asset_path representing the item that was added.  As a
side-effect, this means for normal paths we no longer need to
look up by name, but just have the opened zip file directly
accessible.  (This is probably good, but it does mean that we
no longer run the logic of seeing if the zip file's timestamp
has changed and re-opening it if it has.  We probably shouldn't
be relying on that for an active AssetManager anyway, and maybe
it is even good that we don't allow the zip file to change
under it?)

A follow-up change will finally remove the Pm.java implementation
and turn the pm "command" into a simple shell script that runs
cmd package.

Test: manual

Change-Id: Ie103e3bdaa5b706796cc329254f2638151a3924f
parent 362e983a
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment