Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seamlessupdate does not handle force stop then restart gracefully #16

Open
renlord opened this issue Jun 3, 2020 · 6 comments
Open

Comments

@renlord
Copy link

renlord commented Jun 3, 2020

Sometimes when seamlessupdate hangs, a user might want to force stop the service and restart it by pressing on "check updates", but this fails silently without a UI prompt for reboot and seamlessupdate will refuse to restart until reboot.

Logcat Logs:

06-03 13:21:20.902  1152  1152 E update_engine: [0603/132120.899720:ERROR:update_attempter_android.cc(-1)] Domain=update_engine, Code=generic_error, Message=An update already applied, waiting for reboot
06-03 13:21:20.906  1152  1152 E update_engine: [0603/132120.906020:ERROR:update_attempter_android.cc(85)] Replying with failure: pc:0x5fb9a8d6bc: An update already applied, waiting for reboot
06-03 13:21:20.909  6320  6482 E AndroidRuntime: FATAL EXCEPTION: IntentService[Service]
06-03 13:21:20.909  6320  6482 E AndroidRuntime: Process: app.seamlessupdate.client, PID: 6320
06-03 13:21:20.909  6320  6482 E AndroidRuntime: android.os.ServiceSpecificException: An update already applied, waiting for reboot (code 1)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.Parcel.createException(Parcel.java:2085)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.Parcel.readException(Parcel.java:2039)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.Parcel.readException(Parcel.java:1987)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.IUpdateEngine$Stub$Proxy.applyPayload(IUpdateEngine.java:247)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.UpdateEngine.applyPayload(UpdateEngine.java:308)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at app.seamlessupdate.client.Service.applyUpdate(Service.java:103)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at app.seamlessupdate.client.Service.onDownloadFinished(Service.java:195)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at app.seamlessupdate.client.Service.onHandleIntent(Service.java:262)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:78)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:107)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:214)
06-03 13:21:20.909  6320  6482 E AndroidRuntime:        at android.os.HandlerThread.run(HandlerThread.java:67
@thestinger thestinger changed the title Seemlessupdate does not handle force stop then restart gracefully Seamlessupdate does not handle force stop then restart gracefully Jun 3, 2020
@thestinger
Copy link
Member

Interesting, not sure why this would happen.

@thestinger
Copy link
Member

It looks like it's update_engine that screwed up though? Unless it did successfully apply the update and the only issue was the UI not showing a notification.

@renlord
Copy link
Author

renlord commented Jun 3, 2020

I think what you suggested was the case.

The progress bar hung and I had to check logcat to do the reboot manually.

@thestinger
Copy link
Member

I think perhaps force stopping Updater didn't stop the update, so it succeeded anyway, but the app wasn't running?

@thestinger
Copy link
Member

It definitely lacks a way to contact update engine and pick up where it left off.

@thestinger thestinger transferred this issue from GrapheneOS/os-issue-tracker Jun 6, 2020
@thestinger thestinger reopened this Jul 24, 2021
@thestinger
Copy link
Member

It now uses a foreground service tied to the progress notification for downloading + verifying + installing so issues like this should be far less frequent without the user triggering it. It still won't handle this well when it's triggered via force stop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants