If both title and condensed title is null,
item.getTitleCondensed() could be return null value
in onMenuItemSelected. therefore need to check
whether retun value is null or not.
Change-Id: Ib08f52b949a794aa7bd6cc25414041e820f62969
Activity.setImmersive(boolean) / android:immersive="bool" are now public.
In addition, if the foreground activity is immersive then an update lock
will be held on its behalf. This lets applications such as movie players
suppress the display of intrusive notifications, OTA-availability dialogs,
and the like while they are displaying content that ought not to be
rudely interrupted.
The update lock aspect of this mode is *advisory*, not binding -- the
update mechanism is not actually constrained; it simply uses this information
in deciding whether/when to prompt the user. It's more a guideline than
a rule.
Bug 7681380
Change-Id: I3c412a84cbf3933e3bf0168f2c71c54a86e4b7e5
EventLog function can handle string,integer class and long class. (in android_util_EventLog.cpp)
If menu title string are used bold tag(like <b>test</b>), it'll be android.text.SpannedString.
In onOptionMenuSelected, it is using item.getTitleCondensed() function for writing event log.
therefore any android activity using tag menu string(like <b></b>) can be crashed by IllegalArgumentException.
I found this crash on GMS Application.
change locale chinese -> launch Google+ -> hangout -> menu key -> Invite(expressed chinese) click -> Google+ crash
Change-Id: I0437be81699925e29bf4510eb615ef2424432763
The first intent is the key. No wait, last! Or was it first?
I haven't actually read the code, didn't write it, and haven't tested
its behaviour, but surely it can't be both, and last is the only one
that makes sense.
Change-Id: Ie8435981f09be618c93680fb6056afd015090161
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
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
