I read the post about single-thread some days ago, and I understood why I couldn't approach the problem using timers. The 1st version of my app implemented the so-deprecated wait feature using a timer resetting a boolean flag used as a condition to exit from an infinite while loop. The app did not function at all, resulting in a real infinite loop doing nothing. That was so because, as we could read in the link you gave me, AI2 enabled the timer, but did not ackowledge its "fired" event until it would have arrived at the end of the procedure, that is never. It queues the request from the timer having fired, but would pass the control to it only after its own end.
So I moved to a different approach, as you can see looking at my blocks: I use a timer not to react to its firing event, but to check the time elapsed from an initial moment onwards. It works fine.
I tried following your advice, using a 2nd clock fire event to (re)print (every 500ms) the status label text with the contents of a global string variable set within the for loop. As I was expecting, though, it did not work: the timer fired every 500ms but, being Ai2 in single-thread mode, its fired event code did not execute until the end of the procedure containing the for loop, when it's too late. Even following your advice literally would not work, beside having a counter incremented with no relationship with the sms actually sent.
All problems remain: the confirmation dialog does not close, its "YES" button remain freezed down and the label text does not update. Why so? In Delphi :) I used to code a component.Update/Invalidate/Refresh/Update followed by a Application.ProcessMessages if changing the aspect of interface components within long loops. Could it be something similar here in Android?
Thank you anyway,