Since there could be an arbitrary number of messages in
the queue but Handler/Looper/MessageQueue do not provide
any mechanism for removing "all" messages the best we can
do is ignore. Throwing an error is probably too heavy.
Change-Id: I13c81ac5786484f5b3218885b010de596d943975
Add support for quiting the looper and stopping a thread.
Allow enter/exit at top or bottom of a STATE EBNF.
Fix missing brace in MSG_LIST.
Change-Id: Iddf5ce908008933bf8f0646e844254183da3d1f3
Switched to ActivityInstrumentationTestCase2.
As far as http://b/issue?id=2446911 is concerned, I was unable
to reproduce a test fail. This was not the case a week ago.
A fix has probably been submitted in the meantime.
Change-Id: Id6e95218a2c9d29b0b4eb051a7a1288f9a9809fd
Patches in ExpandableListView to correctly handle header/footer shifter flat positions.
Make tests added in https://android-git.corp.google.com/g/#change,42312 pass.
Change-Id: I0d7823f5ae290e855bfdfb8d33c18bd34661077c
New tests for
- the different conversions between flat and packed positions.
- selectedPosition
- contextMenuInfo.
All these tests currently fail when list contains headers and/or footers.
Change-Id: Ifb8fcc5de4980221e2ff4ebd2b24bc4fa03c6aae
This is the framework part, moving classes around so the framework
no longer needs to link to android-common. Makes some APIs public,
others that didn't need to be public are private in the framework,
some small things are copied.
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
bug fix for 2419869 is the following
1. only one object can use the prepared statement object
(SQLiteCompiledSql in SQLIteProgram)
2. if two objects are requesting to use it, then create a new prepared
statement object for exclusive use by the newcomer and let it be
be finalized by the newcomer.
3. add mInUse flag to SQLiteCompiledSql - to be set when SQLiteProgram
requests it and to be released when that SQLiteProgram is done with it
a couple more changes included are
1. unitests to simulate bug # 2419869 (and the fix's repair to it)
2. better logging in SQLiteCloseable when it prints log messages
Unchecked items remain in the mCheckStates with an associated false value.
Now filtered out.
Added a unit test to ensure non regression.
Change-Id: If0b1a38aa06881055c87a97b3afb2c7fb48656f1
http://b/issue?id=2440815
MemoryFileTest.testPurge() can fail if the process runs
out of file descriptors before the kernel starts purging ashmem areas.
Before, there was no finally block to close the open ashmem
file descriptions, which caused random other tests to fail.
I also changed the size of the memory areas to 10MB, which
should cause it to run out of memory before it runs out of file
descriptors. It now fails with this instead:
java.io.IOException
at android.os.MemoryFile.native_pin(Native Method)
at android.os.MemoryFile.allowPurging(MemoryFile.java:189)
at android.os.MemoryFileTest.testPurge(MemoryFileTest.java:53)
at java.lang.reflect.Method.invokeNative(Native Method)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)
I'm not sure why, but it could be that the kernel is purging the just
allocated area instead of an old one. That seems like bug.
See http://b/issue?id=2203775
Change-Id: Ia7930a714378474dd4c2c6709da40c08e715ab6f
- move the encodeInternal/decodeInternal methods into the inner
"state" classes
- tighten up the inner loop of the encoder and decoder a bit, saving
about 5% of time in both cases
- improve javadoc
- other little fixes
Change-Id: I72e0ce8502c664a32418cea04636ccdbf4fec17c
instead of rolling our own trace/profile code in java, lets use
sqlite 3.6.22 features. turns out sqlite does a good job of
printing the sql statements - including the ones from the triggers.
- added the ability to specify that a sync (of account/authority/extras)
should occur at a given frequency
- the existing daily poll code was replaced with seeding each
account/authority with a 24 hour periodic sync
- enhanced the "adb shell dumpsys content" output to show the
periodic syncs and when they will next run
capture the sql statement along with the bindargs passed in. this will help
one to see the sql statements being executed and hopefully will help
debug incorrect-sql bugs.
Most of these are file moves; a couple notable exceptions are the changes due to the move, and fixing up test code:
- database/DatabaseCursorTest.java
- database/DatabaseStatementTest.java
- net/UriTest.java
