* this forces android to display "charging rapidly" whenever our
proprietary 33w charger is connected, based on the value of
this node (0/1)
Change-Id: I2a36ccb62621672e480e4b25a335410044fbb372
Signed-off-by: donjohanliebert <donjohanliebert@gmail.com>
In the before-times of June 2019, an intrepid AOSP reviewer named
"fbechet45@gmail.com" reported:
> typo error:
> line 311 : "volatage" should be written "voltage"
After a short series of hops, this bug landed in my todo list.
My first thought was, "Easy! I'll fix this on my internal git,
Lets go, in-and-out, 20 minute adventure." But, that would deny the
original reporter of seeing the solution for some large number of
months.
So, I decide "I will fix this in AOSP. But, oh no, Coral has the
same copy-paste error! Let me just wait until October 2019 when
Coral goes public, then I'll fix those two at the same time."
(Little did I know this would continue to get copied and pasted, and
now there are 20+ instances of this on our internal repository.)
Fast forward to 2020: The pandemic gripped our nation, and I was
busy baking bread and posting pictures of it on Facebook. I have
some great recipes I can share. Let me know if you need some of my
artisinal sourdough starter.
Now, in 2021, after multiple automated-and-human reminders, this
has become my #1 priority issue to solve. I still have the "can't
fix all the errors" on AOSP problem, but if I don't fix crosshatch
now, it will be too late to land it into the 2021 dessert release,
which may be the last supported release for crosshatch. Oh no!
I am determined not to mark this bug as "Won't Fix / Obsolete"
and yet not so determined to act on it quickly. So, I will fix
crosshatch internally, and then fix the rest of the projects on our
internal master branch.
I hope this patch finds you well and remember to take care of
yourself in these tough times.
With regards,
Chris
Bug: 132925372
Bug: 135906639
Bug: 77804134
Change-Id: I2d088bcbdfbc758eed5054f0413ab02aa5e57e4c
Signed-off-by: donjohanliebert <donjohanliebert@gmail.com>
- from device/google/sunfish@441168f
- correct battery capacity and cpufreq for sweet
- update Radio related values, gps.on value & wifi.batchedscan values
- based on stock power profile
- values taken from resource-overlay
Signed-off-by: Pulkit077 <pulkitagarwal2k1@gmail.com>
Change-Id: Ie393df152ead4ea50327315c57ce1d3a8b540da7
Signed-off-by: donjohanliebert <donjohanliebert@gmail.com>
The display uses different gamma curves for different refresh rates.
It's hard for panel vendor to tune the curves to have exact same brightness
for different refresh rate (lazy). To avoid flicker at darker environment,
set threshold for 120Hz, so 120Hz will be default in such conditions.
- values kanged from redfin, it works for our panel fine
Change-Id: Ie2042aa5d7b114c006841e1cd86c3257653242be
Bring back old usage of status_bar_height, status_bar_height_portrait,
and status_bar_height_landscape by set the size containing cutout size.
Bug: 216782082
Test: make
Change-Id: I0bf97352bc07e45d7694f9512266f08e7139c103
This sets config_is_powerbutton_fps, since the device has
fps embedded in the power button. It makes frameworks report that
fingerprint sensor is located on the side of the device, which
can be observed when enrolling a fingerprint for the first time.
Change-Id: Ifa079488db642c8a470e40cb585c08e9c85d7cf4
* The device's ultrasound proximity sensor is not active
during standby, thus it can't be used as a check before
pulsing. This fixes Ambient Display.
Change-Id: I1fc416247ed13cbfba245f37a4aafeae74ddbff7
AOSP has changed how the status bar height is determined
in commit [1]. Since then status_bar_height_portrait is
ignored in favor of getting the height dynamically based
on display cutouts. Devices are supposed to keep the
default value and let system handle the display cutout.
However, we do not have a display cutout but instead
change the status bar height to match our heavily rounded
corners, which was not taken into consideration in the
commit. Hence change the default status bar height
directly so that the status bar height matches the
rounded corners.
[1]: 16496cb5c1
Change-Id: I9470fbe9058de3b326e12dc092f94e20faab0a47
Bug:131774557
Test: flash a new C2F2 device with format, open accessibility vibration
settings. The current vibration intensity levels should be High
Change-Id: I0dc6488a4aa10ba3d606ecaa29729d4f0ecb9a1d
(cherry picked from commit 5b34c1ea60d65fc899484b727c5ecf32e47979ff)
sweet supports switching between 60 and 120 Hz refresh rates, so let's
expose it in Settings -> Display -> Smooth Display for users to save
battery if necessary.
Test: visual confirmation after toggling several times
Change-Id: Ie698ec4d4e738afd2a9055dba2369233103a4f13
Add a new priority PRIORITY_DEVICE_PEAK_REFRESH_RATE, and a new config
setting config_defaultRefreshRate which maps to that priority. This
allows an OEM to easily specify a default frame rate different from the
peak frame rate.
Bug: 148978450
Bug: 154648391
Test: - Added new unit tests to verify DisplayModeDirector handles min,
peak, and default refresh rate settings correctly.
- Modified a sweet to set config_defaultRefreshRate to 60Hz, confirmed
we default to 60, but that an app calling setFrameRate(120) switches us
to 120.
- Confirmed that the "smooth display" and "force 120Hz" options on Razer
Phone work correctly.
- Confirmed Redfin works as it did before - still constrained to 60Hz.
Change-Id: Ibfc35abed2b67093b8114822d233bf1ca31eebb0
Enables default setting to 120hz mode, this can be disabled through
Settings app
Bug: 130249886
Test: wipe user settings and check default peak refresh rate enabled
Change-Id: I205d793dea3f7b971972fa850b0255dcf18db923
