Technically, this should be fixed device side, but random failure when
HAL side fails shouldn't crash the system either.
Fixes: https://gitlab.com/LineageOS/issues/android/-/issues/8391
Change-Id: Iedd869cbd74e4a5535655c977b8ead74e8d5868d
The existing Hardware Abstraction Layer (HAL) supports two distinct
control modes: TOGGLE and DEADLINE, each offering unique capabilities.
For instance, the TOGGLE mode allows for control over both charging
time and limit, while the DEADLINE mode only enables control over the
charging time. Managing these separate logic streams within a single
ChargingControlController class complicates the development process.
This commit separates the specific charging control logic — determining
what to send to the HAL—from the primary logic. The charging control
module now offers providers tailored to each HAL-supported charging
control mode, allowing for limit control, time control, or both. When
required, the ChargingControlController invokes these specific providers.
This commit also saparates other parts, like notifications, from the
main logic, to a saparate class.
This separation simplifies the codebase. Moreover, when introducing a new
mode in the HAL, developers only need to implement the corresponding
provider's logic based on the mode's capabilities. And minimal changes
are needed in the primary logic.
Change-Id: Ie40020c2df4141d4aa6385c8f5565821af942755
And a few language features (HashMap constructors, collapsing
catch blocks, method references)
plus two typos
Change-Id: I9ae2f7c006c5f2f9c7c99eab81059c08bece1202
* BluetoothAdapter.getDefaultAdapter() is deprecated since sdk 31
* Also fixes wrong naming for mBluetoothAdapter which was local
and thus didn't need the prefix "m"
Change-Id: I003fe06fbd8958cde0fdd71d61710272e32a2ca5
Currently if LineageHardwareManager couldn't get LineageHardwareService
on its first try, it stays disconnected and wouldn't retry in time.
Several one-time isSupported() checks during boot would then fail,
resulting in missing features e.g. HWC2-based LiveDisplay.
Change-Id: I85e6866543798ed4a805db5c99a28ef8a39335cc
Changing APEX modules behavior is as annoying as it can be.
Futhermore this target was used for a single setting entry that can be
easily replaced by using the AOSP settings provider, that is already
accessible in the module.
Change-Id: I0d2aa32dc4f3057d29bf59126c5a2dc3a4043c21
They don't compile and they haven't been updated in years.
They barely cover any of the sdk code, so remove them instead of fixing
them.
Change-Id: I74b2811d0bcead9b590e6c58053bd4b9fd72fec6
* Remove droiddoc, it has been commented out since a few versions
* Remove API which hasn't work since a while
* Remove org.lineageos.platform.sdk library
* Remove samples
* Remove obsolete README
Change-Id: Ieb1c2a64ee04480a81d24cb782806397f64adb7d
* Luxemburgish (lb) was accidentially mapped to "lu" for all of the
non-AOSP projects.
* Since the next sync will download "lb" now, just remove "lu"
Change-Id: I9751d689633e7e795bdda86e3f039f277432c893
No longer necessary to initialize the variable, since the helper
returns the default NFC adapter, or null if no NFC adapter exists.
Additionally, try...catch can also be removed.
Change-Id: Ic3a1fac8cdf892d5ceccec4e39090ac20cc91e5d
This reverts commit c775185a87.
Not needed anymore, after reverting 'sdk: Introduce org.lineageos.platform.resources target'
Change-Id: I8d6b5dbb879c792bd6b5cf09ab9d6752e7001310
This reverts commit 1c6d5b120d.
Not needed anymore, after reverting 'sdk: Introduce org.lineageos.platform.resources target'
Change-Id: I34539f44422432160d89c420c75f86cd9d9927f9
This reverts commit 6ba68050a3.
Reason for revert: this breaks cts test
Test: run cts-dev -m CtsStrictJavaPackagesTestCases --test android.compat.sjp.cts.StrictJavaPackagesTest#testBootClasspathAndSystemServerClasspath_nonDuplicateClasses
Change-Id: I00bbd9220f9d4f5c996dab5b8ca5da6c77ad3208
IPv6-only networks that support 464XLAT use CLAT to access IPv4
addresses, but the traffic that occurs over the CLAT interface is
tracked separately; it is not reflected at all in the stats of the
underlying interface, so prior to this change, IPv4 traffic on
applicable IPv6-only networks is not reflected in the network traffic
monitor, either.
While there is no exposed API to retrieve stacked interfaces, we can
still try to grab the stats for a CLAT interface (which always starts
with "v4-"), just in case it exists, and if so, add in those stats.
Test: Manual: While connected to an IPv6-only network, such as a
T-Mobile cellular data connection, attempt to load https://1.1.1.1
in a browser while the network traffic monitor is enabled. Reload
the page / choose different languages to cause traffic to occur,
and it should be reflected in the traffic monitor.
Issue: calyxos#792
Co-authored-by: Oliver Scott <olivercscott@gmail.com>
Change-Id: Ida768ebe73a47bb06da53aeb7b5c6882f0090e75
