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
* Doesn't compile after 14 QPR2 / AP1A
* Has always been an issue for CTS
[CIRCULAR REFERENCE: com.android.tools.r8.internal.h: Library class vendor.lineage.trust.V1_0.IUsbRestrict implements program class android.hidl.base.V1_0.IBase]
Change-Id: Id2a4ccc60d7cae6bca02e302725d982d50311278
A new network traffic display unit option "automatic" offers
a compact display of the network traffic by using at maximum
three digits and an abbreviated unit string.
Comes in handy for situations with reduced space in the
status bar.
Change-Id: Ib4d969924ad5a345b03540070e49a0473f343ad3
There might be edge cases of devices that have no power button
and no way to control externally connected displays. In such cases,
if display has touch support, DT2S shouldn't be allowed at all.
Change-Id: I3976f138d02f0b6ddf8ce239cb8c3a19ab737b67
The migration happened in lineage 15.1,
we only support direct upgrades from 17.1.
This partially reverts commit e7008a222e.
Change-Id: Ic2acd93565e21475ea6f896941107230d880e890
Do not save the target time unless setting deadline succeeds,
effectively allowing it to be retried later.
Change-Id: I572b935b088170d56623a33c5efd2292b1a67126
It is only possible to upgrade from 17.1 to 20.0 directly,
let's just drop all the old migration steps.
Change-Id: I04ec638f3b7c75d53629c8fec5523a0ccc7eabb5
* We usually shouldn't touch existing migrations,
they would have already ran for most (if not all) users,
and don't run for existing users since they start at
the latest version.
* However, we've recently discovered many issues with these
migrations, and past reported issues are now starting to make
sense (they can be explained by migration running over and over again)
* As such, let's fix this once and for all to make things clearer.
* We also tend to copy older migrations when writing soemthing new so it
should help having these done :)
Change-Id: Ic45efc823da7ea8a137e79b3769a9ca53c2f8667
Add new private methods readSetting, readIntegerSetting,
readLongSetting, writeSetting, and writeSettingIfNotPresent
to reduce boilerplate and potential for code errors.
Change-Id: I9872cc50db86056cdc1588741600b66ee9d40f9f
There is no need to use database transactions to simply read settings.
We also were not setting the transaction as successful, which was
causing the outer transaction for the whole onUpgrade operation to be
rolled back, meaning that some devices would be stuck at old db
versions and perform repeated migration attempts on every boot.
Issue: calyxos#1290
Change-Id: Icefe994379152f9a3aa6c0c5b447cc55d5c4cf46
* Really shouldn't have touched an existing migration before
* Anywho, let's change it back to what it was but make it compile
* Then, let's migrate that old setting to the new AOSP setting,
but flip it since it works differently.
Change-Id: I342d8c78aa8faeda5dcaafe9199deb51c570efd0
