After implementing AppLock, the device back button closes the app instead of returning to the previous screen (Android)

[joelrose2]

Describe the bug
Before implementing flutter_app_lock, the device back button would always return to the previous screen (the one from which it was pushed). With flutter_app_lock, the device back button will close the app entirely (Android) instead, if the second screen called and dismissed any dialog box.

To Reproduce

I have established with certainty that this behavior is due to the addition of flutter_app_lock to the app, because when I simply comment-out the following lines and run the app, the back button behaves as expected.

MaterialApp(
...
      // builder: (context, child) => AppLock(
      //   builder: (context, arg) => child!,
      //   lockScreenBuilder: (context) => LockScreen(),
      //   initiallyEnabled: (currentAppLockMode > 0), // 0 = no lock, 1 = PIN, 2 = biometrics
      //   initialBackgroundLockLatency: const Duration(seconds: 5),
      // ),

Expected behavior
Even if the user opens and closes a dialog in a screen, after the dialog is closed, the screen's own pop() should return to the previous route in the stack and not hide the entire app.

Additional context (optional)
I am developing using:
[√] Flutter (Channel stable, 3.29.1, on Microsoft Windows [Version 10.0.26100.3194], locale en-US)
[√] Windows Version (11 Pro 64-bit, 24H2, 2009)
[√] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
[√] Android Studio (version 2024.3)
[√] VS Code, 64-bit edition (version 1.97.2)

[tomalabaster]

Thanks for raising @joelrose2 ! This sounds like it's again to do with AppLock using a Navigator under the hood...

I'll loop this issue in on any progress made to removing the use of a Navigator under the hood!

[joelrose2]

Hi @tomalabaster Thanks for the fast acknowledgment. This is a terrific package, but not usable if kills the app experience (literally and figuratively!). Can you estimate how long it might be until there is a solution? Or perhaps you can share a workaround? Thanks.

[tomalabaster]

@joelrose2 thanks for those kind words! You could try my work in progress branch which looks at using Overlays instead of a Navigator...

dependencies:
  ...
  flutter_app_lock:
    git:
      url: https://github.com/tomalabaster/flutter_app_lock.git
      ref: feature/#31_-_use_overlay_instead_of_navigator

If this serves you well then it's possible I could land this change sooner but if it's no good then it may be back to the drawing board...

I'll of course give some thought to any other workarounds or potential fixes and update you when I can!

[szuwest]

I am facing this issue. Any progress?

[tomalabaster]

@szuwest thanks for the nudge - have you tried the WIP branch detailed above?

[szuwest]

@szuwest thanks for the nudge - have you tried the WIP branch detailed above?

I didn't try it. It is quite easy to cause bugs with Overlay, I think.
I found something interesting, someone copy this library code to project to avoid the extra Navigator。Here is the link: https://github.com/ente-io/ente/blob/main/mobile/apps/photos/lib/ui/tools/app_lock.dart. Maybe helpful? @tomalabaster

[tomalabaster]

It is quite easy to cause bugs with Overlay, I think.

This is why I wanted to have some people try it before I create a new major release..! If you are able to at least try it out, that would be hugely helpful to know that it still works for people beyond my basic test app 🙂 It's been a while since I've touched it but I believe I left it in an API compatible state with the current version.

someone copy this library code to project to avoid the extra Navigator

Thanks for sharing! Nice to see it be used in a repo with lots of stars. It does however look like they're using an earlier copy of flutter_app_lock. Previously flutter_app_lock used a MaterialApp under the hood, then I changed it to be Navigator only (to resolve theming conflicts).

[szuwest]

It is quite easy to cause bugs with Overlay, I think.

This is why I wanted to have some people try it before I create a new major release..! If you are able to at least try it out, that would be hugely helpful to know that it still works for people beyond my basic test app 🙂 It's been a while since I've touched it but I believe I left it in an API compatible state with the current version.

someone copy this library code to project to avoid the extra Navigator

Thanks for sharing! Nice to see it be used in a repo with lots of stars. It does however look like they're using an earlier copy of flutter_app_lock. Previously flutter_app_lock used a MaterialApp under the hood, then I changed it to be Navigator only (to resolve theming conflicts).

I have tested this branch on my Android phone and iPhone.
Android phone everything is OK. The lock screen shows up normally, and the navigator works fine.
But on iPhone, the lock screen shows up with the app launch, it doesn't show up from background to foreground.
@tomalabaster

[tomalabaster]

@szuwest thank you for trying it out! Are you able to provide a screen recording at all? Or a minimal example you're using so I can reproduce? Good to hear that Android is all ok!

[szuwest]

@szuwest thank you for trying it out! Are you able to provide a screen recording at all? Or a minimal example you're using so I can reproduce? Good to hear that Android is all ok!

Sorry, I can not provide a screen recording. I test it on my own app. I just changed the branch, didn't change the code. In the main branch, everything is fine, except the Android navigator. In the new branch, it doesn't show lock screen when the app resumes from background to foreground in iOS platform. @tomalabaster

[tomalabaster]

In the new branch, it doesn't show lock screen when the app resumes from background to foreground in iOS platform. @tomalabaster

What do you have enabled/initiallyEnabled and backgroundLockLatency/initialBackgroundLockLatency set to on your AppLock widget?

[szuwest]

In the new branch, it doesn't show lock screen when the app resumes from background to foreground in iOS platform. @tomalabaster

What do you have enabled/initiallyEnabled and backgroundLockLatency/initialBackgroundLockLatency set to on your AppLock widget?

enabled is true
backgroundLockLatency is one minute.

[tomalabaster]

Thanks @szuwest! Please see the attached screen recording.

App.Lock.Overlay.Branch.iOS.mp4

I send the app to the background and foreground a couple of times at the start and the lock screen isn't showing. From approx 00:23 to 01:26 the app is in the background and then I bring it to the foreground again and the lock screen shows.

I did this by changing the following in example/main.dart:

void main({
  bool initiallyEnabled = true, // <-- I changed this
  @visibleForTesting
  Duration initialBackgroundLockLatency = const Duration(seconds: 60), // <-- I changed this
}) {
  ...
}

[szuwest]

Thanks @szuwest! Please see the attached screen recording.

App.Lock.Overlay.Branch.iOS.mp4
I send the app to the background and foreground a couple of times at the start and the lock screen isn't showing. From approx 00:23 to 01:26 the app is in the background and then I bring it to the foreground again and the lock screen shows.

I did this by changing the following in example/main.dart:

void main({
bool initiallyEnabled = true, // <-- I changed this
@VisibleForTesting
Duration initialBackgroundLockLatency = const Duration(seconds: 60), // <-- I changed this
}) {
...
}

It doesn't work.

I checked the code, and debug it on iphone.
I found that:

///didChangeAppLifecycleState
///app launch ： inactive --》 resume
///to background：inactive --》hidden --》 paused
///background to foreground：hidden --》inactive --》resume

the problem is in didChangeAppLifecycleState.