The 2nd attempt (ag/20294157) was reverted due to b/259732944. To avoid
the bug, we explicitly define the "high" quality encoder as a 4k
encoder. Note (1) below explains the reasons.
8k encoder specs:
Codec: h264
bitRate: 80000000 (80M); source: b/241178681#comment3
Size: 7680x4320 (8K UHD)
Frame rate: 30fps
Notes:
(1) Regarding b/259732944 (the bug caused by the 2nd attempt):
If CamcorderProfile.QUALITY_HIGH isn't explicitly specified, the highest
resolution available will be used.
Therefore, when the 8k profile was added, apps requesting QUALITY_HIGH
would ask HAL to perform 8k recording.
This created the following issues:
(a) As 8k support in HAL isn't ready, existing tests using QUALITY_HIGH
will fail (such as CTS, PTS, FATP, etc.).
(b) 3rd-party apps currently using QUALITY_HIGH will get 8k, which might
not be their intention.
So we chose to keep QUALITY_HIGH at 4k, which was the highest resolution
on P22 devices.
Detailed discussions are in b/259599407.
----------------
(2) Regarding the "quality" attribute in EncoderProfile:
It must match what's defined in MediaProfiles::sCamcorderQualityNameMap
(see frameworks/av/media/libmedia/MediaProfiles.cpp).
----------------
(3) Regarding the camera IDs:
The camera IDs in media_profiles_{device_name}.xml correspond to the
IDs inside vector ModelSpecificDataControllerBase::visible_camera_ids_.
The vector is populated in
lyric/silo/hardware/devices/{device_name}/data/model_specific_data_controller.cc
According to the documentation of "visible_camera_ids_", "the first ID
for each facing will be used as the default camera ID". As
visible_camera_ids_[0] is always the first (default) ID for the rear
camera, and only the rear camera supports 8k, we add 8k encoder
profiles for camera 0 in media_profiles.
The explanation above isn't obvious. You'll need to read
model_specific_data_controller.cc to understand it.
----------------
(4) Regarding tests:
We can't test the 8k encoder since we haven't brought up the 8k support
in ISP.
We can use CTS, PTS, and EECoexer to test this CL for existing use cases.
Note that RecordingTest#testBasicRecording currently fails at TOT due to
a different reason. For this CL, we only need to make sure no 8k stream
is requested by observing logs with the "GCH_HalUtils" tag.
Bug: 232811715
Bug: 262423942
Test: build & boot Android
Test: atest RecordingTest#testBasicRecording
Test: adb shell /data/sysval/scripts/eecoexer/eecoex.sh -s CAM,22,0,5,true,HIGH
Test: manually testing GCA video recording
Change-Id: Ie6c054e641810da9c231f3839961cbe8fcc16fdc
Bug: 259450323
Test: Build and boot on device. Checked video recording
and YT playback. Checked for thermal runaway with burn8
and gpubw workloads
Change-Id: If2e40383b31bf1ea64602484ff9c650a3ba0d1f8
Signed-off-by: Sayanna Chandula <sayanna@google.com>
- Full tuning includes volume curve to match previous project at
volume 18 to 1 perceived loudness.
- Passes all power and skin thermal targets
(for 40C skin temp sustained power)
- Test acoustics shows superior performance to past premium (R4, C10)
Bug: 262473484
Test: manual test
Change-Id: Icc1dee1782d9919195aa161bc5b99708c489fc66
Signed-off-by: Jasmine Cha <chajasmine@google.com>
Before PMU feature is ready, directly limit the CPU frequencies
via powerhint. Also update the value of CPU frequencies based on
the latest HW.
Bug: 261760700
Test: Boot & take traces
Change-Id: Ibc41c9decd866a37ec65201204f5a1b09798b72e
the file node was removed so also remove these
dummy setting
Bug: 260806701
Change-Id: I23044f7f32cf4b2b2cc93205ec5751525f05ee7f
Signed-off-by: Chungkai Mei <chungkai@google.com>
cdev limit at CRITICAL severity and hard throttling at
EMERGENCY severity
Bug: 262304756
Test: Build and boot on device
Change-Id: Ic79ef7a38a8b64b25285d53581ce1613844a26c1
Signed-off-by: Sayanna Chandula <sayanna@google.com>
Zuma's PMU porting is not completed so disable PMU for now.
Bug: 259144954
Test: GCA video recording
Change-Id: I96b16b486342d95df28813b63fe7d95a9d9e2aeb
PixelWifiOverlay2023 was originally added in device-XXX.mk file, and lead to overlay parsing failure on aosp/factory build.
Referring to other existing Pixel projects, move PixelWifiOverlay2023 to product.mk files.
Bug: 260594276
Test: Overlay can be read correctly.
Change-Id: I739504ee9ded6f232e438ce5830ca168ed1f4675
Disable wireless charging during drain, usb charging,
and charger stress test
- vendor.disable.wlc 1
If device is placed onto dreamliner and shutdwon(drain out),
it would boot up by DC_CHG and keep shutdown(0%)-boot up
(by DC_CHG) continuously. To avoid this symptom, limit wireless
current_max as 75000 after device boot up
- persist.vendor.limit.wlc.current=1
How to verify:
adb shell setprop vendor.disable.wlc 1
adb shell cat /sys/class/power_supply/wireless/online >>>> 0
adb shell setprop persist.vendor.limit.wlc.current 1
adb shell cat /sys/class/power_supply/dc/current_max >>>> 75000
Bug: 261948834
Test: set the property manually and query the result from file node.
Change-Id: I5bcf9baeb2818b439520167b518b2e5c5224d7e2
Signed-off-by: Ken Tsou <kentsou@google.com>
(synced from commit 4c821c04fc25b026f5fc8e9301758bf87dbb4a3e)
Per b/259732944#comment2, using CamcorderProfile.QUALITY_HIGH will
request an 8k stream if 8k is present in media_profiles. This is because
QUALITY_HIGH is the "quality level corresponding to the highest
available resolution".
(https://developer.android.com/reference/android/media/CamcorderProfile#QUALITY_HIGH)
However, the 8k support in camera HAL isn't ready, so we have to remove
8k from media_profiles to avoid breaking apps using QUALITY_HIGH.
Bug: 232811715
Bug: 259732944
Test: build
Test: boot & check GCA video recording
Change-Id: I52a2b6c577acfff1d871cc038916d1490abd0fd6
Change list:
- 1st proto PICL model 2.8V/3A for both top and bottom spks
Bug: 243497194
Test: builds
Change-Id: I260ebfe55ffc67530d4348d2d76d5fb627880d1c
Signed-off-by: Robert Lee <lerobert@google.com>
