* Rename hals.conf -> _hals.conf so legitimate
MultiHAL won't attempt to load our HALs.
* Rename multihal -> multihal-samsung8974 so soong
doesn't complain about duplicate package names.
* Remove USE_SENSOR_MULTI_HAL flag requirement so
we can actually build it.
* Use TARGET_BOARD_PLATFORM variable in package
name because it's a common tree.
Change-Id: Ifa8c20747e3f0bf9bae8b42dd4c499cf6d770e27
Upstream change I732234a22328a1bfcb603bb020547f543b6fd766 makes
RIL_UNSOL_DC_RT_INFO_CHANGED's responseFunction() NULL, without
protecting against it in RIL_onUnsolicitedResponse(), thus crash-
ing at least hammerhead's RIL stack upon mobile data connection.
https://android-review.googlesource.com/#/c/platform/hardware/ril/+/345950/
Change-Id: I6567019cb6daf6492a29e04cc9872e69b2ba456d
Signed-off-by: D. Andrei Măceș <Andrei.Maces@alumni.nd.edu>
(cherry picked from commit e73eafff8695ab28201acbc03a362d5b177047aa)
Testing response times to time.android.com from around the globe reveals
in ms:-
Europe <30
Middle East <68
North America <150
Johannesburg 183
Buenos Aires 220
Tokyo 226
Sydney 276
Hong Kong 285
Brisbane 295
Mumbai 349
Beijing 4691
Shanghai 4906
Russia n/a
Whilst time.android.com is NOT used for GPS NTP, North American time servers
are, by specifying north-america.pool.ntp.org as default in the framework,
to align with pixel devices. I am assuming similar response times to these
servers from around the world.
Great for North America and it appears Europe but it does not address the
global issue. Also, the pool.ntp.org project forbids both hardware and
software vendors from using these default zone names.
http://www.pool.ntp.org/en/vendors.html
It makes sense, therefore, to leverage the ntp.org's existing 'android' vendor
name to make the default ntp server for GPS purposes:
1.android.pool.ntp.org this will return a random but accurate NTP server in
close geopraphic proximity to the device.
Testing on my own build in the UK seems to improve hot and cold TTFF
considerably.
Change-Id: I144af45757efa35b32daf034eece6e046d2bde79
* These should be set appropriately by carrier, and should already be
at the correct values by default in packages/apps/CarrierConfig
Change-Id: I433b110570c2b79b15076dadf58777e0289e347a
* All of the libsec-ril*.so libraries reference these symbols, but
Google finally dropped the non-inlined versions from libcutils with
Android 8.0. This could be handled with shims in numerous device
trees, but shim semantics and implementation aren't exactly stable
and we can handle it more cleanly here in one place.
* See LineageOS/android_system_core@103e8f560
Change-Id: I787372b739f3ace0d9cbbc33e4bffafa6876665e
* Up until now, vendor build properties were added into /system/build.prop
when property split isn't enabled. However, Google realised that
either /vendor/build.prop or /system/vendor/build.prop can always exist,
and decided to clean up code and always install vendor build props
into $(TARGET_OUT_VENDOR)/build.prop.
* For this reason, the unified devices that used to override build props
such as build fingerprint, will need to override the matching vendor
build props.
Change-Id: Iacdd8eb67543daff5a46b92dbaf17cd094ce462b
* This is necessary for the built-in music player to play files off
of fuse (NTFS, in our case, for the most part) volumes
Change-Id: Ib6fffb5c2b5c8c514979a7aabce949d82902b2d1
* XTRA_SERVERs are important, right? Like to get the almanac data
necessary for aGPS. Without the XTRA download, the chip needs to
collect sufficient navigation messages from the birds to compute
where they are in order to make sense of the ranging signals.
* Well, it seems that O doesn't like reading these entries from the
gps.conf file.
When in gps.conf:
GpsXtraDownloader: No XTRA servers were specified in the GPS configuration
When in overlay:
<that noise doesn't exist>
* This seems to, finally, return GPS fix performance to what we had
in N.
Change-Id: I70679835ec5dea053c5aa3750acee628906d6390
* While msm8974 is not 64 bit, certain users of this libril will be
* A previous revision of this libril had 16 bytes of padding in this
struct for 64-bit platforms (due to word size and struct alignment),
but a change by me to use a long instead of a pointer and an int
broke this padding for 64-bit platforms because a long is still
just 8 bytes on 64-bit platforms, where 16 bytes is necessary
* Use two pointers as padding instead to make 64-bit great again
Change-Id: If599bdb625f7a45e083f5b30df512d12810be79b
This reverts commit 24d70a1aec.
* The new HIDL power HAL seems to be appropriately riced^Wfixed for
8974 now.
Change-Id: I629ab2314dec4698a0d4d45d77cdc48bf92a4d74
Add a device-specific SunlightEnhancement CMHW class.
In addition to enabling outdoor mode, crank the display brightness
up, allowing for much better visibility in bright sunlight.
Change-Id: I6a87d438a0aecd9e068de932d4133e69e0563cf8
The recent change we made in the build repo makes all
builds dexpreopt only boot img and system server.
This changes angler builds back to full dexpreopt.
Change-Id: I0cf03634ee7bbc93b18b49d3f1efe82a6302b447
* Shims have been moved to a board flag, so we no longer need
noatsecure to make LD_SHIM_LIBS persist through services
Change-Id: I94b8c30e28e6dd297e0020ddfb46b2af21068721
* No apparent resolution difference
* Much smoother animation
* Much faster boot
* What's not to like?
Change-Id: I2119fe826146a3103da50b4862ad88f5950a97ec
* This is based on how it was done in cm-14.1, but redone
because the old code completely ignored signedness
* Samsung, in their stock RIL.java, reads index as an int,
sets the first 8 bits to index, the next 8 bits to call_id,
and ignores the upper 16 bytes of the int parcelled up
* This emulates that behavior here, except it only sends the
first 8 bits so that AOSP's RIL.java doesn't get confused
Change-Id: I5c78447fdef7d5fd7fc39addb970300ee1188cd1
* Sometimes, the modem is sending 1-2 extra fields with
the country mcc, which confuses ServiceStateTracker
* Drop the extra data here, instead of in our RIL class
[haggertk]: Forward port to ril-caf on lineage-15.
Change-Id: Ifbec67bb0dac271226bd8b5471deaf6a2ef33f2b
* Checking numInts and numStrings for strict equality when
we're not looping is dumb, because Samsung is notorious
for sending extra information in their RIL
* Check if there's *enough* data rather than the *exact amount*
to fix a bunch of invalid response errors
Change-Id: I14bc37240e5760b4629fcb74b64f25ad95d4fdfc
* For search, the number of strings returned for
RIL_REQUEST_QUERY_AVAILABLE_NETWORKS should be defined in the system
prop ro.ril.telephony.qan_resp_strings
Change-Id: Ie5bb8ba80c5ac93b7502da3b1bb3d2b4404ecd5e
* Samsung added an int to the end of the RIL_SMS_Response
struct in some of the variants (like vzw) but not all
* The presence of this field was discovered by examining
the stock RIL.java, which conditionally read an extra
int from the parcel, based on the device specific
CscFeature_RIL_SmsErrorClassRetry feature
* This causes SMS messages to show as "failed to send"
in the app, when they actually suceeded in sending
* Allow Samsung's custom struct and AOSP's to fix it
* Forward port to ril-caf on lineage-15.1
Change-Id: I6b3e545c2c42ab2de2ac11e93dfdf9546248080a
***** SIGNAL STRENGTH HACKS NOT PORTED YET *****
[javelinanddart]: Redo this code from 14.1 to include
the proper RIL_Call fixes, no Samsung unsol/request
handling as it was unnecessary, and a extensible way
to remap RIL unsols if necessary for the device
Change-Id: I59bad9925d141e6cefbc24d4eefdc0c79017852a
This reverts commit e955914336.
* As it turns out, the brand new HIDL power HAL isn't ready, at
least not for legacy devices like msm8974. Symptoms were that
after waking from sleep, cores 1-3 are not brought back online
consistently.
* Let's go back to the old thing, at least for now.
Change-Id: Ica2ddbeb42635662167efe0b48f0fe4051591b26
* The bulk of the device family policy was common and applicable
to all Samsung msm8974-devices. Move that common stuff here to
ease maintenance.
Change-Id: I86516adfb1b9c55a6959a7faf4ee424a4b3385c8
* So, uh, it turns out we need to disable booting with all
but 1 CPU core to fix CDMA RIL on klte (and hlte?), so
let's enable full dex preopt so that we don't need to
dex opt after system updates
Change-Id: I6fe57f9dcd1da8245eebd51d61055d6de7ffe6cd
AOSP and mainline are going towards removing old 32-bit binder API support.
64-bit binder is 100% compatible with 32-bit kernel and userspace,
so there is no reason for us to keep using the old solution anymore.
We've switched to new API in our kernel, same thing should be applied to our userspace.
Change-Id: I3c95bd7fbd023c5cb08e856b3a3889c03228e843
