Develop Reference

Reading class 0 sms in android

My backend service sends a Type 0 sms (PID 0x40) to authenticate the android client. My app is suppose to read the sms and authenticate itself with the information. Is there a way to verify the Type 0 sms is being received by the client. I have added logs in the broadcast receiver that logs sms. I can see logs that tells normal sms received, but nothing for Type 0 sms.
My target device is android 10, and the buildsdk version is 29

First of all, don't confuse type zero and class 0. Those are different types of SMS. Type zero isn't saved or seen by user, class 0 of 'flash' sms is.
Having said that, if you are in the US, keep in mind that Type Zero SMS are automatically blocked unless sent by a mobile stations or Telecomm.

Dead connection message and delivery receipt received delay in stream management - MongooseIM server 2.0.0

I have enable stream management in both side client or server. I have two users A and B. Both users are online.Then user A suddenly lose his connection. but A user still appear online on user B and as well as on server. During that time user B sending message on user A. Those message are not lost but when user A is appear online again it will receive those message after 2-3 minute.and i will get message stanza on Offline storage and delivery receipt i will got on SM storage.This issue same occur on one to one chat and mucLight. have i need to customized any mongooseIM modules. Please guide me why users received delay message when their are lost his connection. is it possible to changed SM storage to offline storage(MAM). here's link for same issue i have found same issue on this link (https://www.ejabberd.im/faq/tcp) but have not lost my messages but just received it delay.
I am use smack-4.2 lib on my Android app.and following code used to enabled stream management in XMPPTCPConnection.
static{
XMPPTCPConnection.setUseStreamManagementDefault(true);
XMPPTCPConnection.setUseStreamManagementResumptionDefault(true);
}
Here's my ejabbered.cfg file for mod_stream_management module
{mod_stream_management, [
% default 100
% size of a buffer of unacked messages
% {buffer_max, 100}
% default 1 - server sends the ack request after each stanza
% {ack_freq, 1}
% default: 600 seconds
% {resume_timeout, 600}
]},
I have also enable following module on my config file
%% Only archives for c2c messages, good performance.
{mod_mam_odbc_user, [pm]},
{mod_mam_cache_user, [pm]},
% {mod_mam_mnesia_dirty_prefs, [pm]},
% {mod_mam_odbc_arch, [pm, no_writer]},
{mod_mam_odbc_async_pool_writer, [pm]},
{mod_mam, []}
I found little solution here smack connect to xmpp server with previous stream id but its not work on mongooseIM-2.0 server.
Thank you in advanced.

I'm assuming below that user A, when they reconnect, is not using Stream Resumption (as defined by XEP-0198: Stream Management) and merely starting a new session.
This means that on the server side there's still a dangling process waiting for Stream Resumption to happen. When user A is already reconnected to the server, the dangling process times out (which takes resume_timeout seconds) and sends the messages it had stored for delivery in the outgoing message buffer.
If you don't like this behaviour, you can do one of these:
a) (not advised) disable Stream Management and send a Message Archive Management query (that is use mod_mam) to have the most up to date conversation state each time you establish a new connection to the server
b) leave Stream Management enabled, but use Stream Resumption if only possible; that is, you always try to resume the previous session, unless you don't have the previous session ID or the server rejects the resumption request; ideally you would also use Message Archive Management
c) use Delayed Delivery aka mod_offline, but risk that in some rare cases, if you use multiple devices, the messages might be sent to a wrong device; for example, if you have a phone and a laptop, it might happen that your messages will reach the laptop, but never reach the phone

Did you try using mod_ping and configure on ejabbered.cfg file.
{mod_ping, [{send_pings, true}]},
fore more details please follow this link mod_ping

What is the difference between text sms and data sms?

Can anyone tell me what the difference is between 'data sms' and 'text sms'? I think I know pretty well what a 'text sms' is, but what is a 'data sms'?
This question arose while developing an android app that receives incoming sms. Using the android api, one can choose whether the incoming sms is 'data' (android.intent.action.DATA_SMS_RECEIVED) or 'text' (android.provider.Telephony.SMS_RECEIVED).
And, is this differentiation only in android api or is it rather general?
Thank you.

no, "Data SMS" is not "SMS over a 3G/4G data connection". Data SMS is just a kind of SMS message where the message is not encoded as a text string but binary.

Data SMS messages are sent through the data network, over your 2G / 3G data connection, just like all other data such as internet traffic. Normally SMS messages have their own method of transport.

Lost messages with aSmack

i'm using aSmack in my Android app to receive messages from my Desktop-Jabber-client. This works fine and even if my android phone is offline (after the connection was closed properly) it will receive the offline messages after the next login.
But when i enter the airplane-mode on the phone or shutdown the phone so that the connection is abruptly closed (without calling disconnect() on the Connection-object) the phone stays "online" in the contact-list of my Desktop-Jabber-client for a while and i can send messages to it. However these messages never arrive. Even though the phone logs in to the server again. These messages are lost.
Does anyone know how to fix this issue? Losing messages in a chat is not an option. :)
EDIT: Added Test-Code
BroadcastReceiver: http://pastebin.com/cFLzGXgy
Service: http://pastebin.com/wLpQCQfT
The first one is a BroadcastReceiver starting the service (second URL) each time the phone is connected to a network.
PS: This is only a test-code! You must change the server/username/password if you want to use/test it.

You can try to send delivered message from client b to client A when the message arrival. The problem is if the client A is offline (no connection break) the delivered confirm don't send until the user receives the message and the client B can't re-send the message.

you can try to send acknowledgement of receiving the message using Smackx Message Events
this will assure the message is delivered else you take corrective action.

this problem occurs when your connection broke.
You need "Stream Management" XEP-198 enabled connections to achieve this messages. refer to this blog : http://op-co.de/blog/posts/XEP-0198/ Basically it allows for stanza acknowledgement and stream resumption, which is exactly what you want to do in case.so you should wait till smack will 4.1 release.

Sending long sms messages

I've got an app that lets users send sms messages. Works great when the message < 160 characters. After that, things work less-perfectly. Seems like there are a few options here:
Manually break the message up into multiple SMSs, send each part as a separate SMS.
Use the multi-part send SMS function (sendMultipartTextMessage()).
Send the message as an MMS message (sendDataMessage()?).
Here's my novice take on it:
1)
most well supported across carriers. Users may get mad that you just cost them N separate messages though, instead of converting to MMS or something.
2)
not sure if this is supported by different carriers, and read that once the message is greater than 3 * 160 chars in length, gets converted to MMS anyway by different SMS apps - maybe stay away from this altogether.
3)
not sure how to do this, and older phones might not support MMS. To send an MMS using the android SDK, do we just use the SmsManager.sendDataMessage() method?
Thanks

This is quite an old post but it's high up on Google when searching for Android multipart sms, so maybe it helps someone.
Regarding part 1 and 2, it's pretty much the same thing. To use sendMultipartTextMessage, you need to break up the long message into an ArrayList of Strings. It then sends as many SMS as needed. In short:
SmsManager sms = SmsManager.getDefault();
ArrayList<String> parts = sms.divideMessage(longMessage);
sms.sendMultipartTextMessage(phoneNumber, null, parts, null, null);
Part 3: MMS is not an option, as it has been pointed out. The charges and all.

seems to me that the first option is what most mobile phones do by default. sms messages by design can only send a certain amount of characters (160 probbaly), just inform the user that the message is too big and if he still wants to send it anyway (informing also how many sms would the total be).
as for MMS and multipart as you said not every carrier supports it, so they dont seem to be the best option.
EDIT: as for how does MMS work on android-sdk check this thread out: Android SDK MMS

I would suggest the usage of option 2 when you are working on Androids GSM based handsets.
GSM based Mobile device takes care of segmentation in which breaking the messages to multiparts for sending in performed and also assembling of the multipart messages in to one message on receipt.
If you have a method which takes care of sending text messages, than by default use the options of manager.divideMessage as it will work even if the message segments required are only 1 in number.
I dont think you should have any problem sending messages using option 2 and it will also ensure that the receiver receives the message as a single message.
Else we need to write your our own protocol stack where in you write reference number and number of messages for the receipient to understand and recreate the complete message; which is not very tough. We can use byte arrays with headers and the messages can be sent as base64 encoded.
Also I dont know much about the limits the carriers enforce on the number of segments in multipart message; based on my test I was able to send and receive 160*8 segments properly. Based on the GSM standards the segments can be upto 255 but that count might depend on the service provider implementation.