Related changes are introducing new TypedXmlSerializer and
TypedXmlPullParser interfaces which offer efficient access to
primitive attributes.
This change is a purely mechanical refactoring to prepare for
upcoming data format shifts, and has no behavior changes.
Bug: 171832118
Test: manual
Exempt-From-Owner-Approval: trivial no-op refactoring
Change-Id: Ib8045ddba489c254641d6331b64355709c3f6dd7
Some careful spot-checking has revealed common cases where it's
reasonable to blanket apply the new FLAG_IMMUTABLE option to newly
created PendingIntents. Specifically these situations:
-- Simple notification content clicks are immutable; there's no need
to communicate customized data back to the creator
-- Simple notification action clicks are immutable; there's no need
to communicate customized data back to the creator
-- Broadcast intents sent by AlarmManager are immutable; the system
dispatches them without customization.
Bug: 170165227, 170424283, 170425388, 170425877
Bug: 169791183, 170771965, 170226088, 170224928, 170767530
Test: none
Change-Id: I5ed68710d2ccad4635a30fd91136a9e6ad76a01d
* changes:
Upgrade AndroidFrameworkBinderIdentity to fatal.
Tighten up Binder.clearCallingIdentity() usage.
Tighten up Binder.clearCallingIdentity() usage.
Tighten up Binder.clearCallingIdentity() usage.
To determine whether a user has a badge, the
correct call is now hasBadge, rather than isManagedProfile.
Currently, the only user that actually can have a badge
is a managed profile, so this change is a no-op. In the future,
if further profile support is expanded, then hasBadge will
be correct.
Bug: 170249807
Test: Treehugger (this cl is a no-op)
Change-Id: I9144c4dc519936dfc5a2aeae0eb0bd91bea89db2
The recently added AndroidFrameworkBinderIdentity Error Prone checker
examines code to ensure that any cleared identities are restored to
avoid obscure security vulnerabilities.
This change is a purely mechanical refactoring that adds the "final"
keyword to the cleared identity to ensure that it's not accidentally
modified before eventually being cleared. Here's the exact command
used to generate this CL:
$ find . -name "*.java" -exec sed -Ei \
's/ (long \w+ = .+?clearCallingIdentity)/ final \1/' \
{} \;
Bug: 155703208
Test: make
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: I832c9d70c3dfcd8d669cf71939d97837becc973a
This is just a plain refactoring: the removed methods in the changed
classes were called by default by the new methods in the superclass
(SystemService).
Test: m
Test: atest NotificationManagerServiceTest BackupManagerServiceRoboTest
Fixes: 161943081
Exempt-From-Owner-Approval: refactoring without side-effects
Change-Id: Ifd8df592eb4494cc0922b7e0b2ff20187b8a8b3e
RemoteViews is public API used out of scope of widget. The correct place
to call noteAppWidgetTapped is in AppWidgetHostView.
Fix: 153676411
Test: manual test, tap a widget, "adb shell dumpsys usagestats | grep
USER_INTERACTION" to oberserve USER_INTERACTION event sent to UsageStas, "adb shell dumpsys appops | grep appWidgetVisible" to observer appWidgetVisible flag.
Change-Id: Ic473211b91fd952dbb81b09b1e1568d6f69a0dd8
When the app widget on the launcher is tapped on:
1. Update AppOps. AppOps treats the underlying app as foreground so the app can get while-in-use
permission.
2. Report a USER_INTERACTION event to UsageStats so UsageStats can
update mLastTimeUsed and mLastTimeVisible of this package.
Bug: 149043079
Test: manual test, tapped on a widget.
Change-Id: Ic8c91190881cf5dcf89f0f72cfd410b0c2e86bf6
When launcher moves away from TOP, param visible is false, should skip
the proc state check and move ahead to update AppOps.
Bug: 151835293
Test: Manual test, open another app and move launcher away from top
screen, observe AppOps is updated.
Change-Id: I4b1562994d205d7e5b0327b95cf59e08b91ae048
After restore, the app should set OPTION_APPWIDGET_RESTORE_COMPLETED to
true on its widgets followed by calling updateAppWidget to update views.
Bug:63667276
Test: Manual
Change-Id: Idb6fc63b0f894fca9e0470aaf335240fc124e2e9
Make obtaining a visual service from non-visual Context instance
report a strict mode violation and print the stacktrace.
Make calling getDisplay() throw an exception if called on an instance
that is not associated with a display. For existing usages introduce
a new internal method that does not perform the verification until
the usages are properly fixed.
Bug: 128338354
Test: StrictModeTest#testIncorrectContextUse_GetSystemService
Test: StrictModeTest#testIncorrectContextUse_GetDisplay
Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
Replace the existing usages of now-deprecated API
WindowManager.getDefaultDisplay() with WindowMetrics or
Context.getDisplay() in frameworks/base.
Bug: 128338354
Test: Build, auto test
Change-Id: I02d38a022c5e0e6e9d699f03d35b65d6c8126da9
1. Background started foreground service shall not have
while-in-use permissions including location, camera and
microphone. Many exemptions have been applied including:
--FGS started by widget.
--FGS started by notification.
--FGS started by IME or other visible app.
--FGS started by ROOT_UID, SYSTEM_UID, NFC_UID.
2. Add a phenotype key KEY_DEFAULT_BACKGROUND_FGS_STARTS_RESTRICTION_ENABLED
to turn on/off this feature (default is on).
3. In dogfood, if a background started FGS with while-in-use permission
(any of location/camera/microphone) run into this restriction, the FGS
will not been granted these permission. we show a toast message to
alert user and ask them to write a bugreport using instruction at
go/r-bg-fgs-restriction. So we can have a statistic how many apps will
be impacted by this feature.
These is a flag Settings.Global.FOREGROUND_SERVICE_STARTS_LOGGING_ENABLED
to turn on/off the toast message (default is on, in dogfood)
Bug: 136219221
Test: atest android.app.cts.ActivityManagerProcessStateTest
atest android.app.cts.ActivityManagerApi29Test.java
atest android.app.cts.ActivityManagerFgsBgStartTest
Change-Id: Ibc8aaa6839a69136f9311bfacdbab9705b31b6a7
The suspending app can specify if they want to unsuspend the app on
neutral button tap. This needs to be done by the system so as to
maintain continuity of the users activity tasks.
The system then also needs to communicate to the suspending app when
such an unsuspend has taken place so it can keep any of its internal
data consistent with the current state.
Test: atest FrameworksServicesTests:PackageManagerSettingsTests
atest FrameworksServicesTests:SuspendDialogInfoTest
atest GtsSuspendAppsTestCases:SuspendPackagesTest
Bug: 134962563
Change-Id: I587b2643eb41519b82b8e2b371a466a9fb650d4b
The animation is deferred until a cross-profile activity
is started from the dialog.
Test: Manual:
1. Install any app that uses cross profile API
2. Suspend the app in one profile only
3. Navigate to the profile instance from within the app
Fixes: 144840723
Change-Id: Ia86708c1c4d708e2bae454b4cfe1ba8d4b413c5c
We want to allow wellbeing apps to suspend in managed profiles.
This requires changing the internal data design of package-suspend
state to allow more than one suspending package, each with their
own parameters, namely - dialog info, app extras and launcher extras.
Also, removed the restriction of using setPackagesSuspendedAsUser when a
PO/DO exists
Test: atest com.android.server.pm.PackageUserStateTest
atest com.android.server.pm.PackageManagerSettingsTests
atest com.android.server.wm.ActivityStartInterceptorTest
atest GtsSuspendAppsTestCases
Bug: 138812320
Change-Id: If1263142fc9e6687e95af9b8d71ba8eff0c0fae9
The suspending app has more context about why a particular app was
suspended by the user, but we do not want to delegate the interception
of the suspended activity out of the system.
Hence allowing it further customizations to the dialog to make
it clearer.
Test: atest com.android.server.pm.SuspendDialogInfoTest \
com.android.server.pm.SuspendPackagesTest \
com.android.server.pm.PackageUserStateTest \
com.android.server.pm.PackageManagerSettingsTests \
com.android.server.am.ActivityStartInterceptorTest
atest GtsSuspendAppsPermissionTestCases GtsSuspendAppsTestCases
Bug: 112486945
Bug: 113150060
Change-Id: If9f4d14587a2b75bb572e7984a90e300a2c72d16
Don't hold locks while manipulating alarms within the app widget
server, because the joint dependencies on activity manager locking
cause problems.
Change-Id: Ic7a09e6938277df7201be515f9785f326552f166
Bug: 115894687
Test: manual (repeated rebooting including with alarms forced)
Widget presence in the home app is important for usability, but it
depends on a broadcast-based handshake at boot time. This handshake
occurring after the BOOT_COMPLETED broadcast was initiated means
that in practice widgets may not become available for literal
minutes following unlock, as it can take this long for the
boot-complete broadcast to clear and let the systen proceed with
dispatch of the widget handshakes.
We address this by hoisting the widget setup broadcast to occur
just *before* the boot-completed broadcast, rather than as part
of general listener reaction to the global "this user has been
unlocked" notification.
Bug: 76154638
Test: manual (note broadcast ordering following boot)
Change-Id: I7c1a9f7a84fee71f71d2dcd52362a29c2436b01d
Widgets get masked with separate remove views when suspended. Need to
update them with the correct pending intent. Moved around the logic
creating the suspended alert activity to make it reusable.
Test: Manually, "pm suspend <app-with-widget>", followed by tap on
widget
Existing tests pass:
atest GtsSuspendAppsTestCases
atest com.android.server.am.ActivityStartInterceptorTest
Bug: 79474038
Change-Id: Ic75ee762434bf92c54bda307e9cb6018f94a914c
This would allow apps to customize the behaviour/appearance of a widget based
on the app state
Test: atest CtsAppWidgetTestCases:UpdateProviderInfoTest
Bug: 63931362
Change-Id: I1eef705975c2310af7311b74acc23c089fb6d1ec
> Using the AppWidgetProviderInfo for applicationInfo instead of getting
it from packageNamager
> Sending ProviderInfo update when the package is suspended/unsuspended so
that the provider info on client side is always up-to-date
Bug: 67865199
Test: Manually tested on device
Change-Id: Id44facc30b4c3cc01e155eba9feeb541997fc816
The host passes an IServiceConnection to the AppWidgetManager which
is used to bind to the RemoteViewsService. This allows the host to
recieve the connection callbacks directly instead of proxying it via
the AppWidgetManager. The host is also responsible for unbinding to
the service.
Bug: 26481160
Test: adb shell \
am instrument -w -e class android.widget.RemoteViewsAdapterTest \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Iac400095a319c3a43714c82fda7516be1ccc68af
if there was no widget update in-between
Bug: 67736800
Test: Added corresponding test in AppWidgetServiceImplTest
Change-Id: Ib3213f8f79ac11ed05b317e25110d7e37561b837
Symptom:
All AppWidgets on Home screen disppear after appwidgets.xml updated
with invalid value.
Root cause:
The issue occurs when size information of an AppWidget is set to 0
via AppWidgetHostView#updateAppWidgetSize() API.
Since width and height are taken positive padding, so they become
negative number and are sent to
AppWidgetServiceImpl#updateAppWidgetOptions().
In updateAppWidgetOptions(), convert values by
Integer.toHexString() to save widget parameters to appwidgets.xml,
but negative numbers become illegal values for Integer.parseInt().
After device is rebooted, widgets cannot be reloaded because parsing
appwidgets.xml fail by NumberFormatException at Integer.parseInt().
Solution:
When writing the widget's info to appwidgets.xml, check the size
parameters and replace with 0 if they're negative value.
Bug: 65705916
Change-Id: I48f69fbf081201a176ea1093094ba6cdb120e5f5
AppWidgetService.onUserUnlocked can block ActivityManager thread
for 500+ ms. The code is guarded by mLock, so it's safe to simply
offload it to the worker thread without additional synchronization.
Test: Setup widgets/rebooted the device and unlocked
Test: Create/switch to guest user + setup widgets
Bug: 63389529
Change-Id: Ib3bc76f79bdbc707c0ac270d7fc35c8b27af9af0
Both BackupManager and AppWidgetManager internals are taking a long
time to process user unlock events, so add tracing details. Also add
general tracing to show all UserState changes.
Bug: 32859180
Test: builds, boots
Change-Id: I82f4f7220ccb695941acd6bc45cd67a5fae8a4d2
Remember that we might not be able to resolve historical
widget provider references, so don't access them unchecked.
Test: manual
Change-Id: I01c6c68461b6d15aa8fee402a4bfb0f21bf1ddbb
Added defensive checks to prevent sporadic crashes due to various race
conditions when user is stopped:
* onPackageBroadcastReceived - moved the check inside the synchronized block.
This guarantees that onUserStopped (that also grabs mLock) is not yet
called and we can proceed.
* stopListening - Since it is invoked before onUserStopped callback, we can call
ensureGroupStateLoadedLocked(userId, false). The state will be subsequently cleaned
up in the onUserStopped.
Test: manual user switching + SecondaryUserContentResolverTest and
ManagedUserContentResolverTest
Fixes: 37472670
Fixes: 36890589
Change-Id: I44d0a0c004e9c3e6cfb37a24cb8a5b6f20a42f13
This allows more fine-grained control than getting all installed
providers for a user, when you might only want to check for a particular
package. For instance, Launcher can use this API to surface widgets per
app without having to ask for all the widgets.
Test: Unit test on AppWidgetServiceImplTest
$ runtest --path=services/tests/servicestests/src/com/android/server/appwidget/AppWidgetServiceImplTest.java
Bug: 34940468
Change-Id: I182bf1c012d31182024422fc4a63f57f151c3ee5
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
Also defining an extra constant for widget preview which can be used by
developers to provide a snapshot of the widget with the pin request
Bug: 35811129
Test: All exisiting tests passing
for f in 1 2 3 4 5 6 7 8 9 10; do \
adb shell am instrument -e class com.android.server.pm.ShortcutManagerTest$f \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner; \
done;
adb shell am instrument -e class com.android.server.appwidget.AppWidgetServiceImplTest \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Id854bd28468a5bf0416ff1a1b19c44d850016f32
It's probably looking to detect both STATE_RUNNING_UNLOCKING and
STATE_RUNNING_UNLOCKED, so it should use isUserUnlockingOrUnlocked()
instead of trying to peek at the low-level CE key status.
Test: builds, boots
Bug: 29534661
Change-Id: I6aca1721f88ced65abf3bb7cbab550c4dbe27fb7
Launchers can choose to implement support pin shortcut or pin appwidget
or both by specifying different actions in the intent filter
Test: Automated tests and CTS
Bug: 34174006
Change-Id: I4456dbb943cfba11d465556f0732f0ed629ab3ba
