SQLiteQueryBuilder has a setStrict() mode which can be used to
detect SQL attacks from untrusted sources, which it does by running
each query twice: once with an extra set of parentheses, and if that
succeeds, it runs the original query verbatim.
This sadly doesn't catch inputs of the type "1=1) OR (1=1", which
creates valid statements for both tests above, but the final executed
query ends up leaking data due to SQLite operator precedence.
Instead, we need to continue compiling both variants, but we need
to execute the query with the additional parentheses to ensure
data won't be leaked.
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111085900
Change-Id: Ie85a95003ae134eef2fdfbf074c2f82d0a6a9f26
When users are building queries, they often need to append several
standalone SQL clauses, and it's tedious to track their first clause
so they can manually append " AND " to each subsequent clause.
So add new appendWherePhrase() API which appends a standalone phrase
which is AND'ed together with any existing WHERE query.
Also fix bug in update() which would turn null values into the
string literal "null" instead of passing them through as SQL NULL.
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111085900
Change-Id: Ia280dd864895654239503e080eaef925f5620d37
Despite SQLite documentation saying these clauses follow the "expr"
syntax, queries will fail with obscure "row value misused" errors,
so remove the strict enforcement for now.
Test: manual
Bug: 111480817
Change-Id: Ib8cdcb4e6456110589203189fcfa14e75cd68718
Previously battery history is kept in the in-memory mHistoryBuffer
with size of 512KB (96KB on low memory device). When the buffer is
close to full we drop certain types of history. When the buffer is
full the whole buffer is reset and we lost elder history. On a
device with long battery life this problem is more frequent.
This CL changes mHistoryBuffer to 128KB (64KB on low memory device).
When the buffer is full, it is saved to history file on file system.
By default we allow 32 history files (64 history files on low-memory
device) which gives us 4MB history (compare to 512KB today).
The MAX_HISTORY_BUFFER and MAX_HISTORY_FILES can be remote configured
through GServices or P/H.
In case of history exceeding 4MB, the oldest history file is deleted
and new history file is open.
This change increases battery history by using disk file and the
chance of losing history is greatly reduced.
Bug: 67297625
Test: adb shell dumpsys batterystats --history
Change-Id: Id9aafea761649d7323b97d1e44135f7880a95414
Developers often accept selection clauses from untrusted code, and
SQLiteQueryBuilder already supports a "strict" mode to help catch
SQL injection attacks. This change extends the builder to support
update() and delete() calls, so that we can help secure those
selection clauses too.
Extend it to support selection arguments being provided when
appending appendWhere() clauses, meaning developers no longer need
to manually track their local selection arguments along with
remote arguments.
Extend it to support newer ContentProvider.query() variant that
accepts "Bundle queryArgs", and have all query() callers flow
through that common code path. (This paves the way for a future
CL that will offer to gracefully extract non-WHERE clauses that
callers have tried smashing into their selections.)
Updates ContentValues to internally use more efficient ArrayMap.
Bug: 111268862
Test: atest frameworks/base/core/tests/utiltests/src/com/android/internal/util/ArrayUtilsTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Change-Id: I60b6f69045766bb28d2f21a32c120ec8c383b917
Keeping the code in memory of the currently set home app is
important for latency as we don't have any kind of starting
window/splash screen when pressing the home app to hide any latency.
Memory impact:
Pinning dex/vdex:
In practical scenarios, this should be < 500kb.
The home app is usually profile-speed compiled, for which the
resulting dex/vdex files are about 2 mb. However, during regular
use, at least 1.5 MB of it is referenced in memory. This makes
sense: By definition profile-speed only compiles the things that
is usually frequently executed during regular execution.
Pinning apk:
With Launcher 3 in practical scenarios this should be about 3.7 MB,
as the APK is about 5.7 MB but 2 MB are usually referenced in any
case.
Bug: 111132016
Bug: 78585335
Test: Inspect "adb shell dumpsys pinner" after boot.
Test: Check for pinned files after updating camera/home.
Test: Check for pinned files after user switch with different
default apps.
Test: Check for pinned files after bg-dexopt.
Test: Check for pinned files after bg-dexopt + kill pid.
Change-Id: I6cdbc06d089efeb1c72a51216879ba0573502009
The critical methods on this interface - like updateSession() - were already
void, so all we had to do were to "onewaywize" the other methods. We could
either refactor them to be truly async, or implement a blocking mechanism that
let them still be sync *and* oneway - because these methods are not in the
critical path, we opted for the latter, which is simpler and less risky.
Fixes: 73536867
Test: mmma -j ./frameworks/base/apct-tests/perftests/autofill/ && \
adb install -r $OUT/data/app/AutofillPerfTests/AutofillPerfTests.apk && \
adb shell am instrument -w -e class android.view.autofill.LoginTest \
com.android.perftests.autofill/android.support.test.runner.AndroidJUnitRunner
Test: CtsAutoFillServiceTestCases
Change-Id: I380430aa2a7805aed6f629afb360566fc5402abb
Root cause has been identified, but fix is too risky. Instead, we
remove the WTF for now and readd the fix as well as the WTF
in master.
Note that due to defensive programming, in case we land in the WTF
case, it doesn't cause any real bug.
Test: boots
Bug: 110834518
Change-Id: I0da1e48e420c3fcde0e818b7fe0527da9155a159
An Activity may not yet create on client side, there is another
launch request with flags to clear task, then a destroy transaction
is scheduled. If client side keeps blocking until destroy timeout,
the token on server side will be removed. When client begins to
handle the first creation, it will report its activity token to
server that causes IllegalArgumentException because there is no
matched ActivityRecord.
Bug: 32375307
Test: atest FrameworksCoreTests:TransactionExecutorTests
Change-Id: I1b7e0c2863b13091c3fd50df602ff31ae02ff38d
By using text textclassifier API, we classify entities like
email, phone, address in the notification and suggest the corresponding
actions.
Test: Manual test for now. Sideload GoogleExtServices. Write a sample app
to generate notification with phone number / address, etc, and finally
observe the smart actions.
BUG: 110527159
Change-Id: I02740cb07fa25a588d9e864990f95332d6830f12
This change treats any face detect mode larger than FULL mode
in the capture result as FULL mode. So in case the face detect
mode is larger than FULL, it is assumed that the FULL mode
STATISTICS_FACE is supported in the capture result.
Bug: 111131913
Test: CTS, GCA
Change-Id: I3a6a29ce8d9d8ab66918baaea3162797e18276d2
It makes sense to hide the details of the parser implementation
(and other similar objects) in libcore so it could be changed.
This change removes the "ExpatPerformanceTest" which appears not to have
been maintained and was comparing KxmlParser with itself. It is assumed
that android.util.Xml used to return the expat parser.
Test: build
Bug: 111055375
Merged-In: Ibad247323ba90cd949aecb2bd92f2f73306a4327
Change-Id: Ibad247323ba90cd949aecb2bd92f2f73306a4327
It makes sense to hide the details of the parser implementation
(and other similar objects) in libcore so it could be changed.
This change removes the "ExpatPerformanceTest" which appears not to have
been maintained and was comparing KxmlParser with itself. It is assumed
that android.util.Xml used to return the expat parser.
Test: build
Bug: 111055375
Change-Id: Ibad247323ba90cd949aecb2bd92f2f73306a4327
Here is the flow:
NAS generates Adjustment -> NMS convert this to RankingUpdate ->
SystemUI.NotificationListener receives the RankingUpdate in either
onNotificationPosted / onNotificationRankingUpdate (Depend on does NAS
provides the adjustment before the notification is en-queued) ->
NotificationEntryManager determines the need of reinflation ->
NotificationInflater inflates / reinflates the view with these
extra bits like smart actions.
Note: We do re-inflation here as simply adding a button to the existing
notification view seems problematic. For example, if the original
notification does not have any action, we will need to inflate the
template with the action container.
Screenshot:
https://hsv.googleplex.com/5731489463402496
Test: atest SystemUITests
Test: atest com.android.server.notification.NotificationAdjustmentExtractorTest
Test: Modify ExtServices to provide adjustment in
createEnqueuedNotificationAdjustment, post a notification with
a entity in a sample app, observed the notification is updated.
(Testing the onNotificationPosted flow)
Test: Modify ExtServices to provide adjustment in onNotificationPosted
by calling adjustNotification. Post a notification with
a entity in a sample app, observed the notification is updated.
(Testing the onRankingUpdated flow)
Test: Repeat the above test, but explicitly make the RowInflaterTask
slow by inserting Thread.sleep. This can test the onRankingUpdated
flow when the row is not yet inflated.
BUG: 110527159
Change-Id: I98aee3ac62f60b189ea92ac9fc000127325dfead
