| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
During restore first the provider records and then the applications
are restored. Therefore, we keep the restored provider records in a
zombie state and once we get the package install broadcasts from the
package manager we update the zombie providers to be real ones. The
bug was that while doing this we were not updating the provider id
from one with an undefined UID to the one with the UID under which
its package now runs.
bug:17869323
Change-Id: I20b7cbfd2f90e2f5bf3a6b858d8da99cc1c82841
|
|
|
|
|
|
|
|
|
|
| |
PackageManager and AppWidgetHostServiceImpl should
be loading the resources of any shared libraries being
used by the app, as they have references in their Widgets
or application icons/labels, etc.
Bug:17668152
Change-Id: I359662334edb125d7570089916727df4eeba02bb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When restoring app widget state from XML we read all providers,
hosts, and widgets and only after reading all hosts and providers
for all members of the group we hookup the widgets as they may
cross profile boundary. To esntablish the host-widget and provider-
widget relation we use a tag for the host and the provider that
are assigned before saving the state to XML. When restoring we
are using the tags to match widgets with hosts and providers. The
bug was that we were not clearing the tag of all hosts and providers
before reading from XML as we want the only tags that are defined
to be the ones we are reading. This resulted in wrong app widget
restore for a secondary user.
bug:17505027
Change-Id: I035d8f13142c6b9dbc9d658b82390f9cd8d75e0d
|
|\
| |
| |
| | |
DUMP" into lmp-dev
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use enforceCallingOrSelfPermission() for throwing a security exception
rather than creating the security exception ourselves. This has the
advantage that the exception is in a well known format expected by
the CTS test android.security.cts.ServicePermissionsTest#testDumpProtected
Bug: 17165920
Change-Id: I7d3c2d2a0852a490fe1d553cd81d1efc79d2fec3
|
|/
|
|
|
|
| |
bug:17387880
Change-Id: Ic637ce8fa2da87d6f21a222bd70bf627953f57e3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
App widgets can be partially updated where only the actions delta
is delivered to the client. There was a regression where instead
of sending the delta, the merged remote views were sent. This was
problematic because certain actions are ignored when merging to
avoid clutter (specifically showNext and showPrevious), hence these
actions never reached the client.
bug:16844814
Change-Id: I88ab58e610cda24154985165e6d6d93a1baa9c79
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Notify the hosts in the group if a package gets white-listed or
un-white-listed for providing widgets across profiles.
2. Notify hosts in the group for provider changes when a profile
is deleted.
bug:17126070
Change-Id: Ic719c1c68e45842d50decc95603f1d61583b8f02
|
|
|
|
|
|
| |
bug:14991269
Change-Id: I5996f8c69a3d151ff1ecd8f19403dd606f588150
|
|
|
|
|
|
|
|
|
|
|
|
| |
An app can access widgets hosted or provided by its uid and package.
Access is also allowed if the caller has the bind app widgets permission
but this caller can be in the wrong user. Now the caller should not
only have the bind app widget permission but also be in the same user
as the host or the provider of the widget.
bug:16834230
Change-Id: I5ddb6309f63f2b4ba95360446c2b9584350fb66f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
-> Enforce that the passed intent's component belongs to the same package as the
passed AppWidget id.
issue 15287902
Change-Id: Ic85c38d399fe1cbb6f7efa844ae0f5367a1906ed
|
|
|
|
| |
Change-Id: I5166f88f11f781914312e867cb653c8ecbefa705
|
|
|
|
| |
Change-Id: I6a8123d8e69367fc1ce27bac46c4bcec489d73ba
|
|
|
|
|
|
| |
Bug 13651057
Change-Id: Id7e5ba521ac3f201b1a44f122358ca5af2929e06
|
|
|
|
|
|
|
|
|
| |
A host can have an 'instance' the other end of which is still
unlinked to a concrete provider. Don't crash when we hit those.
Bug 13651057
Change-Id: I5a29afb0e6a7ab30976862aee04bd33f609543fa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| |
| |
| |
| | |
Context." into klp-modular-dev
* commit '25df673b849de374cf1de40250dfd8a48b7ac28b':
Make SystemService constructor take a Context.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
|
|\ \
| |/
| |
| |
| |
| |
| | |
services" into klp-modular-dev
* commit 'a5a93f559d337ad5b79716b05ea43707eb779dc8':
Check feature bits before loading optional services
|
| |
| |
| |
| |
| |
| |
| |
| | |
At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
|
|\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
services/print/java/com/android/server/print/PrintManagerService.java
Change-Id: I1b9bf364ca50ee3c48f53d87ae0ce23e7f3c2bc2
|
| |
| |
| |
| |
| |
| |
| |
| | |
These services can now be excluded by modifying the list of REQUIRED_SERVICES (TB renamed)
Changed appwidget, devicepolicy, backup and print services.
Change-Id: Id8e2855d5c045cd57bdb02dca9ed75172803bce7
|
|/
|
|
|
| |
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|