Currently all writes to the dev interface are done
by WriteStringToFd that uses char internally.
The current values seem to expect to be written as s32,
this sadly won't happen and triggers a special case in
the write handling of pm_qos_power_write:
it expects char buffers to be encoded as base16 and
decodes them.
This means the current 44 is actually 0x44 -> 68 seen by
the kernel.
Luckily it seems like both accepted values for this node
don't hit the threshold to enter C2, so it was never
noticed in real usage and didn't effect the device
C-States handling during hints.
Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
Change-Id: Ic544d4dcaa1edc3de913aed737baf1af88a45360
Today, the dark boot follows the Dark Theme mode in Settings. Now
the UI team decide to always use dark boot after the device is
provisioned. So users will see fewer disturbances when a scheduled
update is taken at night
Bug: 181339788
Test: flash a Pixel -> boot -> dark theme is set;
boot again -> observe dark boot
Change-Id: Id4989e4e78471bcefc2730ba7d9adc36f5ac9c75
For non-REL branch, move VNDK APEX to /vendor partition so we don't need
to update vendor.img prebuilt everytime there is a change in the VNDK
libraries.
For REL branch, the API/ABI surfaces of VNDK libraries are frozen so
don't need to move to /vendor partition.
Bug: 140136207
Test: Build on REL and non-REL branch
Change-Id: Ibce24465b546c52bc447b4b28a474de2b4b53792
These debuf.sf.early_* properties have been inactive because they are
all eclipsed by the settings in wahoo/device.mk. Specifically,
// wahoo/device.mk
PRODUCT_PROPERTY_OVERRIDES := a=10
// taimen/device.mk
include wahoo/device.mk
PRODUCT_PROPERTY_OVERRIDES += a=20
With above, PRODUCT_PROPERTY_OVERRIDES becomes "a=10 a=20" and the build
system has chosen "a=10" via the uniq-pairs-by-first-component macro.
This was because PRODUCT_* lists were designed with an assumption that
those mk files are inherited (without being included) in which case the
values from more specific *.mk file are 'prepended' (not appaended).
Since the settings in taimen/device.mk has been obsolete, let's remove
them. This problem was actually found with
I9c073a21c8257987cf2378012cadaeeeb698a4fb where duplicated sysprop
assignments are prohibited, which is an attempt to make the sysprop
settings be agnostic to the confusing ordering behavior imposed by the
product inheritance mechanism.
Bug: 117892318
Bug: 158735147
Test: m
Exempt-From-Owner-Approval: cherry-pick master
Merged-In: I6d1dd46edba0ad69586791935fca0da484ef2746
(cherry picked from commit 695f1fbe29f2ea08ed3a5cefb0fa487bea9144f4)
Change-Id: I6d1dd46edba0ad69586791935fca0da484ef2746
These debuf.sf.early_* properties have been inactive because they are
all eclipsed by the settings in wahoo/device.mk. Specifically,
// wahoo/device.mk
PRODUCT_PROPERTY_OVERRIDES := a=10
// taimen/device.mk
include wahoo/device.mk
PRODUCT_PROPERTY_OVERRIDES += a=20
With above, PRODUCT_PROPERTY_OVERRIDES becomes "a=10 a=20" and the build
system has chosen "a=10" via the uniq-pairs-by-first-component macro.
This was because PRODUCT_* lists were designed with an assumption that
those mk files are inherited (without being included) in which case the
values from more specific *.mk file are 'prepended' (not appaended).
Since the settings in taimen/device.mk has been obsolete, let's remove
them. This problem was actually found with
I9c073a21c8257987cf2378012cadaeeeb698a4fb where duplicated sysprop
assignments are prohibited, which is an attempt to make the sysprop
settings be agnostic to the confusing ordering behavior imposed by the
product inheritance mechanism.
Bug: 117892318
Bug: 158735147
Test: m
Exempt-From-Owner-Approval: cherry-pick master
Merged-In: I6d1dd46edba0ad69586791935fca0da484ef2746
(cherry picked from commit 695f1fbe29f2ea08ed3a5cefb0fa487bea9144f4)
Change-Id: I6d1dd46edba0ad69586791935fca0da484ef2746
Revert "[DO NOT MERGE] Remove ASSIST_GESTURE action from deferre..."
Revert submission 11818631-deferred_medium_priority_actions
Reason for revert: <investigate b/159568565>
Reverted Changes:
Id1d6d67f6:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
I9bc31a200:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
I9b033a06e:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
I1633e191c:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
I56d8f9e5d:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
I086d2d9a5:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
Ibc6e15d29:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
I086d2d9a5:[DO NOT MERGE] Remove ASSIST_GESTURE action from d...
Change-Id: I0d174786308589a8bd6eaa0453b8614008b509d9
We plan to disable active edge from P20 project. Since the
deferred_medium_priority_actions contains ASSIST_GESTURE action and
it will be the showing deferred setup condition. So we add a new
PixelSetupWizardOverlayActiveEdge RRO package to enable this action from
deferred_medium_priority_actions for P19 and older project.
go/suw-disable-activie-edge
Bug: 158540758
Test: manual test
Change-Id: I9b033a06e04ea6c97003d972058e0c7b0349d6c9
