Unable to Send SMS with Android 14 + Quectel_Android_RIL_Driver_V4.0.10-0805

Technical Subjects Driver
1

Hi support team,

Using the RK3588 Android 14 SDK and integrating Quectel_Android_RIL_Driver_V4.0.10-0805, I tested with a China Unicom 4G SIM card. The data network works fine, and receiving SMS is also normal, but sending SMS fails. However, when using Quectel_Android_RIL_Driver_V3.5.66, sending SMS works correctly.

When comparing the two versions of the RIL while sending the same SMS message “test hidl +1,” the RIL logs show the following differences:

Successful Case:

11-21 14:41:36.402   682   682 D ATC     : AT> AT+CMGS=24  
11-21 14:41:36.404   682  1067 D ATC     : AT< >  
11-21 14:41:36.404   682  1067 D ATC     : AT> 0891683110200005F001000B813109220960F300000CF4F29C0E42A7C96CD02A06^Z  
11-21 14:41:36.734   682  1067 D ATC     : AT< +CMGS: 94  
11-21 14:41:36.734   682  1067 D ATC     : AT< OK

Failed Case:

11-21 23:28:26.877   681   681 D ATC     : AT> AT+CMGS=24  
11-21 23:28:26.880   681  1178 D ATC     : AT< >  
11-21 23:28:26.880   681  1178 D ATC     : AT> 1D81000230083006300130033000300130003002300030003005300030F001000B813109220960F300000CF4F29C0E42A7C96CD02A06^Z  
11-21 23:28:26.883   681  1178 D ATC     : AT< +CMS ERROR: 304  
11-21 23:28:26.883   681   681 E SMS     : ql_sendSMS error

Could you please assist in resolving the SMS sending issue? Thank you!

2

If you can, you can send the log.
logcat -b all
I will check it laster.

We need to check which AT command is set before the AT+CMGS.
The AT+CGMS return +CMS Error: 304.

304 means that
Invalid PDU mode

And we need to check the AT+CMGF.

3

logcat-radio-sms-fail.txt (520.2 KB)

saved by “logcat -b radio -d” after sending message failed.

4

Update:
After further investigation of the logs, I discovered a potential issue with the SMSC address handling during SMS sending. Here are the relevant logs for comparison:

Successful case:

11-21 14:41:36.388   682   682 D RILC    : onRequest: GET_SMSC_ADDRESS  
11-21 14:41:36.388   682   682 D RILC    : onRequest,7662 g_is_scan_ing = 0  
11-21 14:41:36.388   682   682 D ATC     : AT> AT+CSCA?  
11-21 14:41:36.391   682  1067 D ATC     : AT< +CSCA: "002B0038003600310033003000310030003200300030003500300030",145  
11-21 14:41:36.391   682  1067 D ATC     : AT< OK  
11-21 14:41:36.391   682   682 D RILC    : RequestComplete, RIL_SOCKET_1  
11-21 14:41:36.391   682   682 E RILC    : Calling responseFunction() for token 122  
11-21 14:41:36.391   682   682 D RIL_SERVICE_1_1: getSmscAddressResponse: serial 122  
11-21 14:41:36.392  1068  2097 D RILJ    : [0122]< GET_SMSC_ADDRESS +8613010200500 [PHONE0]

Failed case:

11-21 23:28:26.857  1091  2326 D RILJ    : [0160]> GET_SMSC_ADDRESS [PHONE0]  
11-21 23:28:26.857   681   681 D RadioMessaging: getSmscAddress(): 160  
11-21 23:28:26.857   681   681 D RILC    : onRequest: GET_SMSC_ADDRESS  
11-21 23:28:26.857   681   681 D ATC     : AT> AT+CSCA?  
11-21 23:28:26.862   681  1178 D ATC     : AT< +CSCA: "002B0038003600310033003000310030003200300030003500300030",145  
11-21 23:28:26.862   681  1178 D ATC     : AT< OK  
11-21 23:28:26.862   681   681 D RadioMessaging: getSmscAddressResponse: serial:160, slotId:0  
11-21 23:28:26.863  1091  1127 D RILJ    : [0160]< GET_SMSC_ADDRESS 002B0038003600310033003000310030003200300030003500300030 [PHONE0]

Upon comparison:

  • The AT command AT+CSCA? returned the same raw result in both cases.
  • However, in the successful case, the decoded SMSC address is +8613010200500, as expected.
  • In the failed case, the SMSC address remains in its raw encoded format (002B00380036...) and is not properly decoded, leading to an incorrect SMSC address in the final PDU.
5

Thanks for your analyze.

The AIDL driver is not full tested.
I will test it next week for the SMS.

6

Hi,

Any update on this ?

7

I have found the problem.
It is because the AIDL version it sent the
AT+CNMI=1,2,2,1,0
If I try
echo -ne “at+cnmi=2,2\r” > /dev/ttyUSB2
And then the SMS sending works.
Maybe you can try add the AT comand AT+CNMI=2,2 in the ql-ril.conf.