See build/soong/README.md for more information.
Test: m checkbuild
Change-Id: I417409281c928ea667d937090d2a0d9d72a449a2
Merged-In: I417409281c928ea667d937090d2a0d9d72a449a2
Exempt-From-Owner-Approval: trivial conversion
(cherry-picked from commit e0b2ee52d2)
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
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
> Moving the size check to a comman place so that it is executed in
all related code
> Fixing size calculation when views are merged as a result of partial
update
Test: Manually tested with a dummy app
Bug: 31790171
Change-Id: Id0ea776796f156455d2cba31c8392d4875116949
(cherry picked from commit 349b412b4b)
> Moving the size check to a comman place so that it is executed in
all related code
> Fixing size calculation when views are merged as a result of partial
update
Test: Manually tested with a dummy app
Bug: 31790171
Change-Id: Id0ea776796f156455d2cba31c8392d4875116949
A recent patch started returning "null" when a Binder service
required to provide a manager wasn't yet registered.
This fixes four locations where that new logging was triggered: in
two cases by adjusting the fetching ordering, and in two other cases
by only fetching when the device supports the manager.
Bug: 28634953
Change-Id: I84dbccffa4ac760c10a2bbcb234f21272bfecb91
The MSG_NOTIFY_UPDATE_APP_WIDGET message is sent asynchronously,
meaning it tries sending RemoteViews without the lock held, possibly
while another Binder thread is trying to mutate it.
Fix this by creating a copy for the thread to safely dispatch.
Bug: 29889779
Change-Id: I341fbbf89abee97a66cd67f1dd2a728282b68bfa
If DISALLOW_MODIFY_ACCOUNTS has been set by a profile/device owner,
or account management is disabled:
When an app tries to add an account, show the policy transparency screen.
BUG:26762383
Change-Id: I721220c37c74493020f5a1be1f15731e9863a1de
We now have isUserRunning && isUserKeyUnlockedisUserUnlocked instead of
having isUserUnlockingOrUnlocked. The difference is
we now allow stopping unlocked user to access the API.
Testing:
Write a simple widget which keep calling AppWidgetManager API in a loop.
1. In non-FBE mode, place the widget to launcher.
Turn off work mode. No crash is observed.
2. Repeat 1 in FBE mode with separated work challenge.
3. Repeat 1 in FBE mode with no separated work challenge
4. Repeat 2 and reboot the device. Unlock work profile, widget is shown
5. Repeat 3, reboot device, widget is shown after rebot
Change-Id: I2fa9f602dcb0befff41fc6b145e9855e82d8d7a8
Fix: 29264823
- Instead of waiting for the broadcast to start loading the user’s
widgets, handle them in the service callbacks to ensure the app widget
update broadcasts are enqueued earlier.
Bug: 27262341
Change-Id: I095abe5e15fe46412d00438986f7a9aee50872ca
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
Do not enforce unlocked state when running on the background thread. User can
be in the stopping state or removed by the time the message is being processed.
Bug: 28471878
Change-Id: I1862849661d93b424a07ea94e80563bea7a94ce5
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
Previously many usages of UserManager.getProfiles and getEnabledProfiles
were only using ids of returned users. Given that the list of users needs
to be parceled and unparceled for Binder calls, returning array of ids
minimizes memory usage and serialization time.
A new method getProfileIds was introduced which returns an array of userIds.
Existing method calls were updated where appropriate.
Bug: 27705805
Change-Id: Ic5d5decd77567ba0f749e48837a2c6fa10e812c0
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
* renamed getPackageSuspended => isPackageSuspended
* does not return false for an error, instead throws
NameNotFoundException if the package could not be
found, or if there is an unknown RemoteException,
wraps it in a RuntimeException and rethrows.
Bug: 27532430
Bug: 22776761
Change-Id: Iee00600089b1c0556a3312b10456826464fa8f9f
