Previously any updated system apps would not be able to have a greater
than 0 priority on an activity intent filter. Moving the priority check
later in the package scanning allows it to apply to updated system
packages as well.
Cherry-pick from gingerbread branch
Bug: 2572398
Change-Id: I95d8b6360bf7a3f39cd7a1ff09e1ee57e11583d8
The finalize() call did not clean up completely, this eventually
caused the android.process.acore to crash since it ran out of fds
and GREF to increased above 2000 if an application forgot to close
its cursor objects. A warning was also added when this happens so
that application developers can correct their mistake. The
included test case tries to verify that the finalizer works as
expected by creating a bunch of Cursor objects without closing
them (without this fix the acore process crashes after about 400
iterations and the test case ends with "Process crashed").
Change-Id: I11e485cef1ac02e718b2742108aa88793666c31d
The reason we need a separate latch is that
AsyncTask will post onPostExecute/onCancelled
_after_ executing mFuture.get(). The previous
implementation would only wait for mFuture.get()
to complete and not the entire task.
Change-Id: I96964591980965148eb09af38b5838bfa5d28277
...to throttle contentobserver-based requeries
Why yes, I guess it could.
This also reworks AsyncTaskLoader to not generate multiple
concurrent tasks if it is getting change notifications before
the last background task is complete.
And removes some of the old APIs that had been deprecated but
need to be gone for final release.
And fixes a few little problems with applying the wrong theme
in system code.
Change-Id: Ic7a665b666d0fb9d348e5f23595532191065884f
* commit '672ebb61a755e4bbe60e4e884b1adadf186733b6':
Improved ignore-backoff handling Allow a non-epidited ignore-backoff op to pass through an expidited backed off op.
Allow a non-epidited ignore-backoff op to pass through
an expidited backed off op.
To do this, I first refactored the complicated if statement:
if (best == null
|| ((bestSyncableIsUnknownAndNotARetry == syncableIsUnknownAndNotARetry)
? (best.expedited == op.expedited
? opRunTime < bestRunTime
: op.expedited)
: syncableIsUnknownAndNotARetry)) {
best = op;
bestSyncableIsUnknownAndNotARetry = syncableIsUnknownAndNotARetry;
bestRunTime = opRunTime;
}
Into a more readable:
boolean setBest = false;
if (best == null) {
setBest = true;
} else if (bestSyncableIsUnknownAndNotARetry == syncableIsUnknownAndNotARetry) {
if (best.expedited == op.expedited) {
if (opRunTime < bestRunTime) {
// if both have same level, earlier time wins
setBest = true;
}
} else {
if (op.expedited) {
setBest = true;
}
}
} else {
if (syncableIsUnknownAndNotARetry) {
setBest = true;
}
}
if (setBest) {
best = op;
bestSyncableIsUnknownAndNotARetry = syncableIsUnknownAndNotARetry;
bestRunTime = opRunTime;
}
The refactoring was all done automatically with IntelliJ to avoid human error
in the conversion.
After verifying this code still behaved as expected including the error
condition in the bug, I added handling for the cases when a non-expidited op
may override an expedited op if certain conditions occur, specificaly, if the
expidited op is backed off and the non-expidited op is not.
Finally, refactored to make it testable and added tests and logging.
Bug: 3128963
Change-Id: I131cbcec6073ea5fe425f6b5aa88ca56c02b6598
The content resolver does not take care of the IllegalStateException
that is thrown in getType and that needs to be fixed.
Change-Id: I3e66f1aa259ab91fb9233e1ba07faa1ab6c3f2dd
list UI is not ready yet
This involves some reworking of Loaders.
Loaders, in particular CursorLoader, are now expected to retain
their current data after being stopped. This allows applications
to keep that data across onStop() -> onStart(), so when the user
returns to the app it doesn't have to wait for the data to reload
and thus cause flicker.
This includes various API changes to better reflect the new
semantics, plus a new LoaderCallbacks method to tell the application
when it is actually time to stop their use of a loader's data.
Note this is somewhat half-done, to help checking in the extensive
application changes that are required without causing build breakage.
Change-Id: Ib4b3bf8185a6da46e7f06ca125521d65e2e380a1
It was moved so it was no longer in the location that
SyncManager expected. I fixed it by (a) moving it to the
SyncManager directory and by (b) changing the SyncManager to
refer to it by class rather than by class name, which means
it will now check for it at compile time, not run time.
Bug: 3289922
Change-Id: I24f8bac371a16c62c2a38ed1024702c6d0913b93
Intent.ACTION_USB_DGTL_HEADSET_PLUG and Intent.ACTION_HDMI_AUDIO_PLUG
where mistakenly using the same string.
Change-Id: Iede1896196585396dcc7e00aad06ad60e9a87875
Also, changes to make this testable with CTS:
-- special PENALTY_DEATH StrictMode fast path that doesn't use
the Looper idling to "time" the violation. Only used when
death is the only violation,
-- make PENALTY_DEATH throw a RuntimeException instead of
killing its process with a signal. this means we can catch
it in CTS tests, but it's also more consistent with
PENALTY_NETWORK_DEATH in Honeycomb.
-- make FileUtils.getFileStatus() invoke StrictMode, which isn't
(yet?) aware of I/O in native code. so help it out.
CTS test for MODE_MULTI_PROCESS is in I6154edab
Change-Id: Icf93f9dfb0ece06b16781e4803dd2c17df3cf1b3
