Process start time is recorded to detect whether two memory samples
come from the same process and how long the process was alive.
Bug: 118249210
Test: atest MemoryStatUtilTest and manually verified that data is in
statsd report
Change-Id: I7f49cd8bfc81c5e7e70e4f8b49729632eeec5798
* changes:
Removed references to ATMS.getLockTaskController() from AMS (34/n)
Removed references to ATMS.mHomeProcess and mPreviousProcess from AMS (33/n)
As part of the storage changes in Q, we're removing the ability for
apps to directly access storage devices like /sdcard/. (Instead,
they'll need to go through ContentResolver.openFileDescriptor() to
gain access.) However, in several places we're returning raw
filesystem paths in the "_data" column. An initial attempt to simply
redact these with "/dev/null" shows that many popular apps are
depending on these paths, and become non-functional.
So we need to somehow return "_data" paths that apps can manually
open. We explored tricks like /proc/self/fd/ and FUSE, but neither
of those are feasible. Instead, we've created a cursor that returns
paths of this form:
/mnt/content/media/audio/12
And we then hook Libcore.os to intercept open() syscalls made by
Java code and redirect these to CR.openFileDescriptor() with Uris
like this:
content://media/audio/12
This appears to be enough to keep most popular apps working! Note
that it doesn't support apps that try opening the returned paths
from native code, which we'll hopefully be solving via direct
developer outreach.
Since this feature is a bit risky, it's guarded with a feature flag
that's disabled by default; a future CL will actually enable it,
offering a simple CL to revert in the case of trouble.
Bug: 111268862, 111960973
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ied15e62b46852aef73725f63d7648da390c4e03e
- Can be enabled/disabled at channel and channel group levels
- An activity to launch can be added to notification
Test: atest, cts
Bug: 111236845
Change-Id: I9a4832211676cca4649d1f28e6e3e3157954d268
- Create a check file for each database in order to detect
1) an unexpected DB file removal
2) DB wipe caused by a DB corruption.
- Either case, do a WTF to collect information on APR.
- Also print file timestamps in "dumpsys dbinfo". Example:
=====================
Database files in /data/system:
locksettings.db 20480b ctime=2018-10-23T22:48:35Z mtime=2018-10-23T22:48:35Z atime=2018-10-23T18:54:12Z
locksettings.db-wipecheck 0b ctime=2018-10-23T18:54:12Z mtime=2018-10-23T18:54:12Z atime=2018-10-23T18:54:12Z
notification_log.db 45056b ctime=2018-10-23T22:48:08Z mtime=2018-10-23T22:48:08Z atime=2018-10-23T18:54:13Z
:
=====================
Change-Id: I77fbeb0bb635c787aba797412f116475fecbe41c
Fixes: 117886381
Test: manual test
Test 1: corruption
1. Stop CP2 process (adb shell killall android.process.acore)
2. shell 'echo abc > /data/user/0/com.android.providers.contacts/databases/contacts2.db'
3. Launch the contacts app.
Test 2: Unexpected file removal
1. Stop CP2 process (adb shell killall android.process.acore)
2. shell 'rm -f /data/user/0/com.android.providers.contacts/databases/contacts2.db'
3. Launch the contacts app.
In both cases, logcat shows a client side stacktrace and also a WTF. (am_wtf)
This partially reverts the change that is suspected to be the cause of
b/117885969
This is to be reverted once the real cause is established.
Posting a temporary fix to unbreak the CTS test while figuring it out.
Fixes: 117885969
Test: atest CtsProviderTestCases:android.provider.cts.SmsBackupRestoreTest#testSmsBackupRestore
Change-Id: I7fd0b954d334501b050e9930643de4f6e41e229e
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
- Allow apps to learn if users chose the importance of a given
channel
- Allow the asst to query channels and channel groups of installed
apps
Change-Id: Ic65dfdc79d5135940c1debb101b849b5837d78b5
Fixes: 118140597
Test: runtest systemui-notification
Found two places where we forgot to remove TransitionListener in onTransitionEnd. I think it is important to clear it as if you reuse a transition object it will be leaked together with some views
Test: n/a
Bug: 64643817
Fixes in AndroidX: aosp/793641, aosp/795753
Change-Id: Iae0a9945a4158776f1a75c806c1f29efc049f96b
Add settingsSliceUri attribute for supporting live wallpaper inline-
control, public for AOSP live wallpaper to use.
Bug: 117200693
Test: atest tests/Internal/src/android/app/WallpaperInfoTest.java
Change-Id: Iffe9fbd9f49daf8a63d5745f91532de13b7288e3
When starting a process under instrumentation using this new
"--no-isolated-storage" flag, the process would be able to see the
full external storage.
Bug: 117229024
Test: adb shell am instrument --no-isolated-storage \
-e class android.media.cts.EncodeDecodeTest#testEncodeDecodeVideoFromBufferToBuffer720p \
-w android.media.cts/android.test.InstrumentationTestRunner
Change-Id: I7973b123cf4fc08e8ce2b05bd4c23fa41b1cdcdf
* changes:
Stopped starting and killing processes directly from ATMS (27/n)
Removed direct calls to AMS.broadcastIntentLocked from ATMS (26/n)
Removed references to ProcessRecord in ActivityStackSupervisor (25/n)
Some shell start activity commands set debug flags that requires us
to synchronously call into the process logic in AMS in the middle of starting
an acitivty in ATMS. To avoid dealock in this situation, we have the shell
commands go throuhg AMS to start activity which will in turn acquire the AMS
lock before calling into ATMS.
Bug: 80414790
Test: Existing tests pass
Change-Id: I407e0c6573cb903b9c2d2f635fd4d99ef833b026
Post messages to have processes started and killed instead which
should be okay.
Bug: 80414790
Test: Existing tests pass
Change-Id: Ia435aa815c36a84947ae0f76291b1d1f9222231d
The method is internal to AMS so can't be called directly from ATMS
which will be in a different package soon.
Bug: 80414790
Test: Existing tests pass
Change-Id: If36c7d9cb65e848101070f6b412c9067ee33741e
> Do not show starting window when using hero transition
> When running cross-task, only play the enter animation
> Allow transitions when using intent-sender
Bug: 113071278
Test: atest cts/tests/tests/transition/src/android/transition/cts/ActivityTransitionTest.java
atest cts/tests/tests/app.usage/src/android/app/usage/cts/ActivityTransitionTest.java
Change-Id: Id973d52412a9a2cde3ebcae3b718556c47dfff5d
Allows for better seperation of AMS and ATMS, also the method mostly
accessed internal variables in ProcessRecord so it make sense for it
to be in that class.
Also, move inputDispatchingTimedOut back to AM side because it involves
lots of process stuff.
Test: Existing test pass
Bug: 80414790
Change-Id: I45b98dc550ff121e9df4bf004b2667af2426b79d
The stack supervisor object should only be accessed through ATMS.
Test: Existing test pass
Bug: 80414790
Change-Id: I0648a95161a6a5c4ad714264d217c7f5e55852d7
Which processes to snapshot is controlled by a whitelist.
Benchmark for taking the snapshot:
https://docs.google.com/spreadsheets/d/1vG9ku8Uu8104CmKbO4cNeEKVeeByvHY--p0_dK1GAdA/edit?usp=sharing
(The difference between the first two sheets.)
~20ms constant cost plus ~4ms per process.
Bug: 115968899
Test: manually verified that statsd is included in the report
Change-Id: Iba680531c563ba28fae849e44044313866b2103f
When device identifier access was moved from a runtime permission to a
privileged permission device and profile owner access regressed by no longer
requiring consent to access the identifiers. With this change device and
profile owners will still need to have the READ_PHONE_STATE permission to
access identifiers.
Bug: 117611604
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases \
-t com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases \
-t com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers
Change-Id: Ib2d86440c531eab075d010de183ccfa45c2443e5
This change makes touch ripples appear correctly on the action buttons
on media notifications. This involves the following changes:
- NotificationViewWrapper.onReinflated() sets the notification content
root's background to transparent rather than null when transferring the
background color to the NotificationBackgroundView. This gives the
ripples a surface to draw on.
- The RemoteViews for the media templates are changed to use a fixed
set of buttons instead of removing and re-adding them on every update.
This prevents the update caused by whatever action the tap invokes from
interrupting the ripples.
- A method is added to RemoteViews allowing the ripple color to be
specified. This allows us to change the ripple color to match the
foreground color of the controls, which is necessary for the ripples to
show up against a dark background.
Test: manual
Change-Id: I907f9a1a75efb48da496133ad357fc5150de4410
Fixes: 35856702
A new API for setting the Private DNS settings value programatically via
the DevicePolicyManager.
Since there are two separate settings for Private DNS, and the value
provided for the hostname needs to be validated, a new
DevicePolicyManager API is introduced.
Only a Device Policy Client in Device Owner mode may change these
settings.
The DPC may additionally set a user restriction (added in a separate CL)
to prevent the user from changing Private DNS settings.
Bug: 112982691
Test: atest com.android.cts.devicepolicy.DeviceOwnerTest#testPrivateDnsPolicy
Change-Id: I566437e4fe10e1346858149120c50b3c20ca073f
