When a device A creates a conference call containing device B and C, both
B and C can receive IMS signaling to indicate that they are in a conference
call. This occurs on most domestic carriers; the Telephony framework
uses the "multiparty" indicator on the IMS call to switch the call to a
conference call.
We made some changes to how conference calls are logged in Q which improves
the accuracy of the call durations. We used to log calls as they're merged
into a conference. In the case of a participant in a remotely hosted
conference call, we'd log the call as soon as they are remotely added
to the conference. This is unfortunate as the call durations are grossly
under-reported.
The conference call logging changes now assume we'll log the conference
event package children in the conference instead of the participants which
merge into the conference itself. On domestic carriers, since the
call on B (or C) becomes a conference, we would then no longer log the
call.
This is FURTHER complicated because on some carriers, B and C will ALSO
receive a conference event package from the network showing all the
participants in the conference. So if B hangs up on the conference, they
will have entries in their call log for A and C, which is really strange
because a call to C was never originated on their device.
In Telecom we need to ensure we do not log remotely hosted conference
participants, and we need to ensure that we DO log a remotely hosted
conference as if its just a single party call.
To accomplish this we need:
1. the address and name display information associated with the call from
A-B / A-C prior to the call turning into a remotely hosted conference.
We need this to log to the call log
2. the remotely hosted conference and participants need to be marked in a
manner that Telecom can identify them.
Test: Manual test.
Test: Add unit test to cover this logging scenario.
Bug: 132325382
Change-Id: I65e713f68d1695a48d96dacbf7faa4476cd8d815
So that we can implement different behavior between Android P and Q.
Test: Upgraded P->Q and booted fresh install of Q. Checked DB after boot
Bug: 131427665
Change-Id: I89f9dc1fc11129c95c03834e21628c6be75f2875
This will control when the Assistant handles show or hide.
Change mode using the following command:
$ adb shell am broadcast \
-a "com.google.systemui.SET_ASSIST_HANDLE_BEHAVIOR" \
--es behavior "${BEHAVIOR}"
BEHAVIOR can be one of: OFF, LIKE_HOME, or REMINDER_EXP
Change the minimum time between handle appearance in REMINDER_EXP using
the following command:
$ adb shell setprop ASSIST_HANDLES_SHOWN_FREQUENCY_THRESHOLD_MS \
${DESIRED_MILLISECONDS}
Change the duration the handles appear in REMINDER_EXP using the
following command:
$ adb shell setprop ASSIST_HANDLES_SHOW_AND_GO_DURATION_MS \
${DESIRED_MILLISECONDS}
BUG:132983599
BUG:131115187
Test: atest AssistHandleBehaviorControllerTest
Test: Tested locally.
Change-Id: I44bb59367159226b67a2aeb49aae2a5b34584d70
StatsService to update UID data and overflows kernel transfer buffer.
In this case, the IPC call silently fails. The issue was discovered in Android Automotive Embedded use case that employs multiuser setup. This causes more uid data being sent via one-way StatsCompanionService::informAllUidData call than usual and can trigger the issue. As the result, uid map on statsd side is empty and many metrics are not captured.
Bug: b/132444397
Fixes: b/132444397
Test: Did a clean build of master branch and flashed the device. adb
shell cmd stats print-uid-map returned without any result. Repeated the
steps after implementing the fix, print-uid-map returns the results now.
Change-Id: I1451c13b36696449c145c51618c68d10e29a596a
A while back the call for ExpandableNotificationRow#resetTranslation()
went missing when reworking the blocking helper. Bring it back
Fixes: 131908593
Test: visual
Change-Id: I3a96c165e892bfee71398972d2e1dd289d09168b
On some devices with huge `rounded_corner_content_padding`, the icon of
heads-up notifications will be clipped or even completely removed from
view. This is caused by `HeadsUpStatusBarView` trying to align the
heads-up icon with where the icon would be on a normal notification
card, which would end up outside of the status bar contents view when
`rounded_corner_content_padding` is set to beyond a certain value.
This patch fixes the problem by allowing heads-up content to overflow
the normal status bar content region when it is shown. As long as the
rounded corner is not too huge, the aligning position of the icon should
not be a problem of its own.
Fixes: 131813566
Test: atest SystemUiTests
Change-Id: I0fb8856c301a438ca87b06fcdbcf5323d9cda18c
The native services should specify their permissions in platform.xml if
they need internet permission, otherwise the eBPF program will block the
socket creation request. Fixing the known services that are in group
AID_INET but didn't specify their permission in the xml file.
Bug: 132217906
Test: CtsJdwpTestCases dumpsys netd trafficcontroller
Change-Id: I84cde7d3757953bc0bf761727d64a715bcdd68bb
Merged-In: I84cde7d3757953bc0bf761727d64a715bcdd68bb
(cherry picked from commit e5d6f0fa6c)
- For users running when the PermissionPolicyService is initialized we
are not running onStartUser. Hence we have force to do this in
onBootPhase
- Only write the runtime-permission fingerprint after all permission
upgrade steps are done
- This also means that if a user was not started in the first boot
after an OTA we do not upgrade the fingerprint until the user was
eventually started
Fixes: 132737426
Test: - Started a fresh build
- Rebooted
- Simulated an OTA
- Added a second user
- Simulated an OTA with a second user, rebooted and only then
started the second user
Change-Id: I0758e8bdfefc16139bde2444f126adc3b0a17526
Fix bug where the first time that bubble stack expands
-mPointerView.getWidth() returns 0 while mPointerView is being created
-setPointerPosition adjusts pointer position by 0
-pointer points to right of center
Also
-replace mPointerView.getHeight() with mPointerHeight
-remove unused getExpandedSize()
Bug: 131849856
Test: manual
Change-Id: I433cf7755152e49c2f8a2fd3df0b70c6dd079b57
Because we were looking at the theoretical and not the actual
showing public state, notifications could get updated to
invisible without ever recovering.
The actual showingPublic state now determins the visibility.
Fixes: 117272628
Test: add low priority child while group is on lockscreen and invisible
Change-Id: Iacdd984451a2e3d69a0aaa8186b6afab5447188e
