Modern Operating systems on mobile devices optimize battery using.
If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode. In Doze mode, the system attempts to conserve battery by restricting apps’ access to network and CPU-intensive services
Restrictions that apply to application in doze mode:
- The system ignores wake locks;
- A network connection is not available;
- The system doesn’t perform WiFi, WiFi RTT, and BLE scans;
- Standard AlarmManager alarms will be rescheduled;
- The system doesn’t allow JobScheduler and WorkManager.
It means in production, operating system will drop any tcp connection (http/websockets/etc) soon when user close application.
- Mediator serve endpoints of Client Agent
- Client Agent and Agent X has established P2P and communicate with DIDComm messages
- Client Agent running on mobile device and listen inbound traffic via websocket or http long polling
- Mobile OS suspend Client Agent application according battery saving plan, so any tcp sockets will be suspended too.
- Agent X send DIDComm message to endpoint (http url reachable from internet)
- Mediator detect all Client Agent tcp connections are unreachable.
- Mediator detect Client Agent declared Firebase device-id in DIDDoc
- Mediator wrap inbound envelop DIDComm message to firebase message and send to Client Agent
- Firebase put message to Queue in the Google cloud to resume dest application.
- Mobile OS resume Client Agent application cause of non-empty Firebase messages queue
- Register your application in Firebase console
- Add support for your Agent application for iOS and Android
- Set server api key and sender id via environment vars or via Admin page