Synced with alanv@ that doc weren't federated against AndroidX yet, use
this v7 reference until they migrate the docs to AndroidX.
Test: m -j offline-sdk-docs
Bug: b/116163454
Change-Id: Ib5167c4815708d159945ce6db239f8debdf8f865
The AccessibilityManager is a singleton, so we need to update it everytime
an activity is resumed.
Test: manual verification with Chrome (CTS test is an overkill here)
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Fixes: 112690889
Change-Id: If011db203dee96ec511da80f4e49395c0340f482
(cherry picked from commit ce40498dc2)
This affects several files beyond those mentioned in the bug.
I didn't fix some instances because the files had code
problems that blocked presubmit checks.
Test: make ds-docs
Bug: 37094741
Change-Id: I642f0384fef2b267ebc970bae1b4fb90bae667e7
Exempt-From-Owner-Approval: Docs-only change
Compact reminder with CTA to read more in Security & Privacy best
practices document.
Test: make ds-docs and inspect generated HTML in the browser.
Bug: 29000858
Change-Id: If74bfd50f85f044214f6db1950351d2f2014e0ae
Some changes to phrasing and punctuation to meet API Council guidelines.
Bug: 111149822
Test: make ds-docs and visual inspection of HTML
Change-Id: I2f7586cee3c1d0b41286f98cd0598cb6c62eafd6
(cherry picked from commit fcefd69c5b)
{@docroot} is relative to the root dir, not the host.
Updated the destination and anchor text to reflect the new OTA guide.
Bug: 111521364
Test: make ds-docs and inspect generated HTML
Change-Id: I937f47338e8c18637947944467803c1764938754
(cherry picked from commit 625f91aa46)
We do this by storing the masking inset in a persistent property.
The boot animation then animates itself to where it would be if that
masking inset were applied, then changes the viewport.
For this to work, we also need to make sure the DisplayManagerService
has the right overlay right at the start.
Bug: 112876936
Test: Hide cutout, then reboot. Verify boot animation is smooth.
Change-Id: I3e988b2340b2e0d2be3939bdc6878704c234ccc8
This isn't something apps generally can handle, so we kill all of
them for now.
Test: Change cutout overlay that changes display size
Test: Rotate screen
Bug: 112876936
Change-Id: Ic3b0f1b3ae1e9bd93ac8f2c6952aa093878602b8
The WeakReference based cache of Assets in use elsewhere in the
process remains unchanged.
Note that this change is larger than it needs to be because it is
an error to create an LruCache of size zero.
There seems to be no measurable difference as measured by the standard
app startup benchmarks.
Test: atest -v google/perf/app-startup/benchmark-app-hermetic/cold-dropcache-test
Bug: 111385832
(cherry picked from commit bc95621811)
Change-Id: Ib7a52bd03f6f13cdb76b82abc307d17227c4c1dc
- Print compatibility mode info and activity token on AutofillManager.dump().
- Add --autofill option on Activity so it just dump autofill state.
Also fixed checkstyle import warnings on ActivityManagerShellCommand.
Bug: 112417431
Bug: 112584717
Test: adb shell dumpsys activity top --autofill
Change-Id: Id56b56a5d7e591d5204663a1da1322a15f8ef3aa
(cherry picked from commit b546ca7916)
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
It isn't one, and I should have read the documentation on it properly
before treating it the same as EXTRA_LARGE_ICON (which is indeed a
Parcelable).
This fixes a chronic outpouring of technically-probably-harmless warning
stack traces of the following nature which can be verified by running
the framework tests and grepping logcat for this scary-looking string:
java.lang.ClassCastException: java.lang.Integer cannot be cast to
android.os.Parcelable
at android.os.Bundle.getParcelable(Bundle.java:***)
at android.app.Notification.fixDuplicateExtra
at android.app.Notification.fixDuplicateExtras
at android.app.Notification.readFromParcelImpl
Duplicate Integer objects are harmless compared to the Bitmap so there
is zero sense in recombining the objects after an RPC. We just drop the
line which tries to do that.
Test: make FrameworksCoreTests -j30 && \
Test: adb install -r ${ANDROID_PRODUCT_OUT}/data/app/*/FrameworksCoreTests.apk && \
Test: adb shell am instrument \
Test: -e class android.app.NotificationTest \
Test: -w com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I2c88ab4e9d5322c05e2e7f68df85ed5b2f296f84
Fix: 79404137
(cherry picked from commit 62eea67846)
Doc-only change to note that requestRestore() doesn't behave as expected
and kill the app as part of the restore operation.
Fixed formatting of first paragraph running into deprecation notice.
Also removed dupe versioning info from deprecation notice--see staged version.
Staged at:
http://go/dac-stage/reference/android/app/backup/BackupManager#requestrestore
Bug: 29255593
Test: make ds-docs and staged output. Visual inspection and manual link test.
Change-Id: I8baae2216f23bd63510f8b445fcdd8090354b0df
This CL fixes the problem that vendor public libraries (libs that are
listed in /vendor/etc/public.libraries.txt) are not loadable via
System.loadLibrary(). (Note that the libs were accessible via dlopen()
though.)
The problem was happening because when System.loadLibary() is called,
the classloader first checks whether the lib is found and accessible in
its own native lib search paths. The native lib search paths basically
come from the java.library.path property, which in turn is from
namespace.default.search.path in /system/etc/ld.config.txt. When VNDK is
enforced starting from P, namespace.default.search.path does not have
paths other than /system/lib because otherwise system process can have
unlimited access to libs in vendor partition. The linker namespace is
dynamically configured by the libnativeloader so that only the public
vendor libs are accessible. However, as a side effect of removing
/vendor/lib from namespace.default.search.path, the classloader always
fails to find any lib under /vendor/lib even if the lib is a public one.
In order to solve the problem, while keeping rest of the non-public
vendor libs from apps, /vendor/lib (and /odm/lib and /product/lib as
well) is added to the classloader AFTER native loader is created for the
classloader.
Bug: 93333337
Test: m -j
Test: System.loadLibrary("adsprpc") is successful in Pixel (because
libadsprpc.so is in Pixel's vendor public lib list)
Test: atest cts/tests/tests/jni
Change-Id: Iac12384548cbdd51234568082d02eeba466c160c
Th wait() call in AMS.getContentProviderImpl() can cause a deadlock when it
starts a new process for a target provider and all system server binder threads
are reaching out to the same provider at the same time, because AMS won't be
able to receive a callback from the provider process.
Let's serialize access to AM.getContentProvider() to avoid this scenario.
Longer team, we should stop waiting in the system server and instead do so in
the client side.
Bug: 74523247
Test: Boot, add a google account, and let syncs run and finish.
Test: Watch free video on Coursera
Change-Id: If5be2dc4b6f22f72d1bb3aa1b5b4d49f20c8d94d
OpEntry.duration was being used to indicate that the
operation was still running if -1 is returned. A recent
change caused a regression.
Adding a new mRunning field in OpEntry to explicitly
hold the running state, even when partial duration is
updated.
Change-Id: Ib29f4c903f990aaa202e84f964959aedfc24abdb
Fixes: 80242152
Test: atest FrameworksServicesTests:AppOpsActiveWatcherTest
Test: Launch maps and verify the location icon is visible
in the status bar
- Add icons to the right and shortcut modes
- Add color
- Make sure dialogs are secure
Test: manual
Bug: 79960669
Change-Id: I6d251b0ea5bd3c1b3eed32b184e4aae22c52ffb5
Fixes an issue where the group conversation heuristic was still
applied even when the app is targeting P. We're now following
the isGroupConversation completely and only do the migration
for apps targeting < P.
Change-Id: I471d58e8a8f5e6270f0dcce8691d08a2bdd1c582
Fixes: 78450835
Test: add messaging notification, observe correct display