It's not correct to state requestCode is 'currently not used'. It can be
used to differentiate multiple PendingIntents since a number of Android
versions now. Also, the introduction block of the PendingIntent
documentation explicitly states this as a possible use:
"If you truly need multiple distinct PendingIntent objects active at the same
time [...], then you will need to ensure there is something that is different
about them to associate them with different PendingIntents. This may be
any of the Intent attributes considered by Intent.filterEquals, or
different request code integers supplied [...]"
So fix the documentation inconsistency to make the possible use
immediately clear.
Change-Id: Ia65d7a5ab12c2c3ee1aa1c5107e5ea8fd937b765
Fix a bug in unstable ContentProvider.
IllegalStateException: ref counts can't go to zero here: stable=0 unstable=0
IllegalStateException: unstable count < 0: -1
There is a race between main thread and background database thread. Main thread
is responsible for handling the REMOVE_PROVIDER message. Database thread starts
insert or query request again and again. acquireProvider in db thread will often
snatch provider from the jaws of death, sometime it fails to remove REMOVE_PROVIDER
which is already fired out from MessageQueue. But completeRemoveProvider in main
thread gets suspended when trying to execute the critical section. If db thread
released the provider before main thread resumes the execution, then two
REMOVE_PROVIDER messages will be executed.
Change-Id: I8588aa1d1a8bc444dcd2adf6f8bc3f055cebbdc4
Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>
# By Roman Mazur
# Via Gerrit Code Review (1) and Roman Mazur (1)
* commit '0d47af1131c4d4f9f29dad790d919d8599e3a3cc':
Clear loaders array after they are destroyed.
# Via Android Git Automerger (2) and others
* commit '53d49f1702df41a4ca342a1df6e720b16e094797':
Touch action bar title text: you will go to space today!
Title/subtitle text in an action bar is now a full alias for home/up.
Add some prototype ActionBar functionality around titles for future
API consideration.
Bug 7966136
Change-Id: I14377121dcb976d0a5f1e1862f35c3d267eb5458
In case of SET_ACTIVITY_CONTROLLER_TRANSACTION, there is no reply transaction.
So makes same to other transactions.
Change-Id: I3b9527682662a12f78cc96b6084904f18178fee7
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
See change Ia577caecbacb226a3ce525a01a66283efb6ba754 for details.
Change-Id: I9f07eeceaa3829f71008e6f6a38ab849095bd69c
Signed-off-by: Roman Mazur <mazur.roman@gmail.com>
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
