Samsung enables FOD in TS driver (fod_enable) at all times except
a small number of optical FOD sensor that doesn't have BiometricFeature
.FEATURE_SUPPORT_AOD. As optical type sensor support is not implemented
currently, this HAL is only used on device that has FOD always-on.
This change follows behavior of stock firmware and without toggling of
FOD enable state FOD should be more stable.
Plus it allows setInteractive and config_powerDecoupleInteractiveModeFromDisplay
to function properly with FOD. Currently setInteractive(0) happens before
a onShowFODView (which is the current point to call fod_enable) can be
triggered by the Doze, as TS driver only handles command when it is enabled,
FOD doesn't work when there is a setInteractive(0) that disables TS.
Change-Id: I22291cc62d81ffdaa5edd3f684f9788b0c0650c2
Samsung's proximity sensor type is binary in nature.
There are only two state: FAR and NEAR.
However, Samsung uses values between min and max for
other purposes like proximity detection during Always-On
Display.
This breaks proximity detection during Doze for AOSP as
AOSP only considers the proximity sensor in FAR state
when the value equals or larger than max.
Thus, this change sets the max to 1 so any > 1 value
would be considered as FAR and the behavior of this vendor
proximity sensor type matches the behavior expected by AOSP.
Change-Id: I56af8e2ae743b47e3c4894e5ef68ce0b54e5cfdb
We found that stock firmware calculates the fod rect
from resolution and a set of inscreen fingerprint
sensor position data at boot and then use set_fod_rect
command to tell the Kernel TSP driver.
Then the Kernel TSP driver wrote it to "sponge"
(presumably firmware of touchscreen panel).
It is not yet known what exactly was done with this
data but it is good to keep in line with stock
firmware when we can.
Change-Id: Id44d399a8dc482c7d6f320a3bbfea1282ac4f83a
Signed-off-by: Jesse Chan <jc@lineageos.org>
Enabling sensor on Press is slow and frequent on/off
switching on Press/Release leads to unexpected results.
Looking into Kernel, the purpose of FOD_ENABLE/FOD_DISABLE
commands are to save battery. (ts->lowpower_mode) It is not
meant to handle fingerprint authentication on Press/Release.
It is expected that FOD is in ENABLED state whenever the user
is EXPECTED to use fingerprint authentication soon.
Thus, this patch moved FOD_ENABLE/FOD_DISABLE from
OnPress/onRelease to onShowFODView/onHideFODView so the
fingerprint authentication can be faster and the logic makes
more sense.
Change-Id: Id94b71acd55038d6eda7a1a89dde5fdf5a1e298f
Signed-off-by: Jesse Chan <jc@lineageos.org>
Samsung uses a special OperationMode (5555).
Thanks to Pierre-Hugues HUSSON for the hint.
Change-Id: I037ff5bf5a1edd65b616480d1c43cef8e61ba999
Signed-off-by: Jesse Chan <jc@lineageos.org>
Samsung uses their own com.samsung.sensor.physical_proximity
type instead of SENSOR_TYPE_PROXIMITY of Android.
This makes proximity sensor unavailable for us as we only
look for SENSOR_TYPE_PROXIMITY.
Thus, this change maps Samsung's vendor-specific proximity
sensor type to generic one.
Change-Id: I64f6558876e1398dfbea0e5c0eb76aa1aafd2dfd
Signed-off-by: Jesse Chan <jc@lineageos.org>
Samsung uses a permission com.samsung.permission.SSENSOR
for Samsung-specfic sensors. Android obviously does not
have that and the default is denied when there is no
permission. As such, those sensors are inaccessible.
Thus, this change removes this permission from those sensors
so we can use them.
Android does not require special permissions for most sensors
so this change doesn't attach additional permission requirements
to those sensors.
However, note that it is possible that some sensitive sensors
introduced by Samsung in the future may use SSENSOR permission
and for privacy reasons they should be handled separately with
appropriate permission control attached.
Change-Id: Ia3033898722039b285e522e226074238508f6093
Signed-off-by: Jesse Chan <jc@lineageos.org>
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Bug: 73535841
Change-Id: Iabb0556dc1c80c7fc7f6c76d61d5e441b03cdce0
* Apply the default Oreo theme and inherit the layouts
from Google for the Settings app, in order to keep
UI consistency.
* Get rid of SettingsDrawerActivity as it no longer fits in
and include the back button in the action bar.
* Kill the icon drawable not only because is a leftover,
but also doesn't really serve any puropose in the new UI.
Change-Id: I71ea2c118dcfd387904d04516572902babb16e35
Should fix this:
W/ContextImpl(3700): Calling a method in the system process without a qualified user:
android.app.ContextImpl.sendBroadcast:877
android.content.ContextWrapper.sendBroadcast:421
com.cyanogenmod.settings.device.SamsungDozeService.launchDozePulse:151
com.cyanogenmod.settings.device.SamsungDozeService.-wrap1:-1
com.cyanogenmod.settings.device.SamsungDozeService$SamsungProximitySensor.onSensorChanged:81
Change-Id: I680a57c9010d06719c3bd014001b00353f8e12fd
As stated in ActivityManagerService:
The vast majority of broadcasts sent from system internals
should be protected to avoid security holes
Change-Id: I1dc989d9d132d40835ca8dbf277285eb88e30a58
As of commit 8cd28f3bce5612d35c4b6196554c7e2846057310,
this app no longer lives on the Settings dashboard.
This reverts commit a75b016e61ef544abdadf4c5e7a508c04b18c8dc.
Change-Id: If5b1fa89ddcc9de3c93217ef79189ad9ebd5193d
Reduce the clutter on the dashboard and move the ambient display
settings to where it belongs - in the display settings.
Change-Id: Ib08cc799e9f58884465b1730ce794cbc8be080f9
* Use SecureSettingSwitchPreference for Ambient Display
* Use the XML preference dependency attribute
Change-Id: I3480af71e334110aed834a53f49b33a853f16316
* Translations moved to the new project
android_packages_resources_devicesettings
Change-Id: I06536915e1963a2fe464c3d6c46dd8728aba0cb4
Signed-off-by: Adrian DC <radian.dc@gmail.com>
Currently, the preference titles are very vague and confusing,
with no way for the user to understand what the preferences
do at a glance (e.g. in Settings search).
Make the purpose of the preferences more explicit through the titles.
Also, the current drawable is colored white, when it should be
colored green. This results in a near-invisible icon in the
Settings search results.
Color the drawable the appropriate teal instead.
Change-Id: I2dac9a73e8689f14d676b41922e0eba364c6500f
Bring this up to speed on the Settings changes in N:
* Use support libs for preferences
* Hook up to Settings drawer through SettingsDrawerActivity
Change-Id: I9365b3ebd1bbfed2936302e30da50e3f9af06665
Jesse Chan