grapheneos / platform_packages_apps_updater Goto Github PK

Hi, the automatic System Update process bar hangs up in the middle after switching my network connection.

I have rebooted the phone & restarted the System Updater after cache deleting.

Device: pixel 4 5g
Update: latest

When I tap on "Check for updates" I'd expect to receive a message, like
Updates available or Could not find any updates or Could not connect update server or whatever.
Right now, it's silent and gives no feedback at all leaving the user in the dark.

Also an update history would be useful, e.g. when something should break which worked before: If there was a hidden update, you'd at least get hint.
It would make the update process also more transparent overall.

Device: Pixel 4a
Version: sunfish-factory-2020.11.27.15

After the zip is verified, the metadata is verified against it to make sure that it was accurate. However, it would be nice to have offline signing of the update channel metadata in a way that enforces the channel name. At the moment, if an attacker takes over the server, they can't do much, but one thing they could do is move the current beta release into the stable channel.

It would be good to pause the download of the update, as sometimes it may have started downloading when you didn't want it. It could be another button (action) in the notification.

Not exactly trivial but shouldn't be hard to implement at all.

When the domain is covered by a wildcard certificate the updater fails with

Hostname example.com not verified: certificate: sha1/... DN: CN=:*.example.com subjectAltNames: [*.example.com]

The update is currently downloaded from a single source, and if for some reason that source goes down updates will not be available at all.

It would be good to have multiple sources supported, and this could also work like a mirror ( (like how F-Droid does it). Check the default server first (with multiple timeouts), and if that fails fallback to a different source. There can be only one backup source, but the code difference for supporting multiple backup sources wouldn't be too huge so it would make sense to just go for that I think.

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

Currently it is possible to disable automatic updating by disabling this app, but it seems like there is no way to disable automatic update checking at predefined 4 hours intervals without doing so. Would you consider adding the option to disable automatic update checks, leaving the user the option to queue up manual updates exclusively?

This change should have various benefits, namely allowing for resource conservation in resource constrained scenarios. It can additionally be optionally bundled in a change that allows the user to select the update interval itself, with one option being something along the lines of "disabled".

Thanks for considering.

I've been using GrapheneOS for a few months now, and really appreciate the update cadence the team provides. However, to view the bug fixes / features of a new release, I have to pull up the releases page. It would be really convenient if the "system update available" notification could bring you to a page within the updater describing the changes.

Thanks in advance!

It's currently possible for the network to change after the job scheduler starts the update where it doesn't fail and continues on a different network not meeting the requirements. It should probably bind to the current network after making sure it's valid and then the usual rescheduling logic should take of everything.

Currently, changing the release channel from stable to beta seems to cause an immediate download and upgrade (depending if automatic reboot is selected), which doesn't seem to have the option to cancel during the process.

b45f075 ?

Would it be possible to have an option somewhere in the process of selecting stable to beta or vice-versa to cancel this, in the event that the user change their mind, or even in case the user tapped the wrong selection?

Please write a quick guide on how to build this project

Hi guys!

I really think these updates changelogs you publish on links should show the text on some option on the system update menu. I think this whole menu should show a description of what’s your current version (not shown on system update section), the newer update number and date, and a summary of what it entails. I find the current updating process rather… Obscure…You don't know where you stand, where are you going to, and what could happen along the way. Samsung (and most other providers) do provide a lot more details about what's about to happen if you proceed. Graphene does not.

Thanks!

This could be done by setting a boolean for needing to show a notification and then setting it back to false after it has been shown.

This may not be desirable because it would be a lot of extra notification channel complexity without much benefit. It would make things more complex for user configuration too.

The process of downloading and installing system updates can be somewhat battery intensive. I'd like the ability to only do so when connected to a charger and within a specific time window.

Here's the options Neo Store gives for syncing F-Droid repositories.

Here's how AntennaPod let's the user chose between an interval or at a specific time.

After an update started downloading, a low priority progress notification should be shown in the notification bar.

When the update is installing, a different notification should be shown or it should at least use a different text. It might tell the user that they are still allowed to reboot during the update.

Earlier this week I received a notification from the updater app that a new release was downloaded, installed and ready to apply upon reboot. I ignored the notification on purpose because I had a busy day and didn't want to be interrupted. However, shortly afterwards my phone somehow rebooted by itself and thereby automatically applied the upgrade. To my surprise, the release turned out to be a major upgrade from Android 11 to Android 12 that contained various bugs/changes and a completely new (awful) UI. Having to deal with this came at a very inconvenient time.

I would urge to:

1. Never perform major version upgrades silently, e.g. without an acknowledgement from the user that they're ready to perform a major upgrade and deal with the consequences that come with it.

2. Even for minor upgrades, don't force them onto people with a mechanism they have zero control over. Make it possible to cancel an update (or at least make it not apply automatically on the next reboot just yet), or if that's not possible add a preference to the updater app to automatically download but not install & apply new releases. There are a dozen conceivable situations where your phone's stability is temporarily more important than running on the latest release.

It can show whether it succeeded or failed to check for updates and download an update if there was one.

For automatic checks, it should be a silent low-priority notification.

For a check triggered by the "Check for updates" option it can be more prominent, so perhaps that should be a separate channel.

First of all I want to express my appreciation for developing and providing GrapheneOS. Thank you for all the hard work!

My issue is probably not a bug. I reckon that this is more likely an issue with my custom built image of GrapheneOS. So far I did not get any OTA update installed on my Pixel4a. Attaching my phone to the ADB shell shows me the following error:
D Service : downloaded 807247091 from 811945318 bytes D Service : download completed D Service : verifyPackage: 0% E Service : failed to download and install update E Service : java.security.SignatureException: signature doesn't match any trusted key E Service : at android.os.RecoverySystem.verifyPackage(RecoverySystem.java:297) E Service : at app.seamlessupdate.client.Service.onDownloadFinished(Service.java:119) E Service : at app.seamlessupdate.client.Service.onHandleIntent(Service.java:309) E Service : at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:77) E Service : at android.os.Handler.dispatchMessage(Handler.java:106) E Service : at android.os.Looper.loop(Looper.java:223) E Service : at android.os.HandlerThread.run(HandlerThread.java:67)

How can I get the signature of an official update into my custom build of GrapheneOS? I followed the following steps during the build process: https://grapheneos.org/build#generating-release-signing-keys.

Did I forget one of the steps during the image build process? Do I have to rebuild the image or is it possible to sideload the keys on a running device?

Cheers
Alex

The ability to check for updates or download/install using a broadcast/Android Intent so it can be trigger via shell scripts or automation apps such as Tasker or Easer.

Here's how AntennaPod does it: https://antennapod.org/documentation/automation/tasker

My phone was at 32%, not charging and in battery saving mode. My system update settings were the following:

• Require battery above warning level: yes
• Require device to be charging: yes

I manually pressed on "Check for updates (Tap to check for updates)", I then got a notification that said it was installing the update and verifying it. The notification after that said "Update successfully installed (Please reboot ...)".

I don't know if the update would have been installed in the background too, without me pressing the "Check for updates" button, but it's unexpected for me that updates are installed, when I merely want to check for new updates. Even if I wanted to install the updates, it should have maybe refused to or warned me, as the phone was not charging and I wished for it to be charging while installing (as per my settings above).

Either the wording of the button is misleading or the button does more than it should!

Pixel 5
Build SP1A.210812.015.2021102613

Updater won't update to the newest build. If I manually trigger the check for new updates it downloads something around 20-50MB of data, after that I get nothing.
Tried to reset the updater app by disabling it and deleting its cache and user-files.

help inform users what new changes have been introduced after an update

Here are some user reports indicating that a device running out of power during a system update can result in file-system corruption, sometimes seemingly severe:

• https://discuss.grapheneos.org/d/9324
• https://discuss.grapheneos.org/d/8958
• https://discuss.grapheneos.org/d/8474
• https://discuss.grapheneos.org/d/8214
• https://discuss.grapheneos.org/d/7081
• https://discuss.grapheneos.org/d/4057
• https://discuss.grapheneos.org/d/4039
• https://discuss.grapheneos.org/d/1594

This situation is presumably rare, but it seems to be troublesome for affected users. Might it be helpful to either require a 50% charge before applying an update, or add a user-settable threshold?

GrapheneOS updater fails to detect the availability of a new update when running Orbot in full-device VPN-mode. This has happened several times before, tested on sargo and bonito on stable. Once Orbot and the related VPN settings are deactivated, the update process starts immediately.

This is in contrast to the information on the website, where it says "The update protocol [...] works well over a VPN / Tor".

Current URL is https://github.com/GrapheneOS/script/blob/12.1/generate_metadata.py which is GrapheneOS 12.1

Should be updated to https://github.com/GrapheneOS/script/blob/13/generate_metadata.py

https://github.com/danielhlynosky78/NewRepo/blob/master/.gitattributes

The updater should display the version number of the OTA being downloaded.

Show a changelog for the updates.

I have a WiP implementation ready which fetches the changelog as HTML from the server and shows it via HTMLViewer (which is what Settings -> About -> Legal) uses.

HTMLViewer is locked down, no js, no internet access, so it seemed like the best way to have something with formatting.

re: ab561cd

steps to reproduce:

1. navigate to the "System update" settings page of the owner account
2. enable "Require device to be charging" in settings
3. ensure the device is not charging
4. tap "Check for updates"

expected: notification indicating the device update status. if there is an update to perform, I would expect that it would be performed regardless of charge status.

actual: no notification appears, I believe no update check is performed.

if this is intentional, feel free to close the issue. but it goes against my expectation of the wording for the "Check for updates" button - "Tap to check for updates as soon as possible". I was under the impression that the charging toggle only applies to background update activity.

Thank you for your efforts on GrapheneOS, I love it so far!

Today I noticed that within 10 days the system updater used over 500 MB of my mobile data to download updates in the background. I wasn't aware of it and was a little upset to see that, as I would never expect large downloads to be made over metered connections by default.

I can see reasoning for this, as a security-first operating system should have sensible defaults for features relevant to security (timely and fast updates), so I'm not even going to suggest changing this default.

What I would like to suggest instead is to maybe add a hint in the "Post-installation" section of the installation guides, that updates are downloaded on metered networks by default and that if the user wants to change that, they should do so in the settings. I read the installation guide top-to-bottom (obviously), but I didn't read everything in the usage guide extremely thoroughly, so I missed that even metered networks are used by default, until I noticed it today.

I think a small hint like that would be a nice heads-up! I'd be happy to hear your opinions.

What am I asking for

An option (non-default) to let me choose when updates are installed.

Why

There are times, usually when I'm travelling abroad, when having my phone fail (even just a single app, like notes) could be a stressful/bad time. These are the times when I don't want updates, because as rare as it is (huge props to the grapheneos team) breaking updates could happen. As it is now, (unless i actively mark every network i connect to as metered) it will automatically download and prep the update, and then the next time I reboot the update is installed whether I want it or not. This makes it feel somewhat like a loaded russian roulette gun with the safety off; so long as i dont reboot (unfortunately a standard troubleshooting step for baseband-and-beyond issues) or run completely out of battery, the update won't install

Why not a way to pause updates

For me personally, having to remember to do this would be another thing I could forget before trevelling and would add to my stress, death-by-a-thousand-cuts style

Also, the userbase who went out of their way to install a privacy-focused OS is going to be much better about proactively installing updates, and I hope we could be trusted to decide when they're installed

User-story-ish

1. I enable this new option
2. A new update is available
3. I'm connected to an unmetered wifi network, so the update is downloaded
4. A notification pops up "would you like to install this update?"
5. I look at the notification, and think about my situation. "Oh no definitely not, I'm at 5% battery and I still need to get a rideshare back to the hotel"
6. A few days later I'm back home, comfortable and could live without my phone for multiple days

This is fairly straightforward to implement, but requires setting up more static files on the server. It will need a metadata-only update zip that's still properly signed along with a separate payload.

due to frequent updates lately, users who have Internet packages with limited monthly capacities very quickly run out of Intentnet credit due to updates when they are away from home or out of Wi-Fi range. You could add the "update only via Wifi" option. to update only when the user is on Wi-Fi, to avoid using up mobile internet.
thanks in advance

One of the Matrix members mentioned in the chat room that they'd been accidentally running an older version of the operating system until checking the releases page manually, even after tapping "Check for updates" manually. It looks like they had some proxy settings set with Orbot and that may have interfered with it and caused the update check to fail silently.

If the update client can't reach the update server when it's time to check for an update, would it be advisable to get the update client to fail loudly rather than fail silently and produce a "cannot reach the update server" error when an update is requested.

Some advantages I see of this approach is that it provides immediate feedback and lets the user know when their proxy settings for any reason aren't letting the phone reach the update server. Some disadvantages I could see of this approach would be that it continues to rely on user interaction, with the associated Pandora's box of shifting the responsibility back onto the user and desensitizing them to the error messages.

Another option that occurred to me might be to take the approach that the Factory OS does, and keep a record of the last successful check for an update in the update client.

An advantage I could see of this approach is that it could be made much quieter and also it'd let the users know when their device is out of date without having to nag and desensitize them to warnings.

Neither of these options are mutually exclusive.

What do you guys think?

When the "required battery level" toggle is activated, why not already start to download and install available updates when connecting the phone to the charger?

Would be nice to have feature to disable checking or downloading updates. For example not to make connections to grapheneos update servers, also to postpone updates if you can't have a situation where something on the phone doesn't work because of an update.
Of course this option should warn user that it can make phone insecure.