Test: change pin and immediately crash the kernel with
adb shell 'su root sh -c "echo c >/proc/sysrq-trigger"' and boot
Bug: 112175067
Change-Id: Ia5f43f3118e2297fbea43c805ef2f4577bf8a9bf
(cherry picked from commit 50e00c8dc4)
Altough these are super spammy, they're super valuable when debugging why
compat mode doesn't work.
Bug: 112417431
Fixes: 112584717
Test: adb logcat AutofillManager
Change-Id: I1574b51b1c6caf783038b82ff207986b726b2e8b
(cherry picked from commit 5d35d3d2d6)
Public API doesn't see android.logicalcam.physicalIds. Remove it
from public doc.
Bug: 112655222
Test: make offline-sdk-docs
Change-Id: Idf6958fb7c117912e33ece4fbaed04cb8e5e14c0
The crash was introduced by Ib66ef392c19c937718e7101f6d48fac3abe51ad0
The root cause of the crashing is requesting out-of-line access for the
horizontal width. This invalid access is silently ignored by
TextLine#measure() method but new implementation end up with out of
bounds access.
To makes behavior as old implementation, calling getHorizontal instead
of accessing measured result array.
Bug: 78464361, 111580019
Test: Manually done
Change-Id: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
(cherry picked from commit 960647d582)
Merged-In: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
Update docs to clarify that plugins are in fact not supported from K
onward and that enabling them doesn't do anything.
Bug: 112579915
Test: m offline-sdk-docs
Change-Id: I8678ea716be0adc4cd3a6fae1b4776e312ec29e0
(cherry picked from commit 1676c95ddc)
Remove the reference to the specific ACTION_STORAGE_CHANGED intent as
other intents are used instead on newer OS versions; just note that it's
cleared automatically when the keychain is updated and don't specify the
exact mechanism.
Change-Id: Ic677832a1384e0eb2498d06e7aa34507fd2e7278
Fixes: 30371615
Test: make offline-sdk-docs
(cherry picked from commit 01eb128213)
Update javadoc for WebBackForwardList and WebHistoryItem. Remove
references to history items being updated as this no longer occurs, and
clarify in clone() that there's no need to acutally do this any more.
Also remove a bunch of implementation notes about
atomicity/synchronisation that are being rendered attached to the return
value and likely aren't even true any more, let alone relevant to
developers.
Bug: 74593032
Test: make offline-sdk-docs
Change-Id: I4ce33133d2ff18e7376d768c7a2e076ecd2a8b95
(cherry picked from commit 8949046528)
Removed unused imports android.app.Activity and
android.os.UserHandle because of checkstyle fail.
Test: make ds-docs
Bug: 111760788
Change-Id: I2852fea6c4b55a3422712c113d081abd40d02dfd
Logging activity starts to TRON, but only if the caller app
doesn't have any foreground activity present.
Example event:
08-03 15:21:30.813 1231 3220 I sysui_multi_action: [757,1513,758,4,805,1533306090812,1514,10147,1515,com.google.android.talk,1516,1018,1517,0,1518,1000,1519,1000,1520,0,1521,10147,1522,com.google.android.talk,1523,1018,1524,0,1525,pendingintent:u0a12:com.google.android.talk/com.google.android.apps.hangouts.phone.ConversationActivity,1526,com.google.android.talk/com.google.android.apps.hangouts.phone.BabelHomeActivity,1527,1,1528,com.google.android.apps.hangouts.phone.conversationlist,1540,1,1541,com.google.android.apps.hangouts.phone.BabelHomeActivity,1542,3146240,1543,{com.google.android.talk/com.google.android.apps.hangouts.phone.BabelHomeActivity},1544,com.google.android.talk/com.google.android.apps.hangouts.phone.BabelHomeActivity,1545,com.google.android.talk,1546,1,1547,0,1551,0,1552,0]
(cherry-picked from 201bc0c14e)
Bug: b/111866309
Context: go/activity-starts-logging-tron
Test: 1) enable logging with: adb shell settings put global activity_starts_logging_enabled 1
2) open some activities and observe: adb logcat -b events | grep "sysui_multi_action: \[757,1513"
Test: atest FrameworksServicesTests:ActivityStarterTests
Change-Id: Ie7dee51c574e544d12e83d279afda46b336f2013
Call out more explicitly the antipattern of calling loadUrl with the
same URL and returning true, and repeat this on the deprecated version.
Simplify the wording about returning true v.s. false. Switch to the
"note" style used elsewhere on the page.
BUG:111843379
Change-Id: I36c31a8e0f4754c314b8a4d72cc497c9c3a3e242
Test: make docs
(cherry picked from commit 3819a6467b)
For the various Build.VERSION_CODES.<version_name> constants, adding
a link to the appropriate "about this release" page in
/about/versions/ , if there is one.
Staged doc to:
http://go/dac-stage/reference/android/os/Build.VERSION_CODES
Bug: 80546406
Test: make ds-docs
Change-Id: If363445c938d325172da6beeed25e821121c5539
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.
Bug: 111085900
Test: atest packages/providers/DownloadProvider/tests/
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Change-Id: Ib4fc8400f184755ee7e971ab5f2095186341730c
Merged-In: Ib4fc8400f184755ee7e971ab5f2095186341730c
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: I6e8746fa48f9de13adae37d2990de11c9c585381
Merged-In: I6e8746fa48f9de13adae37d2990de11c9c585381
- Add more notes on coordinate axes
- Add more text on metadata when distortion correction is active
- Note that poseTranslation needs to be negated in many use cases
- Fix coordinate system references for OIS reporting, add more information
- Note that pixel centers at half-integers for the camera API metadata
such as lens intrinsics
Bug: 79371566
Bug: 74434422
Bug: 109742048
Bug: 109834325
Bug: 109817371
Bug: 112107924
Test: Manual reading of added text
Change-Id: I450e80b79ef66ce8d82a4dee835db6abd1e598a3
Before applying this patch, when a show-when-locked immersive app is
showing, the system bars would quickly show and hide, which are
redundant to the user.
The root cause is that, for nav bar, we have a policy to show nav bar
if the width and height of status bar are MATCH_PARENT and status bar
has no PRIVATE_FLAG_KEYGUARD. When keyguard is becoming status bar,
its keyguard flag would be removed first, and then the height would
be changed to the bar height. So the nav bar would be shown between
these events. For status bar, we force showing it when it is expanded
by checking its width and height are MATCH_PARENT or not.
To fix the issue, this change introduces a new private flag which
indicates that the status bar window is now in an explicit expanded
state. We check this flag instead of checking the width and height of
status bar.
This change also fix a bug that: when AOD is enabled, if the
foreground app has FLAG_SHOW_WHEN_LOCKED, FLAG_TURN_SCREEN_ON, and
FLAG_FULLSCREEN, clicking on the power key would make it show the app
again instead of AOD. (not 100%, but chances)
Bug: 80147982
Test: 1. go/wm-smoke
2. Launch a show-when-locked turn-screen-on immersive app on
AOD, and see if any system bar flashes.
3. Launch a show-when-locked turn-screen-on immersive app on
lockscreen, and see if any system bar flashes.
4. a. Enable AOD in Settings.
b. Open a show-when-locked turn-screen-on immersive app.
c. Click on power key, and see if AOD shows.
5. Launch an immersive app and drag down the status bar, see
if nav bar keeps there as long as status bar is expanded.
Change-Id: Ie885d504eb73ae8a86736b2c3ed4fb03eb9f739e
Merged-In: Ie885d504eb73ae8a86736b2c3ed4fb03eb9f739e
(cherry picked from commit 3404601e07)
Specifically, a change in state from one DND provider
shouldn't result in another's state being cleared if they
aren't yet bound (or are intentionally unbound).
Fixes: 111251709
Test: cts, cts-verifier
Change-Id: I42a0ba935577e708d9df02e2a6d3620e42395a51
(cherry picked from commit 8f05600189)
Such that it gets executed after setSurface, in order that
mReqUsage has the correct flags set.
Test: Take trace, ensure that allocateBuffers actually allocates
in the right format/usage by ensuring that dequeueBuffer doesn't
trash them immediately again.
Bug: 111517695
Change-Id: I94b402d7b29d565155a77a2d09106246261712d2
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
Merged-In: I6cdbc06d089efeb1c72a51216879ba0573502009
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
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
