This change also fixes a typo that was suppressing the dock
sounds. But: so as not to surprise anyone, this change
defaults dock sounds off as well. Will need to add UI
somewhere to turn them on (Spare Parts?).
Bug: 2465483
Change-Id: Ic2cccb416d5616a84363debb740bf5897f0831c4
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.)
The noise is the residual ring tone that is still playing while the call is answered and the
audio route changed to headset or earpiece.
The fix consists in muting the ringing tone when changing mode from ringtone to in call
and delaying the route change until the audio buffers are emptied.
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.
