CL Id0a4200f912ac3303026cb26b6d8974c47332828 sets a system property
"ro.art.hiddenapi.warning" for non-release, non-user builds. This
patch reads that flag and unless the flag is set, will only ever show
the warning message if the app is debuggable.
Test: manual
Bug: 64382372
Change-Id: I9b552792779589a7a91818a82d5c86141fc0a30b
Status: Ready for review
Note: This is a Javadoc only change.
Changes: Removed unnecessary "(TODO)" note.
Test: Build the docs with "make ds-docs" and staged updated content.
Staged content:
go/dac-stage/reference/android/app/Notification.html#FLAG_SHOW_LIGHTS
Bug: 20150478
Change-Id: I3a7fc0414ccb6f52e9b4919031a93ca1a7a29336
This CL attempts to clarify that just having a ContentProvider does
not necessarily mean ContentProvider#onCreate() is always called
before Application#onCreate() on Android N and later devices because
of direct boot.
Fix: 67559645
Test: make -j doc-comment-check-docs
Change-Id: I33b7cda42146333f48fb445027f5d31f3c5af5b6
Freeze period is defined as a pair of calendar dates (recurring annually)
during which the system should block any incoming system updates, including
security patches. They are set on top of existing system udpate policy
types (automatic, windowed, postpone) such that outside the freeze
periods existing policy semantics will still apply. They are created to
allow admin to keep their device fleet from any destabilizing changes during
critical period of the year, for example during Christmas sales period.
Device Owner can set several freeze periods, although to prevent the device
from not receiving OTAs indefinitely, each single freeze period is
restricted to be at most 90 days, and adjacent freeze periods need to be at
least 60 days apart. To properly enforce these restrictions, any freeze
periods the device previously experienced is tracked by DevicePolicyManager
and are validated against any new policy. This is to deal with corner cases
such as the admin repeatedly set a short but overlapping freeze period on a
rolling basis, hence bypassing the 90-day freeze period restriction.
Test: runtest -c com.android.server.devicepolicy.SystemUpdatePolicyTest frameworks-services
Bug: 64813061
Change-Id: I2864192797dc194edd9c183b881da6cfe3fdba5e
This flag will allow the sync manager to exempt certain kind of sync requests.
- This will only exempt jobs from app-standby.
- EBS still won't exempt them. Battery saver cuts background network anyway, so
background syncs will still not work, and it didn't used to work pre-P either.
- Manual force-app standby still doesn't allow them to run.
Bug: 72443754
Test: Build and boot. The behavior shouldn't change since none uses the flag yet.
Test: atest CtsJobSchedulerTestCases
Change-Id: I806b97bb4b7da773479e878e6eccb792b03eadc1
Throw SecurityException from setMandatoryBackupTransport if
in a parent instance.
BUG: 72332943
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test
com.android.cts.devicepolicy.ManagedProfileTest#testParentProfileApiDisabled
Change-Id: Iff2367256ce372641fd5569ad27b32f0894597ce
App transitions, from ActivityManagerInternal, are now referenced via a
proto enum. This is also referenced by statsd's atoms.proto.
Bug: 69478930
Test: still compiles
Change-Id: Ifb5cb0120d4cd4e2464ce3b5a7455842cb55259c
We move to the start state when launching a tabbed activity through
LocalActivityManager, but currently do not inform the activity
thread due to changes in how ActivityThread is updated through the
ActivityLifecycler. This changelist addresses this issue.
Change-Id: Ibc2bda39617e1741bb3ee8637a182dc9f14dd61d
Fixes: 70813462
Fixes: 70812753
Test: atest CtsAppTestCases:android.app.cts.LifecycleTest
Test: atest LocalActivityManagerTest
Test: atest ActivityGroupTest
* changes:
Fix issue with reparenting stacks on displays.
Revert "Revert "4/ Update SysUI shared lib for Recents transition""
Revert "Revert "3/ Add input consumer to capture touches during a Recents transition""
Revert "Revert "2/ Add support for remote Recents animation""
Revert "Revert "1/ Create display content window controller to position stacks in the display""
According to the documentation surrounding the resource manager
lock, the lock should _not_ be held when calling back into the
activity manager. The process of getting the system context [in
order to obtain the theme] _may_ call back into the activity
manager.
Change-Id: Ibddf728a39e651f0b3ec1e2f56e09da233b963c3
Fixes: 71592993
Test: Manual
- Changed AM.getGrantedUriPermissions() API.
- Made DocumentsContract.PATH_TREE public.
Also fixed related AM methods to use explicit for on some loops.
Bug: 63720392
Test: manual verification
Change-Id: I33bdcb949f4301534bd8467c8018d6f03b4588a4
* changes:
Added the reply draft as an extra to the content intent
Launching notification settings correctly inline
Launching Notification animations inline
