We've encountered subtle bugs in how apps are using this public
API, so revert it back to exactly what shipped in the last
release, and move functionality to new SQLiteStatementBuilder
class, since we already have several customers using it.
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111486645
Change-Id: Ief059e987f2421e19f6f57a94320c313946a26d7
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
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
Also renamed denial reason to reject cause to match
the 3GPP spec.
Bug: 73659459
Test: Build
Change-Id: Ia67ebf94771c7ff5f5d90f6cdd303cb2716f9186
(cherry picked from commit b4094993f7)
This reverts commit 0c149bd2d8.
Reason for revert: reverting this topic as it breaks several branches.
Change-Id: Ia01984242e54b5db5d853135b322ebb1284a4d43
Merged-In: I45c0bfefb7ffe98e3eab8e68d0e1170881ae9f4c
This reverts commit b4094993f7.
Reason for revert: Caused merge conflict. Need to come up with a better solution.
Change-Id: Id7b7f35c25775a7a095b77a90724cf3a0f8daf7e
Connection#onSilence is generally applicable to apps implementing the
self-managed ConnectionService API.
Also updated the docs to make it more clear where that API is to be used
and how the developer can silence the ringtone.
Test: CTS test, manual test.
Bug: 110348674
Change-Id: I1c1791c101827780949fd633c531ed83037e7b4e
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
Add methods to get mcc/mnc as strings so that the leading-zero
ambiguity is resolved.
Test: manual (db update), unit tests
Bug: 35064313
Change-Id: I45c0bfefb7ffe98e3eab8e68d0e1170881ae9f4c
Merged-In: I45c0bfefb7ffe98e3eab8e68d0e1170881ae9f4c
Add methods to get mcc/mnc as strings so that the leading-zero
ambiguity is resolved.
Test: manual (db update), unit tests
Bug: 35064313
Change-Id: I45c0bfefb7ffe98e3eab8e68d0e1170881ae9f4c
Enable API user to create their own URLSpan for Linkify operations.
Test: atest android.text.util.cts.LinkifyTest
Test: atest android.text.util.LinkifyTest
Bug: 28536972
Bug: 32613009
Bug: 29150779
Change-Id: I9a2f995656bd1510502e5517ac737b47ebd33130
- Addition of getTypeAllocationCode & getManufacturerCode to
android.telephony.TelephonyManager.
- The Type Allocation Code is the first eight characters of the IMEI.
The Type Allocation Code identifies a particular GSM device model.
- The Manufacturer Code is the first eight characters of the MEID.
The Manufacturer Code identifies the manufacturer of a CDMA device.
- The reasoning behind adding getTypeAllocationCode is to be
able to obtain the Type Allocation Code without requiring the
READ_PHONE_STATE permission. Currently in order to obtain the
Type Allocation Code a substring operation must be performed on
getImei which is protected by the READ_PHONE_STATE permission.
- The reasoning behind adding getManufacturerCode is to be
able to obtain the Manufacturer Code without requiring the
READ_PHONE_STATE permission. Currently in order to obtain the
Manufacturer Code a substring operation must be performed on
getMeid which is protected by the READ_PHONE_STATE permission.
- The reasoning that these additional methods do not require the
READ_PHONE_STATE permission is that neither the Type Allocation
Code nor the Manufacturer Code can identify a unique device.
The Type Allocation Code and the Manufacturer Code are analogous
to other device information such as device model or device
screen dimensions.
Test: run cts -m CtsTelephonyTestCases
Bug: 74613795
Change-Id: I5a586b5a362b39aae13357329efb19eb93f0434c
Signed-off-by: David Kelly <dkelly@afilias.info>
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Enable API user to create their own URLSpan for Linkify operations.
Test: atest android.text.util.cts.LinkifyTest
Test: atest android.text.util.LinkifyTest
Bug: 28536972
Bug: 32613009
Bug: 29150779
Change-Id: Ia4495dc7e656044b91a79804d3b50a30cae98225
