This CL passes a port ID when enabling/disabling ARC in case
there are multiple HDMI ports that support the feature.
Bug: 18781204
Change-Id: I632518132bf07c8ae6f0ff5135429ca719b596b2
The man bent over his hourglass,
A programmer of sorts. The day was green.
They said, "You have a blue hourglass,
You do not fire alarms when they're asked."
The man replied, "Alarms as they're asked
are changed within the blue hourglass."
And they said then, "But fire, you must
Alarms beyond us, yet themselves,
Alarms within the blue hourglass
That trigger exactly when they're asked."
---
Fix the delivery-fuzzing semantics that had been introduced in
81f9882b5aadd6a2289c9f521a06a7af5f35ebf0. That patch turned out
to be incomplete; in particular, alarms scheduled later might require
the validity of an already-scheduled kernel alarm even if they did
not affect the head alarm batch directly, and this was not being
addressed. For now, roll back the fuzzed delivery logic entirely.
(This is not a full revert because that patch also caused exact alarms
to be considered standalone for batching purposes, and we need to
preserve that new policy.)
Bug 18726690
Bug 18765436
This is a 'git revert' of 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0
*except* that this CL preserves the "exact alarms are treated as
standalone" portion of the original patch.
(Cherrypick of 5c3e277fb42bd799287936c5aee0d30fbcc7e65c from its
original branch.)
Change-Id: Ib9c3200f7e6bc6fa0c9928ee9db4cfd87f039353
Add plumbing to alert Telecom every time a character is processed after
the post dial wait state (the processing happens in Telephony).
Bug: 18644688
Change-Id: I487d76aa9c959ca528c6377374aa35c2d0b4a803
The man bent over his hourglass,
A programmer of sorts. The day was green.
They said, "You have a blue hourglass,
You do not fire alarms when they're asked."
The man replied, "Alarms as they're asked
are changed within the blue hourglass."
And they said then, "But fire, you must
Alarms beyond us, yet themselves,
Alarms within the blue hourglass
That trigger exactly when they're asked."
---
Fix the delivery-fuzzing semantics that had been introduced in
81f9882b5aadd6a2289c9f521a06a7af5f35ebf0. That patch turned out
to be incomplete; in particular, alarms scheduled later might require
the validity of an already-scheduled kernel alarm even if they did
not affect the head alarm batch directly, and this was not being
addressed. For now, roll back the fuzzed delivery logic entirely.
(This is not a full revert because that patch also caused exact alarms
to be considered standalone for batching purposes, and we need to
preserve that new policy.)
Bug 18726690
Bug 18765436
This is a 'git revert' of 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0
*except* that this CL preserves the "exact alarms are treated as
standalone" portion of the original patch.
Change-Id: I54c763775877de5b6eeb5617544aa6100bb17526
Adding an intent for OMA-DM use case where
the network sends a string error indicating
the device is not provisioned to make calls.
The string the network is expected to send
is added to ImsReasonInfo.
Bug: 18242739
Change-Id: If7f654f834f543523af40b422ea9659c5f0b4de4
The normalizeNumber method in PhoneNumberUtils preserves a leading "+"
but only if it's the first character in the string. Thus it gets
dropped if there is leading punctuation such as "(". This patch
preserves the leading "+" as long as it would be the first character
in the normalized phone number.
Bug: 18418335
Change-Id: Ifcb1d3dd6c2943c729f570e7f3c90d1da9ee8b4b
