This setting should be private to GPP, and there should be no reason
for any app to access it. And GPP is migrating away from this
relatively public setting, so it can't be relied upon.
Test: Builds
Bug: 135751498
Bug: 37119785
Change-Id: I839c2d67ae54b4df184ea7ee1c7aebee72c6e794
We're working towards making MediaProvider into a Mainline module,
which means it can no longer share the "android.media" UID built
into the OS. The major reason for this is because they're signed
with separate keys, but a secondary reason is that we don't know what
database customizations an OEM has performed in their MediaProvider.
This initial pass introduces the APIs needed to support a "legacy"
MediaProvider that will be used to migrate data between the old and
new UID. This legacy provider is implemented using the same code
as the modern provider, but hosted at the "media_legacy" authority.
Bug: 144247087
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ibc38a786799e138e9c3e31297c7066bab6843d89
Add new TelecomManager#getDefaultDialerPackage which is multiuse aware;
this is used when showing the voicemail notification.
Remove some @hide methods from Conference; push these inline.
Move ConferenceParticipantConnection into frameworks/opt/net/ims since
it is just an IMS implementation detail.
Bug: 141576016
Test: Manual smoke test.
Test: Run unit tests.
Test: Run CTS tests.
Change-Id: I39b6955cb14cc1ca68b05c620c3d09a2cdfe30c9
Since we are removing such capability in the other topic CL. Check that
CL for rationale.
Test: Builds
Bug: 135920175
Change-Id: I9d1d5afb1d72270a81888bea3ec0bd6f2f4e9542
For supporting the mechanism for apps to add saved networks to the device, need to:
1. Add one new intent action.
2. Define two extra keys for passing data to Settings APP and get result
back.
3. Define 3 result codes.
Bug: 136472483
Test: just add action, test case will be in Settings App side.
Change-Id: I7391a6b8d89bd4621aab833b2da2a981f7b8163b
The European Commision prescribes an auto-standby feature for TV panels:
After some hours of inactivity, the device has to go from on-mode to
standby-mode or off-mode, or another condition not exceeding the
applicable requirements for standby-mode or for off-mode.
After a long time of no user activity the device should go to sleep,
even if wakelocks are held (eg. during video playback).
Test: 1. Set attentive timeout low, to 35s:
`adb shell settings put secure attentive_timeout 35000`
2. Play a YouTube video
3. Observe warning dialog appearing after 5s
4. Verify: Clicking a remote button or changing the setting higher hides
the warning. Remote button press is consumed.
5. Verify: After 35s of not pressing a button the device goes to sleep
6. Verify: If "Stay awake" developer option is enabled, then
warning is not displayed and device does not go to sleep after 35s
7. Verify: No warning or sleep if setting is set to -1
Test: `atest frameworks/base/services/tests/servicestests/src/com/android/server/power/PowerManagerServiceTest.java`
Bug: 137633812
Change-Id: I551b6cffc336437fb1c5a00b4102f68ae0e003e9
Add new SystemApi methods for Telecom to call in lieu of the old @hide
methods. Also moved CallerInfo and CallerInfoAsyncQuery to Telecom
because there are no more users in Telephony.
Bug: 141576016
Test: CTS
Change-Id: I458ba6bcfc03db72c0419b0cab2f0d0adfa971d4
Add new attribute capability to ProcessRecord, it represents what this
process is allowed to do. Capability is a separate dimension for
process state (ProcState).
In OomAdjuster.java, capabilities can be passed from client to service.
Add PROCESS_CAPABILITY_FOREGROUND_LOCATION to represent the capability
that can access location while-in-use.
For permission such as foreground location access, AppOpsService
checks for FOREGROUND_LOCATION capability, also checks if the process
is in one of the foreground process states, if both conditions meet,
the locaton operation is allowed.
Remove PROCESS_STATE_FOREGROUND_SERVICE_LOCATION.
Bug: 136274596
Test: atest CtsAppTestCases:ActivityManagerProcessStateTest
atest CtsAppTestCases:ActivityManagerApi29Test
atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/appop/AppOpsServiceTest.java
Change-Id: Ie1c8e670fb0789208b753eb49b7e2fce6a2f211f
Before Q, the thumbnail has wrong rotation, the developers need
to rotate it to correct rotation manually. As of Q, we provide
the correct rotation of the thumbnail.
Test: m -j
Bug: 142601201
Change-Id: I9c472f47b2bd0c3191ff55d1eb8d21303437dedd
This takes the Context#getFeatureId from the calling context and pipes
it all way through to the noteOp calls done by the content provider.
Bug: 136595429
Test: atest CtsAppOpsTestCases (new test added to capture this case)
TelecomUnitTests:CallLogManagerTest
ContentProviderClientTest
TelecomUnitTests:MissedCallNotifierImplTest
TelecomUnitTests:BasicCallTests
MediaInserterTest
PreferencesHelperTest
RankingHelperTest
PinnedSliceStateTest
FrameworksCoreTests:ContentResolverTest
Change-Id: I53b1035626229c920b353509a5bece157b52fb51
Over the last year we've been converging on saying that MediaProvider
is an indexed view of values that developers can obtain directly from
MediaMetadataRetriever. This change starts indexing several fields
of interest to bring these two surfaces into sync.
Since we're going to be asking MediaMetadataRetriever about audio,
video, and image files, it could return any metadata values for any
of those file types, so we're adding and promoting fields up to the
MediaColumns level.
Bring back APIs related to "trashing" media items; they had been in
place for the last release, but were hidden until we had firm
requests to add them, and partners have now requested them. Also
add APIs for marking media items as "favorite", as requested by
partners.
Bug: 135343128, 142478744, 122025511, 142498573
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ie839ec1b2eed621786d0d10f35a061cbc52f192b
Previously DeviceConfig, Settings.Config, and SettingsProvider needed to
understand how to append "/" to a namespace to create the prefix for key
names before saving them in SettingsProvider. This removes that
duplication and lets all of the compositing and decompositing happen in
Settings.Config.
Test: atest FrameworksCoreTests:DeviceConfigTest
atest FrameworksCoreTests:SettingsProviderTest
atest SettingsProviderTest:DeviceConfigServiceTest
Bug: 136135417
Change-Id: I126155594f3e764e149a4928d1b3708da68c97f4
Currently, when a display is in freeform mode, an activity that
is not resizable launches in fullscreen. However, for large
screen devices, it is preferable to launch activities in windows
to create the true desktop experience. This CL changes launch
configurations and resize actions to make non-resizable activities
launch in a window and to prevent resizing of these windows. When
the display enters fullscreen mode, the activity keeps its original
bounds and launches in a letterbox.
To make this all work, ActivityRecord was updated to use the
hierarchy instead of trying to recalculate everything independently
with a fullscreen assumption. The result is that the ActivityRecord
configuration now (mostly) has the actual bounds of the app so
that positioning works properly.
Please note, the following tests were removed because the
functionality they were trying to test has changed. Previously,
when a task was nonresizeable, even if the display windowing mode
was freeform, it was launched in fullscreen mode. However this CL
allows nonresizeable tasks in freeform mode to be launched in
windows. These tests were removed since they are redundant
with non-resizable (which is handled by packagemanager):
- TaskLaunchParamsModifierTests#testForceMaximizesPreDApp
- TaskLaunchParamsModifierTests#testForceMaximizesAppWithoutMultipleDensitySupport
The following tests were added:
- TaskPositioningControllerTests#testHandleTapOutsideNonResizableTask
- TaskLaunchParamsModifierTests#testLaunchesAppInWindowOnFreeformDisplay
- ActivityRecordTests#testSizeCompatMode_KeepBoundsWhenChangingFromFreeformToFullscreen
This also adds a developer option to enable size-compat
apps to start in freeform mode.
Test: go/wm-smoke
Change-Id: I3aa3fcdcd2b1e0b875d61dfaed3d5e85313edc29
AWARE_TAP_PAUSE_GESTURE_COUNT is the number of times the user
has used the Motion Sense tap gesture to pause media. This number
is used to determine whether to show the "Tap to pause media"
contextual tooltip.
AWARE_TAP_PAUSE_TOUCH_COUNT is the number of times the user has
touched the device to pause media instead of using the Motion Sense
tap gesture (Motion Sense and tap gesture must be active for this value
to increment). This number is also used to determine whether to show the
"Tap to pause media" contextual tip.
We back up these counts so that users moving to new devices with Motion
Sense will not be given these contextual tips again if they already know
how to use the feature.
Test: manual
Bug: 138296598
Change-Id: I702719fb7cec8b6be9dff91d212a00fb26129957
Merged-In: I702719fb7cec8b6be9dff91d212a00fb26129957
(cherry picked from commit a6e468831a)
AWARE_TAP_PAUSE_GESTURE_COUNT is the number of times the user
has used the Motion Sense tap gesture to pause media. This number
is used to determine whether to show the "Tap to pause media"
contextual tooltip.
AWARE_TAP_PAUSE_TOUCH_COUNT is the number of times the user has
touched the device to pause media instead of using the Motion Sense
tap gesture (Motion Sense and tap gesture must be active for this value
to increment). This number is also used to determine whether to show the
"Tap to pause media" contextual tip.
We back up these counts so that users moving to new devices with Motion
Sense will not be given these contextual tips again if they already know
how to use the feature.
Test: manual
Bug: 138296598
Change-Id: I702719fb7cec8b6be9dff91d212a00fb26129957
The periodic parole window is the 10 minute window that occurs every
24 hours to let RARE apps run. Now that we have the quota system in
place, there's no need to have the periodic parole window. Alarms and
jobs will still be allowed to run when charging. Network will continue
to be restricted for RARE apps even when charging. JobScheduler requests
an exception for RARE jobs in quota, so they will still be able to run.
Bug: 136184981
Test: atest AppStandbyControllerTests
Test: atest CtsAlarmManagerTestCases
Test: atest NetworkPolicyManagerServiceTest
Test: atest com.android.cts.net.HostsideRestrictBackgroundNetworkTests
Test: atest com.android.server.AlarmManagerServiceTest
Test: atest com.android.server.AppStateTrackerTest
Test: atest com.android.server.job.controllers.QuotaControllerTest
Test: atest com.android.server.net.ConnOnActivityStartTest
Change-Id: Ide382ad7fb9c7441f0a5232833ad39bf8c3a1e94
