Device polling requires both pick policy and pick iteration policy,
however, device discovery action has no iteration policy.
Along with fix, move send result and pick policy constants
to HdmiConstants package
Change-Id: Ibbcfdc482a189bbc3aa2c61143422541da78447d
Bug 15470128
Bug 15470558
Wait for shared element destinations to be complete
before sending it to the calling activity.
Don't allow layout between setting final destination
and the transition values capture.
Use snapshots to hold the final position while waiting
for the called Activity to take the shared element.
Fixed problem with exiting views sometimes disappearing
when exiting.
Change-Id: Ibc655f7bb9e8dd6e8a15778c96931e3d845cc15c
Bug: 15683945
invokeFunctor() does not require isEnabled() to be true
to execute. Specifically it does not care if HardwareRenderer
has a Surface or not, as it will fall back to a pbuffer surface
if available. If there is no context at all, it will invoke
with kModeProcessNoContext.
Change-Id: Ie6abe566b92c8fa33bb7a673fc3b9fa9ce913446
Since HdmiCecKeycode defines all keys used for Hdmi CEC,
simple HdmiCecKeycode sounds better than HdmiCecKeycodeTranslater.
Change-Id: I1a0ea9f128b19dd47bfda3bf2dd8794a9e42c6f8
Here is a list of changes on this. (R: rationale)
1. HdmiCecLocalDeviceTv takes over responsibilty of device info
management.
R: All devices infos are added or removed by only Tv's
device discovery and hot plug detection mecanism
2. Each HdmiCecLocalDevice manages FeatureAction and Cec
message cache.
R: There is no direct connection between actions that
are created in different device action. If there is
an same actions created from different local device,
they should be managed independently.
3. Active path and logical address is managed by
HdmiCecLocalDevice.
R: All device should know active path of current source.
4. All system audio & ARC features are handled by
HdmiCecLocalDeviceTv
R: In terms of ARC, theoretically, any device can be transmiter of
ARC but TV is the de facto device
On other hands, for system audio Tv is the recipeint
of request.
Change-Id: Iac9ff43fb41798ed4f94c61d23345fe5fe777fbb
We intentionally drop interim updates when the panel is not
visible, but we should catch up when it becomes visible again.
Not a problem for the dialog panel, since it is torn down / recreated
each time.
Bug:15573750
Change-Id: I717b5d459acb25f9610222e9913d7b8eb71cdd00
This will allow us to use this logic on other link types such as
Ethernet, and will also avoid increasing the complexity of
WifiStateMachine as we get more information such as routes and
DNS servers from netlink.
Bug: 9180552
Change-Id: I79034827cb0c5f24d783d7243e04b69e12aa3cc6
This will allow us to dynamically track routes being added and
removed, similar to what we do for IP addresses.
1. Support removing routes. Since this is a new function, we
don't need to jump through hoops to support callers passing
in routes that have no interface, we just fail to match them.
2. Make the addRoute method return a boolean value indicating
whether anything changed. This is consistent with what we do
for addresses and is used to decide whether to update the
rest of the system when an update comes in.
Bug: 9180552
Change-Id: I50648b5f81ec55c88501a7640e119cda2bb540f2
1. Allow IpPrefixes to be created from strings. In order to do
this, factor out the code from LinkAddress which already does
this to a small utility class in NetworkUtils.
2. Truncate prefixes on creation, fixing a TODO.
3. Add a toString method.
4. Write a unit test.
While I'm at it, make RouteInfoTest pass again, and convert it
to use IpPrefix instead of LinkAddress.
Change-Id: I5f68f8af8f4aedb25afaee00e05369f01e82a70b
This was causing the wrong rcc to be shown. Simple fix
just fixes the ordering so it's not reversed.
Change-Id: I56f2d9d6895d6ba3b0eca8f77a3b0b63e0193ad1
