Network Factories are allowed to go below, but networks need to be
constrained. Allowing the network to go below 0 meant that -1 could
sometimes leak through and foul the logic.
The core of 17361330 will be fixed when we stop sending scores for
listens to NetworkFactories, but it exposed this issue too. Summary:
1 - add a network listener. This isn't a request so it's not sent
to networks.
2 - alter your score (ethernet sets score to -1 when the link goes
down) (16:07:39.782)
3 - a bug in ConnectivityService causes score changes to get sent for
all network requests and network listeners causing NetworkFactories
to no see 2 entities. This bug will be fixed by a pending change
(https://googleplex-android-review.googlesource.com/#/c/540840/).
This causes the ethernet NetworkFactory to see two entities, both
served by networks of score -1. (16:07:39.989)
4 - disconnect Ethernet - this only sends 0 scores for known
requests, not network listeners. Had it been sent for both entities
they both would have evaluated that the networkfactory score (-1)
was lower than the request score (0) and both released their
refcount. (16:08:03.147)
5 - this means the listener is tracked by the EthernetNetworkFactory
with a score of -1 while the factory itself has a score of -1 so the
network release isn't called.
bug:17361330
Change-Id: Ife34ca0f9c233dd3c3df80f6fea580af43afcdeb
This is a groundwork for subsequent CLs that are
supposed to improve default input method selection
logics.
Historically we have had a @hide constructor of
InputMethodSubtype. However, this contructor is
a bit obsolete because we can not specify some
parameters that were added in recent platform
releases. We should use InputMethodSubtypeBuilder
instead.
BUG: 17347871
Change-Id: I72ad79682a58344e14380eb20e26edf98aee37cd
"Empty" could imply that the constructor body itself is empty, which
is not a requirement. All that matters is that the constructor is
public and takes no arguments.
Change-Id: Id1cda8835baee9f9ad89aba8b3d33b963e61e718
Bug 16984007
Animated Vector Drawables were using the viewport dimensions for
calculating the allowable animation error. Instead of using viewport
dimensions, it is better to use the intrinsic dimensions. Using
the viewport dimensions meant that a small viewport (e.g. 1x1)
would mean that animation paths within would only have an accuracy
of 50% of the dimensions of the drawable.
Change-Id: Id0152eabb4effd1e50c644eea7a371b38baeb7c1
It wasn't properly lazy-initializing the service binder, so it always
thought the backend service didn't exist, and so always returned false.
Also directly validated that every usage of sService in the module is
now correctly lazy-initialized.
Bug 16661321
Change-Id: If5fbb18aef81bfa8fd70eb40a1f6af54cc96d804
Bug 17440475
transitionAlpha must be set when using Transition.forceVisibility,
but shouldn't be set when views initially come into the scene.
Change-Id: Icc61c83c701508d09dadb074c86094171dcce78a
While we're in there also call listeners when they're added
so they know the state immediately.
Bug: 17258031
Change-Id: I5f1186314795f3fafd78e1b3e2d5102cdaec65d6
When META-INF/MANIFEST.MF is missing, treat as NO_CERTIFICATES
instead of CERTIFICATE_ENCODING. Also remove redundant layer of
debugging details when wrapping exceptions.
Bug: 15667982
Change-Id: I6e8216d5bf6e42da1feb70c89f991001380305be
ActionMenuViews work in two modes: hosting another Menu instance or
creating their own. The former is used when an action bar is
displaying a window's options menu. The latter is used when an
ActionMenuView (or Toolbar) is placed within an arbitrary layout and
the getMenu method is called.
When showing a window's options menu, ActionMenuPresenter calls into
the ActionBarPolicy to determine if we should reserve an overflow
button or if overflow will be presented by the window instead. Always
reserve overflow if the ActionMenuView is presenting its own menu.
Bug 17381966
Change-Id: I17c495986994d421bf6276ae39ba233243432e97
Simulates the relevant portions of a DOWN/UP event pair to request focus
and bring up the IME.
BUG: 8213791
Change-Id: Idb32d81552ecbbdefc64686c914eba6d8e28b0b8
Since implementation is still largely synchronous, this is safe.
For the future full-asynchronous implementation, this is the behavior
we want in any case.
Bug: 17345630
Change-Id: Ib54a3441b21fa8cb42bcc6548e5639d9db7ec193
Otherwise, cannot reliably match up capture progressed and failure callbacks
with the start callback.
Bug: 17421092
Change-Id: I91d92be70a15536b215bac330370ce37e426ec26
This can be controlled by MDMs via DPM.
Also fixes:
- javadoc for restrictions
- persisting of cross profile copy/paste restriction
Bug: 17387303
Change-Id: Ie148f56189181d2a4c6345c0823d417ab13a94a3
There was a race where ActivityManager would return null
for getCurrentUser() when switching between guest accounts.
This is because the Guest account was marked for deletion
while it was still active.
Bug:17290209
Change-Id: I224fb4b6836380e5acb7dbeb8f3343d74505f88a
(Noticed the difference in a javadoc diff between Notification and
NotificationCompat)
Bug: 17424399
Change-Id: I639a46c429ffebf8ca47118b2ea80f40ccdc1286
