[FL-3953] Application chaining

[portasynthinca3]

What's new

• Deferred application launches, i.e. launching one as soon as the requesting app exits. FL-3959

Verification

• Run ./fbt launch APPSRC=loader_chaining_b. This app will should exit immediately when launched like that.
• Run ./fbt launch APPSRC=loader_chaining_a. Run through each of the 5 choices:
  • "Launch B": an hourglass animation should be displayed, quickly followed by a dialog from app B.
    • The "Just quit" dialog option should return to the desktop.
    • The "Launch A" dialog option should return to app A.
  • "Launch B, then A": an hourglass animation should be displayed, quickly followed by a dialog from app B.
    • The "Just quit" dialog option should return to app A.
    • The "Launch A" dialog option should return to app A. Once it is exited from, app A should get launched again. Once exited from again, the desktop should be shown.
  • "Trigger error: silent": should behave as though it just exits the app. The serial logs should contain an app launch error.
  • "Trigger error: GUI": a standard system error message should be displayed ("App Not Found"), followed by the desktop.

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[github-actions]

Compiled f7 firmware for commit 95eafaa2:

• 📦 Update package
• 📥 DFU file
• ☁️ Web/App updater
• 📊 Size report

[CookiePLMonster]

Can this be used to have FAPs run system apps like a "stack", for example launching Passport and then returning to my custom app when it closes?

[skotopes]

Can this be used to have FAPs run system apps like a "stack", for example launching Passport and then returning to my custom app when it closes?

in theory yes. Originally it was implemented for nfc->mfkey->nfc chaining

[CookiePLMonster]

in theory yes. Originally it was implemented for nfc->mfkey->nfc chaining

My "real" question in here is - if system apps can be loaded and my app re-launches after that system app terminates, this enables people to create custom desktops, which I think is a pretty nice use case for a feature like this.

[skotopes]

in theory yes. Originally it was implemented for nfc->mfkey->nfc chaining

My "real" question in here is - if system apps can be loaded and my app re-launches after that system app terminates, this enables people to create custom desktops, which I think is a pretty nice use case for a feature like this.

this specific PR is not going to solve your problem. But it can be improved to do so in future

[portasynthinca3]

launching Passport and then returning to my custom app when it closes

@CookiePLMonster unfortunately no. That would require Passport to explicitly launch you after itself. I don't think we need to be implementing that "app stack" with automatic returns within the Loader.

[portasynthinca3]

@CookiePLMonster looks like your use case might be possible after the latest commit

[CookiePLMonster]

With the new API, can we obtain the return code of a last enqueued application once ours relaunches? Or is this information lost?

[skotopes]

fails with deadlock from file browser (left button)