Support Team,

  This has been a noticeable and reproducible issue since we implemented two-factor authentication for our RDP connections using the ADSelfService app and registering with push notifications.  We are noticing that when our phone are not "awake" and in use, the push notifications are 40-50% reliable.  It likely has to do with whatever methods are being used to wake the phone when it is shallow vs deep sleep mode (i.e. if the phone has had its screen off for 15 or 30 seconds when compared to being off for more than a minute or two).  When we first noticed the issue, we assumed it was to do with Android's aggressive power-saving and background data settings, so we did make the changes per the attached screenshots more than a few months ago.  Background data is set to Allow for both Mobile and Wifi connections, and Background battery usage is set to Unrestricted.  Also, Android is set to NEVER pause the app if it has not been used in a while.

Even with those settings, when the phone screen is off and hasn't been used for even just a few minutes, we will not get the push notifications.  The only way to do so is to open the phone and launch the mobile app, wait a few seconds, and we'll eventually receive the push notification which is by now expired.  After re-initiating an RDP connection to the desired server, we will then receive the timely push notification the second time.   When the phone screen has been off for maybe just 30 seconds or a minute, we DO receive the push notifications from AD Self Service, directly on the lock screen (which is what we expect).

The screenshots from my phone (Galaxy S22 Ultra) are with Android 13, OneUI 5.0, but this has been an issue even with Android 12 on other phones.  Also to note, I have MS Authenticator, Google Authenticator, and DUO Mobile Authenticator that has 2FA push notifications for other vendors and sites, and we have not once experienced the same issue with them.  For those apps, we did NOT have to adjust the default background data and background battery settings.  I can also confirm that AD Self Service is not listed in the "sleeping apps" or "deep sleeping apps" list in the OS.

Some persistence/background/force-to-always-run method your team is using may be deprecated and not call all appropriate screen wake functions.  Can they check this? It has actually been going on for quite a while, but we did not get the chance to report it sooner.  And are any other customers experiencing the same?