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
- remove unnecessary calls to resetRtlProperties().
- now reset of RTL properties will only be done when adding a View
(and no more when removing it)
Change-Id: I0d42128c9f7df6085fb92bb5af5c9bd4d1ba88a3
getChar(String) and getChar(String, char) had wrong description in their
javadoc.
Also most of the get methods with default value were missing the corresponding
@param tag for the default value parameter.
Change-Id: I0f38b3caacf9cabd70e0c1ada36af3662f5566d0
AudioService relies on a valid mmc in order to enforce the headset
volume limitation or not. There is a timeout to enforce the limitation
if no mcc is configured after boot.
Until this timeout is reached or a valid SIM is detected the headset
volume is not limited.
This change makes that the last known volume limitation state (enforced or
not) is persisted so that next time we boot, last known state is applied until
a new mcc is configured if any. In most cases, the mcc does not change from one
boot to the next and we do the right thing. If teh mcc does change, the correct
policy will be enforced when the mcc is detected or after the timeout.
Also fix a bug where the volume panel was not displayed if the limitation mechanism
is triggered at the first press on VOL+ key.
Bug 7455275.
Change-Id: Id0f2996d893d38c6a14f4f9e4a0e9e3be17ef127
This does some cleanup of the initial boot, especially when
booting in "no core apps" mode for encryption/decryption.
Change-Id: Ifb3949f580e52f54559e603c4b0b104f6bac2f6c
- 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
MediaRouter's policy so far has been around a single selected route,
but when route types are entirely orthogonal this should not be the
case. However we still don't want to get into a situation where we
have multiple, very different routes selected for different types at
the same time, we still want to have more of an element of
predictability.
Behavior of getSelectedRoute is now:
* If the selected route matches at least one type with the requested
type flags, it is still considered selected for that request.
* If the caller specifically requested the selected user route and the
currently selected route is not a user route, return null.
* If the requested type flags do not match any types with the selected
route, return the default system route.
Note that this is "any" behavior instead of "all" - this matches
existing usage of the method. We may consider adding an "all" variant
later on.
Bug 7588042
Change-Id: I3a79d8153ca6b882fd3ef6b9b1de8f538873dec2
Also fix a little problem where the USER_STARTED broadcasts
were not being sent as ordered broadcasts(!).
Change-Id: I3aa3e0a9b3900967cdd2d115ee103371b0a50c41
FindBugs description:
There is an apparent recursive loop at IntProperty.java
in method set(Object, Integer)
This method unconditionally invokes itself. This would seem
to indicate an infinite recursive loop that will result in a stack overflow.
Note: Checked into AOSP. Cherry-picking for mr1.1.
Issue #7621806 IntProperty has infinite recursion bug
Change-Id: I2f52dd3689198cb948925aa65dd9c95be7888fe7
In alarm manager, print a summary of the top 10 alarms by time
being executed. Keep track of execution time (and wake count) of
each type of alarm for each application so this can be printed in
the summary (and used to compute the top 10 alarms). Rework how
the alarm summary stats are tracked so that we don't need to hold
on to the full Intent for each stat and can get the Intent information
at the time the alarm is sent rather than waiting for whatever Intent
comes back in the result.
Also in the battery stats: sort the kernel wake locks by time, add
a new section showing all partial wake locks across all applications
sorted by time.
Finally a new LocalLog class that is used by AlarmManager to log
important warning messages, so these can also be later found in
its dumpsys output.
Change-Id: Icc07810053e60fb623a49937e696819cb8352b06
Navigating over text backwards by character does not allow the cursor to get
at the beginning of the text and it stops one position before the start. Now
the cursor can get to index zero which is before the first character.
bug:7307336
Change-Id: I109b579835cc080907b20b01e0cf07811e962c6c
ACQUIRE_CAUSES_WAKEUP is supposed to be ignored if combined with
PARTIAL_WAKE_LOCK. Instead it was being carried out for any values
of the WakeLock level.
This change reverts behavior to closely match
previous releases of the framework by only honoring
ACQUIRE_CAUSES_WAKEUP for screen wake lock levels. The only
difference being that in previous releases ACQUIRE_ could have been
combined with PROXIMITY_SCREEN_OFF_WAKE_LOCK (it never was) and
now such a combination will ignore the ACQUIRE_ flag.
Bug 7532258 fixed.
Change-Id: I46e848d8fd1b57e54c63141bf3d4f353986b5bdf
* 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 a1410e6789ce72bc423793315a51aea8b6bad6c7
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
