When injecting classes in LayoutLib (eg. CreateInfo), so that LayoutLib
can refer back to the changes, also inject the anonymous inner classes.
Without this, the injected classes are not loadable. Although, LayoutLib
itself doesn't load these classes, but some tests do.
Change-Id: Ib5f6b779ef4d79dec8d614d3dbb26eeac88a1064
* commit '782def772adacaf029d7d9850605923066665424':
Add config_forceVoiceInteractionServicePackage to allow a device to config its VoiceInteractionService package and ignore the regular setting.
The fake window that was added when View.SYSTEM_UI_FULL_SCREEN was
set consumed all touches, even those going to the SystemUI and not
just those of windows below. The input consumer is now correctly
positioned in the window order to only capture the right touches.
Clicks to the volume panel and the heads up now correctly go to the
right place instead of just unhiding the SystemUI bars.
Bug: 21089476
Change-Id: Ib53dfc0b33b70084ca607d0f044db30b6e6c91d6
* commit '80cf2210226bc652181abafe606b69ebce63af78':
Add config_forceVoiceInteractionServicePackage to allow a device to config its VoiceInteractionService package and ignore the regular setting.
For security reason, disallow HTTP include files if the source asset is
a HTTPS site or an Android app.
Change the include statement field name from "delegate" to "include".
Bug: 20323096
Change-Id: Ifc12b61657c9c89a670b9d7c3220853321c15dea
We have APIs for a DO/PO to fix a permission in a granted or
denied state in which the user cannot manage this permission
through the UI. However, there is no way to go back to the
default state in which the user gets to choose the permission
grant state.
Change-Id: I2562a1d8b1385cd740b44812844ef14c895c2902
FUSE daemons now rely on getting per-user GID information when
packages.list is written. Normal secondary user adding/removing
usually has enough PackageManager traffic to trigger a side-effect
rewrite, but this change writes explicitly to handle guest users.
Also obtain the user list once, and exclude dying users. During
user creation we manually splice in the user ID that we're bringing
online.
Bug: 19924661
Change-Id: Icc5b1b169300c9dc12099be12651acbf89d6bea9
When trying to find the SDK Platform Dir for LayoutLib tests, also
test if the dir from which the tests are run is module dir.
Change-Id: Id5c6038d07ebbb122e38f907ad488ed1f2bcde32
We were exceeding the maximum allowed recents document tasks entry
for an application package because the full Intent object was been
compared for equality which will be different for each task. Now
we are only comparing that the task components match which is
sufficient to determining that the task belongs to the same
application package.
Bug: 18642190
Change-Id: I831b0fcffb876d51e9439e7a7a4c75bb0881db7c
Couple of overlapping issues that this CL fixes. The major change is to
offset the selection vertically this is similar to how the handles work
already (i.e. touch target is below what's being selected), and still
allows the user to see the selection start / end without covering it with
their finger.
This change fixes multiple issues:
1) Previously to ensure the finger wasn't covering the selection a
preceding or following offset was taken, this made it difficult to
select certain words and it made text on the edge of the screen hard
to select (b/21098345 and b/19965619)
2) The use of preceding and following on the word iterator was not correct
allowing grapheme clusters to be split, now the offset is calculated
with getWordStart/End which respect grapheme clusters (b/21045116)
Bug: 21098345
Bug: 21045116
Bug: 19965619
Change-Id: Id8392426cce20ad0ff47a4279c92f6ed1b0ad30e
First, when parceling a notification with no small icon:
Well, you shouldn't attempt to do this anyway, since NoMan
will reject a notification without a valid smallIcon. But
setServiceForeground parcels up the Notification on its own
before handing it off to NoMan, so it will crash on an
invalid small icon. (In general, parceling code should never
ever crash, even if the object is in an undesirable state.)
And when build()ing a notification: Same thing---don't build
a notification with no icon; you're going to have a bad
time. But maybe you're going to fix it before you hand it
off to NoMan. Or maybe it's just one page of a wearable
notification, so it doesn't really need its own icon. Either
way, Notification shouldn't crash.
Bug: 21286186
Bug: 21298403
Change-Id: Ie482cde0a3afe3aaabf07be0536551b8e4bceba0
Allows us to proceed without crashing the system process. Also,
complete an incomplete error message. Follow up comments from
change b904863476991d8540d37d5.
bug: 21144503
Change-Id: Idb6a33f93b70b4e5e2bca95d2d3af0e2adaeedf3
