It was done in a weird way by "forgetting" the layoutId. It's now done
explicitly, which should make it more robust in the future.
Fix: 205265677
Test: Manually
Change-Id: Ie8b88a2b17e8f680f14fa19a485cd91853d90142
When implementing the code, it seems this was forgotten :( If the view
id of the root of the RemoteViews is changed, currently, the top-level
view will be re-used, which is an error.
Bug: 181985606
Test: atest android.widget.cts.RemoteViewsRecyclingTest
Change-Id: I5a8addb08f597ec574e3ed49d1318771e4c7c767
The check has to be done in RemoteViews and in AppWidgetHostView right
before creating the context used to inflate the app widget. Further, the
APK is cached potentially in two places: in the APK with code and the
APK without codes, so both places are updated if present.
Test: manual, see bug for details
Fix: 202369942
Change-Id: I5718f67711a3332a942d3c037eef7f30379549a4
This was mistakenly removed in Android S (in ag/13732454) and could
cause issues if the top-level layout parameters are defined using
resources defined in the AppWidget's package.
Also add some safeguard to avoid crashing if the AppWidgetProviderInfo
doesn't contain a ProviderInfo (which can happen if it's not created by
the system).
Fix: 201744899
Test: Existing CTS tests
Change-Id: Ibb4f2c26a6258ec2c68a7fd1fafe3e5fe3551109
All the dimensions are in pixel, not dp. The conversion from complex
value to pixel is done in AppWidgetProviderInfo#updateDimensions.
Fix: 199524613
Test: N/A
Change-Id: Ifdc90e7338ade8494d90e567fc95500b650c4ebb
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
This reverts commit cb5a80ea57.
Reason for revert: Was not the cause of the test failure
Fixes: 186622527
Test: atest FrameworksCoreTests:ContextTest
Change-Id: I705854f080200f0465d94a7754e710f05a3ec92c
AppWidgetManager#bindAppWidgetIdIfAllowed sends a broadcast when
successful, but this is currently not documented. The behavior was
introduced in 2014 by a change in the AppWidgetServiceImpl.
Bug: 189334092
Test: N/A (documentation only)
Change-Id: Iba83b89fd60c7f658a1fe911a260b666638fb020
If an application caches an ApplicationInfo and uses it to call
Context#createApplicationContext, the app will not get the most recent
version of the overlays for that application. To make things worse, the
LoadedApk stored in ActivityThread#mResourcePackages is updated using
the old ApplicationInfo causing further uses of the cached LoadedApk to
return outdated information.
Deprecate Context#createApplicationContext, convert all internal uses
to Context#createPackageContext(String packageName, ...) and log
whenever any one calls Context#createApplicationContext with an
outdated ApplicationInfo to detect debug issues in using old infos.
Bug: 188059515
Test: change wallpaper and observe widgets get reloaded with most
recent overlays
Change-Id: I2aeefa8c0e66264859109975a54c4f73f76ad710
Relies on the ordering in SparseIntArray, as it's documented as ordered.
Bug: 187852819
Test: Manual
Change-Id: I3942a7f3826c173d99544ac0b4f81266b4ca3cc1
If new colors are set but do not change, do not re-inflate the App
Widget.
Bug: 187852819
Test: Added logs and added a widget, moved it to see
Change-Id: I672ee7984cab8966f79d839494ac8a7b91679102
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
This will allow Quickstep launchers, e.g. NexusLauncher, to
provide a custom interaction handler.
Bug: 169042867
Test: manual testing
Change-Id: Id70cb463e2671e32ea9f52f06487ac63fcf57e0d
UX landed on a format where we have 2 neutral palettes, and 3 accent
palettes. It's the ideal format to play with elevation and hue rotation,
in order to have a more vibrant and less muddy UI.
Fixes: 181986389
Bug: 173553055
Test: atest SystemPalette
Test: atest ThemeOverlayControllerTest
Test: atest ThemeOverlayApplierTest
Test: atest DeviceDefaultThemeTest
Change-Id: I80d3f7d1cc92e97efcb40fe6dc9f09918321d273
Views shouldn't be recycled if the view id is changed as the identity
of the view is then altered.
Second pass: this has been further tested by adding/removing AppWidgets
on a test phone.
Bug: 181985606
Test: atest CtsWidgetTestCases:RemoteViewsTest
Test: atest CtsWidgetTestCases:RemoteViewsRecyclingTest
Test: atest CtsInputMethodTestCases:android.view.inputmethod.cts.InputConnectionBlockingMethodTest
Change-Id: I8924c02f7f0223458f556a07a3dfdc96b4ce612e
This reverts commit 308a272289.
Bug: 183104573
Test: Install from Play Store with the screen off on wembley, and the device doesn't crash when the screen turns back on.
Change-Id: I289fcafc6685c4ede295e8d6916a54da9bac1ad5
Views shouldn't be recycled if the view id is changed as the identity
of the view is then altered.
Bug: 181985606
Test: atest CtsWidgetTestCases:RemoteViewsTest
Test: atest CtsWidgetTestCases:RemoteViewsRecyclingTest
Change-Id: I68415087297312eb2c1985d272be2ac535507c2a
The mViewMode variable is only used if there is no RemoteViews object.
But we still want to update the colors in that case.
Bug: 179783721
Test: atest CtsWidgetTestCases:android.widget.cts.RemoteViewsThemeColorsTest
Change-Id: I078d21422a6300e7aaecb0baa2a49b9e14cae9e9
This follow recommendations from the API council review.
Based on those recommendations: I updated the API and updated the
comments to make the function behavior clearer.
Bug: 181611658
Test: atest android.widget.cts.RemoteViewsSizeMapTest
Test: Local widget to check rendering
Change-Id: Ie9fcedbc7b18b83f6d1220f99240f264e53e3649
The flag value should be 4 and not 3 so that we can use bitwise
operations to determine the existence of a flag.
For example, we want to use the following to determine if a widget is
reconfigurable:
(providerInfo.widgetFeatures & WIDGET_FEATURE_RECONFIGURABLE) != 0
But if the value of WIDGET_FEATURE_CONFIGURATION_OPTIONAL is 3, the
above check would fail.
Test: atest FrameworksServicesTests:AppWidgetServiceImplTest, atest
CtsAppWidgetTestCases
Bug: 177977976
Change-Id: I15d4baae5e17acb9a0b936485a53f9b3359d65ca
Update the framework to:
1 - Allow creating RemoteViews with a mapping from size to layouts
2 - Use the closes sized layout in any given situation
3 - Allow the launher to specify the current size when inflating a
remote views
Bug: 179025145
Test: atest android.widget.cts.RemoteViewsSizeMapTest
Change-Id: Icf98d01bd0cf8b48c47555a1af6acb498b46b1a4
This is needed to replace usage of the adb shell
command 'appwidget grantbind' in some cts tests with
TestAPIs.
Bug: 180328483
Test: N/A
Change-Id: Ie74149c2045e19261c77da2ffa757a803cc61d95
and getting resources for a particular config
This would allow fetching display infos for the activity in a particular
config independent of system config.
Bug: 156154533
Test: Included CTS
Change-Id: Ie245d685fb21444c10a88b4ca86dc7ff08e2b599
Merged-In: Ie245d685fb21444c10a88b4ca86dc7ff08e2b599
