If you test case is declaring a non-primitive constant,
this method would clear out the constant between
individual tests.
Change-Id: I570f2bbbbbb0a170bf63b7473b4aaf84869e93e0
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
What this adds:
- A new Intent activity flag to completely replace an existing task.
- A new Intent activity flag to bring the current home task up behind
a new task being started/brought to the foreground.
- New versions of startActivity() that take an array of Intents to be
started, allowing applications to start a task in a specific state.
- A public moveTaskToFront() method on ActivityManager, with a new flag
that allows the caller to have the task moved to the front with the
current home task immediately behind it.
Change-Id: Ie8028d09acffb5349d98043c67676daba09f75c8
This fixes a problem where the test runner would die when a
test case has tests that are not methods of the test class.
Change-Id: I5adc464bb4a0c8d282428895e422a47dcb6bfe1f
Without this addition, code that is being tested using an isolated context
can cause an exception if it unregisters a previously registered broadcast
receiver. This is because the isolated context never actually registered
the receiver in the first place. The fix is to make sure the isolated
context is consistent in ignoring both recevier registration and
unregistration calls.
Change-Id: Ie0ba6f4bb10f5248704327a0ffc8e37ee8b71ae2
I can't find the bug number for this, but it is needed for some things
we are doing where the app building an intent may not have access to the
URI in the data field. This is for HC, but doing in GB to avoid introducing
integration issues.
Change-Id: I0cac971854198b18775d2a73deb80f23431bfbe2
I can't find the bug number for this, but it is needed for some things
we are doing where the app building an intent may not have access to the
URI in the data field. This is for HC, but doing in GB to avoid introducing
integration issues.
Change-Id: I0cac971854198b18775d2a73deb80f23431bfbe2
So that it'll be compatible with Loaders, which uses this method.
(Otherwise MockContext.getApplicationContext(), which just throws
an exception, will be used.)
Change-Id: I529b60466cf086b514fcddbef4583d1c5b750b9c
Merge commit 'ec438e1448ebc578ee5a4c4beb1e26292cdedd6e'
* commit 'ec438e1448ebc578ee5a4c4beb1e26292cdedd6e':
Add PackageManager API to get information about a provider component.
This introduces basic infrastructure that should allow content
providers holding complex data to perform on-demand conversion
of their data to streams of various types. It is achieved through
two new content provider APIs, one to interrogate the possible
stream MIME types the provider can return, and the other to
request a stream of data in a particular MIME type.
Because implementations of this will often need to do on-demand
data conversion, there is also a utility intoduced in ContentProvider
for subclasses to easily run a function to write data into a
pipe that is read by the client.
This feature is mostly intended for cut and paste and drag and
drop, as the complex data interchange allowing the source and
destination to negotiate data types and copy (possible large)
data between them. However because it is fundamental facility
of ContentProvider, it can be used in other places, such as for
more advanced GET_CONTENT data exchanges.
An example implementation of this would be in ContactsProvider,
which can now provider a data stream when a client opens certain
pieces of it data, to return data as flat text, a vcard, or other
format.
Change-Id: I58627ea4ed359aa7cf2c66274adb18306c209cb2
This commit fixes two somewhat related problems:
- Attempting to run a method which does not exist caused a runtime
exception which stopped the test run. Change this so the runner reports
an individual test failure instead
- A runtime exception during the test run would cause it to stop
completely, with no information dumped to the logcat or stdout. Now
exceptions are trapped and reported to stdout.
Also added associated unit tests to test these two conditions.
Related bug 2812262.
Change-Id: I383f9b9bad99f14cb51071800fa9bdbf6a6a1119
Simple API for tracking .obb files associated with packages. Stores the
path in the PackageSettings. No verification of file content is done
now since the PackageManagerService can't read the SD card where these
files will likely live.
Change-Id: Ibeaf26ba0526b6d60f401137e58f46ee9faff39e
add new method openOrCreateDatabase in Context.java to allow
callers specify a DatabaseErrorHandler object to be used when
database corruption occurs.
add new constructor in SQLiteOpenHelper to accept DatabaseErrorHandler
as an additional param to be used when SQLiteDatabase instance is
created.
Change-Id: I912a0202a74510f9ca0206dd8101c4abab9102ae
-Updated onStart() call to onStartCommand()
-Removed asserts that disallowed starting an already bound service and vice versa, since
that is a valid Service usage pattern.
Change-Id: I79804aef5319a590c74fca54fc990954f7c3fdaa
The test runner will only load TestCase classes that have a public
constructor with either no params or a single String parameter.
This is fairly subtle behavior and can be difficult to catch. This change
adds a log message when a TestCase class is not loaded, and adds some
associated unit tests.
Change-Id: I6fc63e4179c949620f5773e0ae134f99905a6fb2
Addresses:
Issue #2550648: PackageManagerService setComponentEnabledSetting unconditionally
writes Settings xml
Issue #2549084: Make PackageManager.addPermission have async version
Also make the writing of settings when changing the preferred activities to use
the same async mechanism, and fiddle with thread priorities in the background
thread to go up to foreground priority when holding the lock to write settings
and a few other places. (At some point we should really clean this up to never
acquire the main lock while in the background.)
Change-Id: Ib2b7632543f6fb3f92a225518579f3b2d15e1413
This permits implementing interfaces which are faster than using
remote Cursors. It then uses it for Settings & SettingProvider, which
together account for ~50% of total ContentProvider event loop stalls
across Froyo dogfooders.
For fetching Settings this looks like it should reduce average
Settings lookup from 10 ms to 0.4 ms on Sholes, once the
SettingsProvider serves most gets from in-memory cache. Currently it
brings the Sholes average down from 10ms to 2.5 ms while still using
SQLite queries on each get.
Since MockAccountManager was passing null to the AccountManager
constructor, unit tests where the AccountManager attempts to call
the AccountManagerService were crashing.
Now the getAccountsByTypeAndFeatures and blockingGetAuthToken
(which are the calls that the Gmail unit tests call) call a small
stub
At some point, all of the other AccountManager calls should be stubbed
out
And ability to exclude tests with given annotation.
Also fix class cast compile warning in emma output method.
Bug 2239240
Change-Id: I56273a51a8c58a690680bdb612615fab69e6e13f
