The system process has no ApplicationContext and consequently was
returning null. Use the base Context in these cases.
Bug 7673699 fixed.
Change-Id: Ie2ab856bb0baefff44775a12bef7802320f72656
If you install a lockscreen widget app on a secondary user, lockscreen fails to find it.
There were several places where the correct context and userId were required under the
covers - AppWidgetHost, AppWidgetHostView and RemoteViewsAdapter.
Set the user id in the required places and use it to query the package information.
Bug: 7662835
Change-Id: Ife482c8ab2a2e601650b7cfe2660e88d3b8f2050
Bug: 7660973
RemoteViewsAdapter will now store the userId as part of the cache key
when caching remote views to optimize for orientation changes.
Change-Id: I7c4e52b3995d4f56ebfa35aa9516327e182ad892
This was initially about the Clock widget crashing repeatedly on some
devices with multiple users. Turned out that there were race conditions
when switching users that could result in remote views of one user calling
back to the RemoteViewsAdapter in keyguard that in turn sent an incorrect widget id
to a different user's widget, resulting in a crash.
Since KeyguardHostView is instantiated in the same process for different users,
it needs to carry a user identity to pass along to AppWidgetService so that
remote views services were bound to the correct user and callbacks were attached and
detached properly.
Added some aidl calls that take the userId to do the binding properly. A more
complete fix might be needed in the future so that all calls from Keyguard carry
the user id.
Also, there was a problem in comparing host uid for secondary users, since Settings
for a secondary user has a different uid than keyguard. Not an issue on single-user
systems. Changed the host.uid comparison to accomodate for the secondary user.
Bug: 7450247
Change-Id: Idbc36e3c60023cac74174f6cb7f2b2130dd3052c
- fix onMeasure() in RTL mode: need to compute width before computing layout params
that are used for layout
- fix getRelatedView() so that it uses the resolved rules
- add some extra "final" statements
Change-Id: I7c3bf841cd18c5f77b010a9be20fa78069e88d94
- as we remove the 9 patch padding trick, we need also to do the correct
positioning of the radio / checkbox / star during draw
Change-Id: I02b67bef9c0f2dc1c0c65361de14ab20ce9b881d
Before to implement a pool of objects, the pooled class had to implement an
interface which was leaking the pool management APIs. This requires
hiding APIs - inconvenient at best. Further, each client had to
implement the chaining of pooled instances which means adding a couple
of member variables which are manipulated by the implemented interface
methods. As a consequence the client is aware of how pooling is
implemented which is error prone and breaks encapsulation. Now the
pool objects are responsible for managing pooling state via reusable
wrapper objects and the clients are oblivious of how pooling is done.
Creating a thin cached wrapper for each pooled object has minimal
performance impact while making the code more maintainable. Actually
implementing of the old version of the APIs was taking as much code
as implementing the pooling yourself.
Also clients had to implement a poolable manager whose responsibility
was to create new instances and provide callbacks when an instance
is added to or removed from the pool. Now, the clinet class should
create a static member for the pool and expose obtain/aquire and
release/recycle methods in which it should create a new instance if
the pool did not return one and clear the state of the host when
it is returned to the pool. Updated the JavaDoc with a best practice.
The pooling was composed of several interfaces and classes scattered
over a few files, now all this is in a single small file.
Update all usages of the pooling APIs in the framework.
Also one had to write a poolable
manager which
Change-Id: Ib8dc286040eb3d7cb7d9668ba76fead05cb97647
* commit '0b64976f19a3f03f80dfcd80b8894299d4dc71d7':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit '0ee790408e19a2a820a080a8b4ad3af63d3a5eca':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit '1586168302f79d10e85a5aeed7b486c4244cc98e':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit 'e9812bae0e0ce08bd232dc2371fdb959e4f7a318':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
This reverted change was adjusting the min and max values for the NumberPicker
which is not desirable since it changes behavior and it will be possible for
an app that works on the current platform to crash on an older one. Also the
adjustment was not implemented correctly.
Updated the documentation to clarify the reltionship between the min value,
max value, and the displayed values array.
Bug:7518172
This reverts commit a1410e6789
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
