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
When the user overflung to go to the quicksettings panel the
scroll logic remained active and was not reset.
Change-Id: Iab733f3525d5465c5dc583559d0acbc350274171
Bug: 15425820
This just prevents the crash, it's still unclear how bad pointers
are getting into the map in the first place
Change-Id: I3acffaae09548ec48973035b7fcf5f35606bad60
The dirFlags and bidiFlags enums are distinct, and have different
meanings. The former is a determined direction for a run of text, while
the latter is a request for the bidi algorithm. They have been used
interchangeably, and this has caused some problems, notably running the
bidi algorithm needlessly when the direction for a run is already
determined.
This patch cleans up the confusion, by always naming each occurrence
explicitly "boolean isRtl" or "int bidiFlags" (the previous code often
just used "int flags", which added to the confusion), and converts
between the meanings when a function takes an isRtl argument but passes
it to another function expecting bidiFlags.
Fixes b/15089607 Clean up bidi flag mess
Change-Id: I410b6604376e853dd12c255e7f5a9d2b9a310dd9
