1. Realize that mDestination can never be null and update the
code accordingly.
2. Simplify isDefaultRoute.
3. Provide two new hidden utility methods, isIPv4Default() and
isIPv6Default(), that can be used by LinkProperties to
to determine if the system has connectivity.
4. Update tests.
Bug: 9180552
Change-Id: I85028d50556c888261d250925962bdedfe08e0c6
If we forward intents when looking up launcher icons, we end up
having an icon for a disambig activity instead of the apps for that user.
Bug: 15769854
Change-Id: Ia57525466dba57b6669b2b5cedf98f202d08f586
Bug 15585623
Bug 15607591
Exit transitions now run because exit transitions are executed
with startActivity.
Change-Id: Ie55793a9514c64d96e2cf1abdd2d39c4d2606a23
Previously, if an app inflated a layout in a Fragment's onCreateView
that itself had fragments included, those fragments would be added to
the Activity-level FragmentManager and would not share the same
lifecycle with the fragment it was inflated for. This led to some
nasty management headaches.
If an app targets L or above, add the fragment to the child
FragmentManager of the current fragment when inflated using the
LayoutInflater passed to the parent fragment.
Bug 12763389
Change-Id: Iad4ed7d5df602aea9579bf1503e206fa894630c1
* Introduce 'fake' metadata for 3A+flash (hardcoded to support nothing)
(will be removed in a later release)
* Open the camera1 device in its own thread, so that the looper it
captures is also our own (and not the main looper)
* Set the picture size based on the size of the JPEG surface outputs
Change-Id: Iaeb5031c6b352115b73d2261a39d65347d75fdc8
Since managed profiles are started on bootup, the managed profile
would be allowed to set an app (possibly itself) as a lock task
app and then run itself on bootup and constantly control the
device. This privelege should be restricted to device owners.
Change-Id: I4a93aabd6054cbe75076ef0517fce03ffa74dc93
Bug: 15838537
* Fix kSync_UIRedrawRequired constant value (woops)
* Tell CanvasContext that WebView is now rt-safe
Change-Id: Idf15cf21115c2ca24b8ccd00025e8502864cd87c
Apps calling the View methods that accept TypedArray params have
always been wrong. There is no way to call these methods safely since
apps can't get at the correct filter array assumed in these methods'
implementations. Do the best we can with these calls anyway; ignore
whatever they did pass and just get the styled attributes from the
Context used to construct the view and its associated theme.
Bug 15792674
Change-Id: I6dfa1abf273b581e79a17a72f68c97ff9a9148c5
