More freezing of apps when doing surgery.

We're still hearing rare reports of apps running while the system
is trying to do surgery on app code/data.  To fix this once and for
all, start guarding all PackageManager critical sections by freezing
and then killing the app before doing surgery.

This is done by introducing a new PackageFreezer class which can be
used in try-with-resources blocks.  It also handles child packages
uniformly, and it uses CloseGuard to defensively un-freeze packages
if a caller leaks without closing.

The set of frozen packages is now maintained outside of PackageSetting
to support newly installed packages.  Add docs for the various locks
and method syntax conventions, including the new "LIF" syntax which
indicates the caller is responsible for freezing the package being
worked on.

Bug: 27698554
Change-Id: I64c4c48123060ccb4d4c50c2fbf3ef223c01e659
This commit is contained in:
Jeff Sharkey
2016-04-08 21:14:08 -06:00
parent 8ed9ece93d
commit d4041db120
3 changed files with 339 additions and 200 deletions

View File

@@ -113,12 +113,6 @@ abstract class PackageSettingBase extends SettingBase {
int installStatus = PKG_INSTALL_COMPLETE;
/**
* Non-persisted value indicating this package has been temporarily frozen,
* usually during a critical section of the package update pipeline. The
* platform will refuse to launch packages in a frozen state.
*/
boolean frozen = false;
/**
* Non-persisted value. During an "upgrade without restart", we need the set
* of all previous code paths so we can surgically add the new APKs to the

View File

@@ -4325,10 +4325,6 @@ final class Settings {
pw.print(Integer.toHexString(System.identityHashCode(ps)));
pw.println("):");
if (ps.frozen) {
pw.print(prefix); pw.println(" FROZEN!");
}
if (ps.realName != null) {
pw.print(prefix); pw.print(" compat name=");
pw.println(ps.name);