Current implementation parses the provider info from all manifests in
every app the first time getInstalledProvidersForProfile is called,
which causes unnecessary delay on the call-site if only a single package
was requested.
This CL ensures widgets loading are deferred further down the line,
until it is absolutely needed to be parsed.
Bug: 202356231
Test: manual
Change-Id: I793bd818781ae956cd5bc590a315c669d01e7ca6
It's possible a previous snapshot change altered the nullability
of these values, but the String[] for both resourcesDirs and
overlayPaths are expected to be nullable anyways, so just null
check them before cloning.
Bug: 216722631
Test: atest com.android.cts.webkit.WebViewHostSideMultipleProfileTest#testSecondProfile
Change-Id: I56aaf6d5aec1ec14bc7986fe58e1cc77cf6b8376
Marking final allows the gated debug code (generally logging) to be
stripped from production builds. This saves ~20KB from system server.
Follow-up work will explore presubmit guards for similar DEBUG cases
(including guarding against DEBUG = true).
Bug: 203143243
Test: m
Change-Id: Ic87a8d8bf183ac0b36c790a2f4a4661ae5e1a87f
Add null checks to applyResourceOverlaysToWidgetsLocked to protect
against a widget provider component info being null.
Fixes: 196231621
Fixes: 196331791
Test: none
Change-Id: Ia762694523404ac508eb49600306048037f13658
When Runtime Resource Overlays (RROs) are applied to an application,
the ApplicationInfo of the app in package manager is updated to have
overlay paths. Widgets create the context used to inflate their
remote views using a snapshot of the ApplicationInfo of the widget
provider. This snapshot is taken when the widget RemoteView is
initially created and sent to system server.
This change updates the snapshot of the widget provider ApplicationInfo
with the new overlay paths and notifies apps hosting widgets to
re-inflate their remote views in order to have RROs apply to widgets
correctly.
Bug: 193866093
Test: Repeatedly change wallpaper & style color to a "basic" color
and go back to launcher to observe overlay correct color is
applied
Change-Id: I0b9b8c0d32d83a52e9ea5bc8ba1635cf99e4b921
As part of widget restore, we need to notify participants (hosts &
providers) of the mapping between ancestral and new widget ids.
Prior to this change, this was done at the end of system restore
and after each restore-at-install of unbundled apps.
There were two issues with this:
1) We would try to notify not-yet-installed participants at the end of
system restore and then *not* try again when they were installed.
2) We relied on PACKAGE_ADDED broadcasts to know which participants were
installed, but these are delivered asynchronously and not guaranteed
to be processed before the restoreFinished call.
After this change, we:
1) Only notify participants that are actually installed
2) Use receipt of the PACKAGE_ADDED / CHANGED broadcast to trigger
notification of any restore participants that are added or changed
*after* system restore completes.
2 is safe because by the time PackageManager sends the package
added / changed broadcasts, the app data restore has been completed,
and the app has been killed if needed.
Bug: 162057170
Test: Manual restore of Keep widget via cloud and d2d
Change-Id: I51dec33d09b62faba6d7c7daacd718a3c0682f7d
The call to queryIntentReceivers only contains receivers that are
enabled. It does not return disabled receivers, whether disabled by
default and unmodified or disabled at runtime.
Therefore, the isEnabled check only has the effect of filtering out enabled widgets that were initially disabled in the manifest.
I have verified this locally with all 8 permutations of manifest-runtime
component enabled states.
Fix: 189087746
Test: locally, AppWidgetServiceImplTest
Change-Id: Ibc35005f8af31622134edb174469b39895b88ecc
When the work profile (WP) is off, the layout of the widget is provided
by the system.
The layout must have a background with android:id/background as view id
and clip its outline, or it will be considered "legacy" and have the
wrong outline when moved.
Bug: 187907544
Test: Add a widget for the WP and turn the WP off.
Change-Id: Ibee31f5f0e510313ae7f8dc78c208c45a4d0e1fd
This seems to interfere with cross profile remote views otherwise. This
will also avoid changing the stored RemoteViews, or not providing an ID
if the RemoteViews is constructed by the host.
Fix: 187837525
Fix: 187867661
Test: atest ManagedProfileCrossProfileTest#testCrossProfileWidgets
Test: Manually with other apps, checking the colors do no flickr
Test: Check that uninstalling an app with a widget doesn't crash anymore
Change-Id: I7caa3f58d9b554e36f54e6b9d3b793c3ae5023ef
This ensures that adapters have their caches filles and other benefits
such as lists maintaining their scroll positions
Bug: 183503469
Test: validated with local app that service is not called on drag for
colors changing and that flicker is removed
Change-Id: I043d1d7a547b012f7a12eb555b35854a9bb7109b
Package visibility should be applied to #getInstalledProviders as
what we did for similar APIs in PackageManager.
Bug: 180104057
Test: atest AppEnumerationTests
Change-Id: I50f471e6f71613e36cc1b137456a3ee0b23f6a38
Config chages are required to load the correct label. But
the label had been deprecated few years ago and hosts are
expected to load the label themselves
This avoids another reload just after unlock since the local
list is not prepared initially
Bug: 180867488
Test: Presubmit and CTS already passing
Change-Id: Iff4543bb62d06c81713b47b76330b2147a10386c
Removing creating and holding icon bitmaps in systemServer and
directly loading resources in the Host process
Bug: 178616010
Test: Verified View on device
Change-Id: I4abf616985d68ac48f55856bb90fa598a4cebe1c
JobScheduler calls isBoundWidgetPackage(), but this can be extremely
slow while AppWidgetService is doing any meaningful work, causing
problems for the rest of the system. Remove that serialization by
moving mWidgetPackages behind its own lock.
Test: atest CtsAppWidgetTestCases
Bug: 161866124
Change-Id: Idae7d16d375dfd41f802ad193fa1ec939093c67a
Previous changes have applied mechanical refactorings, but this change
hand-migrates the remaining logic which was too complex to identify.
This change should have no behavior change; famous last words.
Bug: 171832118
Test: manual
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: I85cd830eb6bfde18fca6e73ee7adfdc385a890de
This is a purely mechanical CL that applies the output of the
recently added refaster templates to help guide towards more
efficient TypedXml methods. There is no behavior change.
Bug: 171832118
Test: manual
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: Ic95dd3de77c60482ad36b31706e6b701929f40b3
Related changes are introducing new TypedXmlSerializer and
TypedXmlPullParser interfaces which offer efficient access to
primitive attributes.
Bug: 171832118
Test: manual
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: Ibd93f353ff3cb1f0b7073ebbeae17fe5194b046b
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
We've been writing many new framework-specific Error Prone checkers
to help detect obscure platform bugs, and this change starts enabling
those checkers for more packages across the platform.
Bug: 155703208
Test: manual
Exempt-From-Owner-Approval: trivial blueprint changes
Change-Id: I1db3412b0be40f6f78c68331ae01756887192071
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
Over the years we've had several obscure bugs related to how SDK level
comparisons are performed, specifically during the window of time
where we've started distributing the "frankenbuild" to developers.
Consider the case where a framework developer shipping release "R"
wants to only grant a specific behavior to modern apps; they could
write this in two different ways:
1. if (targetSdkVersion > Build.VERSION_CODES.Q) {
2. if (targetSdkVersion >= Build.VERSION_CODES.R) {
The safer of these two options is (2), which will ensure that
developers only get the behavior when *both* the app and the
platform concur on the specific SDK level having shipped.
Consider the breakage that would happen with option (1) if we
started shipping APKs that are based on the final R SDK, but are
then installed on earlier preview releases which still consider R
to be CUR_DEVELOPMENT; they'd risk crashing due to behaviors that
were never part of the official R SDK.
Bug: 64412239
Test: ./build/soong/soong_ui.bash --make-mode services RUN_ERROR_PRONE=true
Exempt-From-Owner-Approval: trivial blueprint changes
Change-Id: Ia20181f8602451ac9a719ea488d148e160708592
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
