serial board. They all use a well-known UUID that is not really explained
anywhere official, and this always trips developers up.
Change-Id: I53bda44b580f472b1ff1ad196b25485b68f4b5d5
ActivityThread should try to set the value for Java
Thread.getContextClassLoader to the PathClassLoader that loaded the
APK's classes so that Java frameworks that use the Java context class
loader, which is not to be confused with the
android.content.Context.getClassLoader which serves a similar purpose
in the Android framework.
However, we avoid setting the Java context ClassLoader to the APK's
PathClassLoader if there is a static indication that multiple packages
may share the VM, since they could load in an unpredictable order
leading to different values for the thread local Java context
ClassLoader. In this case, we instead use a specially created
WarningContextClassLoader that warns the user the first time the Java
context ClassLoader.
Currently the static indications that a package might share a VM with
other packages are the presence in the AndroidManifest of a
sharedUserId or requesting a non-default application process name.
Today we're seeing a crash that's likely caused by a change in the order in which
system services start.
The crash we're seeing happens in response to user interaction which happens after the
boot process completes, so we should re-fetch the DevicePolicyManager if we weren't
able to get it when LockPatternUtils was constructed.
Includes several potentially controversial major changes:
- Remove the amount of repeated boilerplate explanations of common
idioms. I find them much more distracting than useful. The same
things are explained, but in fewer places.
- Add more narrative/directive information instead of merely descriptive
commentary; I included a lot of "color" about who particular methods are
intended for and why you might use them.
- Add explicit guidance (in the class javadoc) about the common usage pattern.
Explicitly document the auth token invalidation dance, which is highly
nonobvious, had never been written down before, and which GMM got wrong,
creating a Latitude conops nightmare they're still digging out of.
- Explain and justify, as best I can, the overall model of account management:
saved credentials, pluggable authenticators, auth tokens, and so on. Clarify
some things, like that setPassword() changes the locally cached credential
but does not set the user's password on the server.
- Clarify what the passed-in Activity parameter is used for. (It seems silly,
but I was confused by this: is it supposed to be the Activity that actually
performs the password prompt or whatever? No, it's just a Context for the
startActivity() to be launched from.)
This removes the '*' value for android.app.searchable and
android.app.default_searchable that was previously used by apps to say
that they want global search as their search. I think the only
activity that this will affect is the wallpaper chooser in the
launcher, which doesn't seem like it matters. It could mean that some
third party code will stop invoking global search, but all they would
need to do is call startSearch() with globalSearch=true instead.
Fixes http://b/issue?id=2377433 and http://b/issue?id=2377429
Change-Id: I0252952b44ae85dab31221b598ed79cc24e2b580
2185256: After open &close of device keyboard shortcut does not added to Home desktop.
ActivityThread was losing the last saved state when restarting or launching into
a paused state.
2366174: defaults not cleared when they should be
PackageManagerService now removes any preferred activity records for a package
when it is uninstalled.
2154556: Battery stats can have an unbounded number of wake locks
We now start combining wake locks into one shared record when we hit a
maximum limit (currently 20).
2442519: Foreground services can have no notification by providing a bogus one.
If the notification manager rejects our notification, the service is forced to
no longer be in the foreground.
2442383: Finalization issues in com.android.server.am.PendingIntentRecord.java
Cleaned up finalization to call super class and avoid the big activity manager
lock (we still need to use the locks inside of the message system, but these
are much less likely to be a problem).
2284190: Cannot call a phone number using adb
We weren't getting the calling uid/pid in startActivity() if the caller did not
supply an application record.
Turns out the database is used a ton, and not particularly quickly, so
these were spamming the logs at their prior 100ms thresholds. Setting
it to 500ms now. (still sub-sampled, so should be ~5x less spammy...)
Also, set FLAG_ACTIVITY_NEW_TASK to allow launching
global search from non-activity contexts.
Fixes http://b/issue?id=2460991
Change-Id: I833d5b851f0127fb69165fbfc7d1ee190b320401
The ui modes can be controlled with the UiModeManager class, which
is can be retrieved as a system service via getSytemService(Context.UIMODE_SERVICE).
The class is necessary so that CarHome can be unbundled and other apps can
disable the car mode. Its currently a hidden class, since I'm not sure if this
is the best way to provide this functionality to the user.
I am getting tired of writing package monitor code, realized this is missing in
a number of places, and at this point it has gotten complicated enough that I
don't think anyone actually does it 100% right so:
Introducing PackageMonitor.
Yes there are no Java docs. I am still playing around with just what this
thing is to figure out what makes sense and how people will use it. It is
being used to fix this bug for monitoring voice recognizers (integrating the
code from the settings provider for setting an initial value), to replace
the existing code for monitoring input methods (and fix the bug where we
wouldn't remove an input method from the enabled list when it got
uninstalled), to now monitor live wallpaper package changes (now allowing
us to avoid reverting back to the default live wallpaper when the current
one is updated!), and to monitor device admin changes.
Also includes a fix so you can't uninstall an .apk that is currently enabled
as a device admin.
Also includes a fix where the default time zone was not initialized early
enough which should fix issue #2455507 (Observed Google services frame work crash).
In addition, this finally introduces a mechanism to determine if the
"force stop" button should be enabled, with convenience in PackageMonitor
for system services to handle it. All services have been updated to support
this. There is also new infrastructure for reporting battery usage as an
applicatin error report.
Because some apps make SQLite database names containing email
addresses, we take care not to log those email addresses in the
EventLog, so other apps with READ_LOGS access can't read them.
When an application being installed defines a backupAgent in its manifest, we
now automatically perform a restore of the latest-known-good data for that app.
This is defined as "data backed up by this app from this handset, if available;
otherwise data for this app as it existed when the device was initially
provisioned." If neither option exists for the app, no restore action is
taken.
The CL involves major changes in the Backup and Package Managers...
* The Package Manager's act of installing an application has now been split
into two separate phases, with a data-restore phase optionally occurring
between these two PM actions. First, the details of the install are performed
as usual. Instead of immediately notifying install observers and issuing the
install-related broadcasts, the in-process install state is snapshotted and
the backup manager notified that a restore operation should be attempted. It
does this by calling a new API on IBackupManager, passing a token by which it
identifies its in-progress install state.
The backup manager then downloads [if possible] the data for the newly-installed
application and invokes the app's backupAgent to do the restore. After this
step, regardless of failure, it then calls back into the Package Manager to
indicate that the restore phase has been completed, supplying the token that
was passed in the original notification from the Package Manager.
The Package Manager then runs the final post-install actions: notifying install
observers and sending out all the appropriate broadcasts. It's only at this
point that the app becomes visible to the Launcher and the rest of the OS.
... and a few other bits and pieces...
* The ApplicationInfo.backupAgentName field has been exposed to the SDK. This
can be reverted if there's a reason to do so, but it wasn't clear that this
info needs to be hidden from 3rd party apps.
* Debug logging of restore set IDs and operation timeout tokens [used during
any asynchronous Backup Manager operation] are now consistently in hex for
readability.
* We now properly reset our binder identity before calling into the transport
during restore-set operations. This fixes a permissions failure when a
single-app restore was attempted.
* The 'BackupTest' test app is no longer lumped onto the system partition
by default.
Change-Id: If3addefb846791f327e2a221de97c8d5d20ee7b3
