Package IDs greater than 0x7f are interpreted as negative
numbers in Java's signed integer. The proper check for existence of
a resource ID is that it is not 0.
Bug: 37498913
Test: none
Change-Id: I446fb6abb514bf7cf2d0dcbfbd81dd5718cd2cb4
- throw NullPointerException if the package name is null; there’s
already a method with the specified null behavior.
- Return value of this method should be @NonNull - return an empty
list. Document this.
Test: Unit test on AppWidgetServiceImplTest
$ runtest --path=services/tests/servicestests/src/com/android/server/appwidget/AppWidgetServiceImplTest.java
Bug: 37544056
Change-Id: I047a8e7c4e519ef7c5deddaca0d1ad931dc91343
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 will be used to help document the expected behavior of various
broadcast actions defined by the OS.
Also add logic to PackageParser that will then yell at developers
whose manifests are making bad assumptions about which broadcasts
they'll receive.
Test: builds, boots
Bug: 35925551
Change-Id: I059c2bf8aa3ce53d9ff18dcc263db7620cd14bd6
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
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
Test: Manual and unit tests
adb shell am instrument -e class android.widget.AppWidgetHostViewTest -w com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 22839968
Change-Id: Id9cb56619653f43b9f755c881f5d0936375f9c87
Test: Manual test and all the unit tests:
adb shell am instrument -e class com.android.server.pm.ShortcutManagerTest1 -w com.android.frameworks.servicestests
... to test9
adb shell am instrument -e class com.android.server.appwidget.AppWidgetServiceImplTest -w com.android.frameworks.servicestests
Bug 32404406
Change-Id: Icd6d4cbd25d9cdf4508da725d95d6401cc3a46a7
> When loadingView is no available, the FirstView is always
loaded on the background thread
> AppWidgetHostView only inflates on the background thread, if
the view has any costly operations
Test: TBD
Change-Id: I701caee7e4e6ba5972d0cf478cb57f8ec950da54
Update the content description to mention the
widget is suspended.
Mark the remote views as not significant for
accessibility.
Bug: 28909714
Change-Id: I8804d41e520e2b4af7ade0fa8820ee7b2488bde5
When the widget starts lisnening again, it receives all the pending updates
until that point (restricted to the requested widgetIds). When startListening
is called for the first time, the widgetIds is empty and it does not get
any updated. Further calls to startlisting will give the missed updates
for the bound widgets
Bug: 23892701
Change-Id: I3aa06d3e33a0861c19cfd5ced567d5bb3b93d906
This undoes the automerger skip which occured in
commit e740c84dc3 and
replays it as a standard (NOT -s ours) merge.
Change-Id: If5a47be26f73d6a0735c425cd66310a3e2a89086
Also associating a lastUpdateTime with every widget. This allows
the host to query the widgets which were updated only after
the last stopListening call.
Change-Id: If9375cf2d8caa0ccca14b6649821d87ada1f3a84
Similar to first patch, but now using new "rethrowFromSystemServer()"
method which internally translates DeadObjectException into
DeadSystemException. New logic over in Log.printlns() now
suppresses the DeadSystemException stack traces, since they're
misleading and just added pressure to the precious log buffer space.
Add some extra RuntimeInit checks to suppress logging-about-logging
when the system server is dead.
Bug: 27364859
Change-Id: I05316b3e8e42416b30a56a76c09cd3113a018123
When enabled, the View inflation as well as some of the drawable
loading is done on the background thread.
It also assumes that all the views support inflation on the
background thread, which is true for the default views
supported by the platform
For ViewGroup opetations, it maintains a virtual view tree which
is used for findViewById. The final operations are applied on
the UI thread in the end.
Change-Id: Ib3ce55182ec04a344f2b2513981ee03afc8fa2e8
b/19904873
> Reason: to prevent TransactionTooLargeException from occuring when
binder transaction size goes over the limit.
Change-Id: I054cb161d235234f3ccdaadd70314163e690b0db
Track package names of bound app widgets and use the list when
querying for idle apps.
Bug: 20066058
Change-Id: If8039397a061ef04bb13aa38d57cd7f0221f5fc7
Ensures that delegate code is run last. Previously, calling the super
method from an accessibility delegate set on a widget would only run
code in the widget's parent. Next, the delegate code would run. Finally,
the widget's code would run. As a result, the widget code would override
any data supplied by the delegate.
By moving all overridden code to internal methods, we ensure that the
call chain for super includes the widget's parent code followed by the
widget's code. The delegate code will always run last.
BUG: 17641433
Change-Id: Ib9d403156c1fc4fb04f65f3c126d1277a44b3740
We are checking whether an app can access an app widget
based on the calling uid and the package name. The package
is mostly to make sure that hosts in different apps do
not accidentally interfere whereas the security is enforced
by the uid.
When remote views adapter binds and unbinds to a remote
views serivce it was passing the package of the context we
create to load resources for the widget instead the package
of the host. Now it is passing the host package and also
we are checking if the caller of bind remove serivce API
is in uid that has the host package - this makes it
consistent with elsewhere.
bug:17226052
Change-Id: I2b0b6669e3dc027037b7481c2871cedabd642433
The default application icon generally has a different aspect ratio that a
preview image, and cannot transparently be used in place of the image.
Returning null will allow the apps to handle the case as they see fit.
Change-Id: Ie6e8e16dd7b4e58b222187a81c62d27eccab45a9
1. Added API for badging an arbitrary drawable at a given location.
2. Updated the icon and previewImage deprecation as they are no longer
returning a badged drawable. The methods to load the icon and the
preview are now just making it easier for a developer to get the
drawables.
3. Fixed a bug in AppWidgetServiceImpl leading to a crash when a user
is removed.
4. Fixed a bug in AppWidgetHost which was unnecessarily caching its
package name and having code paths where the cached value was not
populated when calling into the system.
bug:14991269
Change-Id: I50d011a6597d88814715d5ec04ee67815e8ce0bd
The goal of this change is to enable support for appwidget from
user profiles to the user main profile. A user profile is a user
which is associated as a child of the main user profile. For example,
a user may have a personal (parent) and corporate (child) profile.
The device policy should be able to control whether adding a widget
from a child profile and given packages is allowed. This change
assumes that all packages from managed profiles are white listed.
Another change will add the device policy changes.
Change-Id: I267260b55d74c48b112a29979a9f59eef7a8194e
- Fix broken Javadoc @see directives
- Linkify AppWidgetProvider in the documentation for the new
ACTION_APPWIDGET_RESTORED broadcast
- Minor content edits
Bug 15022842
Change-Id: Ia7d4ad5be476c260492e1be5d83e21f6943a6847
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
