That sounds like an interesting application!
I have written an AI2 app that happily communicates with an Arduino based BLE equipped device EVEN when the phone locks itself and/or the app is no longer visible. I have run it like that for days sending data from the Arduino device to the app (at intervals of 100msecs, etc - so tons of data reliably received over BLE by my app whether it is in foreground or background!). So I think what you want to do is possible but you need to approach it a little differently.
Having said that, Chris is of course correct in that certain BLE functionality like Scanning & Connecting do NOT work in an AI2 app when the app is no longer in the foreground (showing on the screen) but these should not affect your planned application if you approach it correctly.
So what I KNOW works even if app is no longer active on the screen (so you are running other apps or phone simply goes into lock mode with screen off) are things like "BLE.StringsReceived" (from the Arduino device, after you have first connected and then "BLE.RegisteredForStrings" in your app before the app/phone goes to semi-sleep). I have tested this on my relatively old Google/LG Nexus 5 phone (which uses Android 6.X). I also tested it on a newer Google Pixel Phone running Android 8 I think. Not sure if other (non-Google branded) phones would behave the same (as obviously there is a slight battery hit when this BLE data transfer is continuously happening in "background" mode.
So here is my suggestion:
2. Then you let the Arduino side "drive" the connection by sending data to the App (which you will receive in the App via BLE.StringsReceived ) every so often (maybe every second or even less frequently in your case). The data sent by Arduino side could be a single character like a "?" (sort of a "What's Up?" or a "Anything new?" for me!).
3. On the AI2 app side you can then use the "BLE.StringsReceived" event to check if you have received an SMS (or whatever you want to send to your glasses!) and if you DO have something you "simply" issue a "BLE.WriteStrings" on the same connection but using the "TX" CharacteristicUUID with the same ServiceUUID of the previously (& continuously kept alive by BLE!) established connection.
So bottom line is that you "stay connected" and you let the glasses "drive" the process (in other words the simple data received from the glasses will "wake up" your app with the "BLE.StringsReceived" event/call, thereby allowing your app to check if anything new has arrived that needs to be sent to the glasses). If yiu have something to send to the glasses you send it with "WriteStrings" and then the app simply "goes to sleep" again, waiting for the next "StringsReceived" call from the glasses.
I am pretty confident this will work and in fact in AI2 it is simple to implement! :)
Hope this helps and/or it at least provides you with some food for thought!