If a backup-participating app sets android:restoreAnyVersion="true" in its
manifest <application> tag, then its agent will be invoked for restore
even if the available dataset was created by a later version of the app
than is currently installed on the device. This will not typically be
a problem for third party applications, since for them the installation
and initial data restore are tightly coupled, but it can cause serious
problems for applications which are both preinstalled on the system
partition and overridden by later updates. The primary difficulty
that this new attribute addresses is this:
1. User buys a Nexus One, Market self-updates, and the user installs some apps.
At this point the backup data on the server may indicate that the version of
Market which originated its bookkeeping is newer than the stock N1 Market app.
2. User loses their phone, and buys a replacement N1. At setup time, Market
has not yet had a chance to self-update, so when the restore comes in, it's
tagged as being from "the future" and so the restore is refused. No apps get
reinstalled.
Bug: 2442127
Change-Id: I076a9553dc613e5c3189350e778315718ed1ed2b
the pending TOUCH_EVENTS and then send an ACTION_CANCEL
and skip the rest of touch events.
This should address the drag problem Flash plugin has.
Fix http://b/issue?id=245053
Add null checks to a few places to avoid crashes when dumping
debug data.
Also add some sanity checks for accessing content providers in
the activity manager.
change hard coded path in installd
fix tests
Work around for renaming containers.
Do forced unmount when destroying containers.
Force a gc in default container service to release handle to parsed package
and thus avoid getting killed by vold
Some cosmetic changes to PackageManager api.
Unit tests for renaming container for MountService
Remove internal size limit on app to be installed.
Merge commit '563d3a62f3762b312a4c0a9d9af15a2333beaede'
* commit '563d3a62f3762b312a4c0a9d9af15a2333beaede':
These changes add access to some status values in widgets listed below:
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
Added ACTION_ADD_ACCOUNT intent and EXTRAS_AUTHORITIES strings to the public
api so that Calendar can send users to the add account screen directly instead
of via the sync settings page.
widget/CheckedTextView.java: report if the item is checked or not.
widget/CompoundButton.java: report if the item is checked or not.
widget/ProgressBar.java: isIndeterminate(), getProgress(), getSecondaryProgress(), and getMax() report what
sliders and progress bars are showing
widget/TextView.java: report the current selection: getSelectionStart() and getSelectionEnd()
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.
This should reduce the number of updates to the searchables
list if multiple packages change at the same time.
Fixes http://b/issue?id=2270711
Change-Id: Ieb930022866aa2872f8df1af677e3ea1645349bf
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.
This is to fix a particular case where the navigation cache
does not recognize that a textfield is now in focus. A message
was sent from the WebCore thread telling us to open the IME on
the textfield. Open it with the WebView as the served view.
Fix for http://b/issue?id=2457459
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.
