[Sharp Aquos S2] Not all telecommunications operator work

[normalno1]

On treble roms not all telecommunications operator work (not sim card and imei), but other operators work normaly, on stok rom all operators work fine. Logs after hot swapping from working to not working operator logcat_simcard.txt

Addition by @phhusson (lower comment from @normalno1)

The problem is due to the fact that libril in the vendor is not compatible with standard interfaces in gsi. Problem has been fixed. May be suitable for other FIH devices. https://forum.xda-developers.com/showpost.php?p=78262728&postcount=1707
```https://forum.xda-developers.com/showpost.php?p=76740118&postcount=2

[phhusson]

Could you get me the logs of settings crashing?

Le lun. 17 sept. 2018 à 20:00, normalno1 notifications@github.com a écrit :

On treble roms not all telecommunications operator work (not sim card and imei), but other operators work normaly, on stok rom all operators work fine. Logs after hot swapping from working to not working operator logcat_simcard.txt https://github.com/phhusson/treble_experimentations/files/2389690/logcat_simcard.txt

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/phhusson/treble_experimentations/issues/190, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOOi3J7V3GC5uBFf4ZUYbY_ayu6mP6ks5ub-NVgaJpZM4WsbB1 .

[normalno1]

After boot on working sim card developer settings work fine on "bad" sim card

Could you get me the logs of settings crashing? Le lun. 17 sept. 2018 à 20:00, normalno1 notifications@github.com a écrit :

[normalno1]

@phhusson logs after boot on not working sim card and radio logs logcat_radio.txt

logcat_simcard2.txt

[normalno1]

Logs after developer settings has bug settings_crash_log.txt

[normalno1]

Ril logs radio9.txt

[dmukhin]

AFAIK in GSI we don't have quite huge part of Qualcomm addons (in framework and maybe even in apps) nearly required for correct Qualcomm RIL communication. This is known issue mentioned, for instance, in https://lineageos.org/engineering/Telephony/. Not sure about other Qualcomm based but on Sharp S2 stock developers put it to system

[phhusson]

It depends on what you call "correct". It works quite fine on pretty much all other Qualcomm devices, so that's likely not the issue. Most of the things mentioned in the Lineage page doesn't apply to GSIs, because there Treble gives proper abstraction, and stable wrt ABIs. Only the last section about extensions makes sense, though I don't agree that only Qualcomm's IMS is usable. But anyway, even according to them, only IMS and advanced features should not be working, everything else should be ok.

[dmukhin]

Yes, I agree those QTI hacks should be part of vendor in Treble. Regarding our problems I see in logs that SIM card read but comparing to stock it doesn't execute some specific code in QtiUiccCardProvisioner etc that notifies about subscription established or whatever. I'll add radio log from stock later, you can compare to radio9.txt from above

[dmukhin]

radio.txt.zip

[dmukhin]

BTW: seems like one SIM info response processing failed due to android.hardware.radio.config.V1_0.IRadioConfig.getService(true) thrown java.util.NoSuchElementException

[normalno1]

The problem is due to the fact that libril in the vendor is not compatible with standard interfaces in gsi. Problem has been fixed. May be suitable for other FIH devices. https://forum.xda-developers.com/showpost.php?p=78262728&postcount=1707

[phhusson]

Could you explain what this does?

Le mar. 27 nov. 2018 à 09:39, normalno1 notifications@github.com a écrit :

The problem is due to the fact that libril in the vendor is not compatible with standard interfaces in gsi. Problem has been fixed. May be suitable for other FIH devices. https://forum.xda-developers.com/showpost.php?p=78262728&postcount=1707

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/phhusson/treble_experimentations/issues/190#issuecomment-441972945, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOOjVSEijqLz-ByLNPkxgdAdcagHvSks5uzPpWgaJpZM4WsbB1 .

[dmukhin]

Vendor expanded CardStatus and AppStatus structures with some hotswap and PIN related information thus it broke ABI. They customized framework in stock system to support it as well, when getIccCardStatus response processed and many SIM applications read binder fails to send result from RIL to framework due to structural mismatch. It was found by reverse engineering. That fix aligned ABI

[phhusson]

You mean they changed the Treble HIDL android.hardware.radio.CardStatus ? And your change is to no-op the serialization of the extra fields?

[dmukhin]

Yep they changed HIDL:) Actual serialization done in system VNDK library, I aligned its input structure fill in vendor libril

[phhusson]

Ok, nice finding. Could you send me stock ROM /system/framework folder so that I can examine further and see if it can fixed GSI-side?

[dmukhin]

https://drive.google.com/file/d/1aWlLzCojSCOwutQlUceItoCirs-tfyDY/view?usp=drivesdk

[phhusson]

Thanks

[phhusson]

Since this device wasn't Treble certified (since it wasn't required to), I won't try to fix it (though if someone has an idea for a working and readable MR, I can agree to merge it).

Here are the HAL changes seen in this firmware:

struct AppStatus {
    AppType appType;
    AppState appState;
    PersoSubstate persoSubstate;          // applicable only if app_state == SUBSCRIPTION_PERSO
    string aidPtr;                        // e.g., from 0xA0, 0x00 -> 0x41,
                                          // 0x30, 0x30, 0x30
    string appLabelPtr;
    int32_t pin1Replaced;                 // applicable to USIM, CSIM and ISIM
    PinState pin1;
    PinState pin2;

//int32_t pin1_num_retries
//int32_t puk1_num_retries
//int32_t pin2_num_retries
//int32_t puk2_num_retries
};

struct CardStatus {
    CardState cardState;
    PinState universalPinState;           // applicable to USIM and CSIM
    int32_t gsmUmtsSubscriptionAppIndex;  // value < RadioConst:CARD_MAX_APPS, -1 if none
    int32_t cdmaSubscriptionAppIndex;     // value < RadioConst:CARD_MAX_APPS, -1 if none
    int32_t imsSubscriptionAppIndex;      // value < RadioConst:CARD_MAX_APPS, -1 if none
    vec<AppStatus> applications;          // size <= RadioConst:CARD_MAX_APPS

//int32_t hotswap;
};

The comments are the addition compared to AOSP HAL.

Still, thanks @dmukhin for the details, that's definitely interesting.