Skip to content

devices/FP5: automatically flash stock Android 13 as part of bootstrap#299

Open
peat-psuwit wants to merge 1 commit intomasterfrom
personal/peat-psuwit/fp5-auto-flash-firmware
Open

devices/FP5: automatically flash stock Android 13 as part of bootstrap#299
peat-psuwit wants to merge 1 commit intomasterfrom
personal/peat-psuwit/fp5-auto-flash-firmware

Conversation

@peat-psuwit
Copy link
Contributor

Seems not every people reads the whole unlock instructions and missed the "Android 13" requirement. So to simplify this process, just download FP5's Android 13 factory image and flash it on user's behalf.

The image is distributed as a zip with a direct URL that we can pull directly. A screen asking user to acknowledge Fairphone's EULA is added.

The list of partitions to flash is taken from the flashing script (also distributed in the image zip file). As it includes some seemingly low- level partitions, I've added a fail-safe assert to prevent flashing them to a wrong device.

Seems not every people reads the whole unlock instructions and missed
the "Android 13" requirement. So to simplify this process, just download
FP5's Android 13 factory image and flash it on user's behalf.

The image is distributed as a zip with a direct URL that we can pull
directly. A screen asking user to acknowledge Fairphone's EULA is added.

The list of partitions to flash is taken from the flashing script (also
distributed in the image zip file). As it includes some seemingly low-
level partitions, I've added a fail-safe assert to prevent flashing them
to a wrong device.
@maciek134
Copy link
Contributor

So this looks fine functionally, but can we at least verify the firmware on the device first with some fastboot assertions?

@peat-psuwit
Copy link
Contributor Author

I don't know... I don't think there's any meaningful bootloader variable that we can check. And while pulling partition image from the phone is possible, I think that's kind of heavy-weight option.

But why do we want to check firmware first? I don't think it matters if we flash the same image back again. Or this is a worry about anti-rollback that you mentioned in Telegram group?

@maciek134
Copy link
Contributor

No anti-rollback protection shenanigans on Fairphone thankfully, it's not enforced once the bootloader is unlocked.

This is mostly about not downloading the 1GB+ image when it might not be necessary without the ability to easily skip it. I guess it might need more investigation.

Copy link
Contributor

@maciek134 maciek134 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm code-wise, but I don't have the device to test it

@gpatel-fr
Copy link

Hello
sorry to barge as a mere user (I'm planning to buy a phone in the near future and it could be a Fairphone 5) but I'm not so sure this is the best idea.

Automation is good when nothing goes wrong, but there could be a few things that could block the installation / flashing; to cite a few, the editor changing something (the path to the file), the user not understanding what is happening and interrupting the flashing while it occurs, the user not following the prescriptions (having the phone charged to 80%, removing the Sims...) because they will not even know that it is recommended to do so. If anything goes wrong, there is no way to work around and to skip this step unless I'm not understanding fully this change (a possibility) - so if the phone has already been updated and the process is interrupted before the end, it is necessary to download everything again.

@maciek134
Copy link
Contributor

maciek134 commented Oct 21, 2025

No worries, the installer is for the users and so is the issue tracker :)

the editor changing something (the path to the file)

What editor? Installer configs are immutable, the installer doesn't change them. If you mean a person editing, that's the reason we carefully review each change before it's merged.

the user not understanding what is happening and interrupting the flashing while it occurs

The result would be the same or worse if they do this during UT flashing too.

the user not following the prescriptions (having the phone charged to 80%, removing the Sims...)

I'm not aware of such recommendations and they don't make sense anyway (we flash with a cable connected and I have no idea why removing the SIM would be necessary for flashing)

so if the phone has already been updated and the process is interrupted before the end, it is necessary to download everything again

Downloads are cached, my only reservation was about downloading it the first time while the device was already on the correct version - if something happens and the process has to be restarted nothing is downloaded again

@gpatel-fr
Copy link

What editor? Installer configs are immutable, the installer doesn't change them. If you mean a person editing, that's the reason we carefully review each change before it's merged.

I should have said 'url'. Don't think that Fairphone (the company) has done a firm commitment to the old motto 'cool urls don't change'

the user not understanding what is happening and interrupting the flashing while it occurs

The result would be the same or worse if they do this during UT flashing too.

the user not following the prescriptions (having the phone charged to 80%, removing the Sims...)

I'm not aware of such recommendations

these recommandations are listed at the url the installer is linking to (well, before the PR), under 'Before you start':

https://support.fairphone.com/hc/en-us/articles/18896094650513-How-to-manually-install-Android-on-your-Fairphone

@maciek134
Copy link
Contributor

Ah, yes, if the URL stopped working that would be a problem (could be manually worked around by putting the file in cache, though the UX in the installer could use some changes there).

As for the recommendations, we could check the battery level with fastboot getvar battery-soc-ok - returns yes if the device is charged enough to be safely flashed. I have no idea where the recommendation to remove SIMs comes from, and well you can't remove the eSIM anyway so that's not even a viable one.

@gpatel-fr
Copy link

I have no idea where the recommendation to remove SIMs comes from

me neither, but when I do a job on behalf of a customer for a third party system, I follow the editor's recommendations to the letter even if I don't see the point. That's a matter of responsability. If something bad happens, even if it's the editor's fault, if I have not followed the official way, that's an argument against me. If you take the way 'we are open source ! we have NO responsability whatsoever !', yes that's true that you don't have a personal responsability. But if customers complain to Fairphone company, relations between the project (UBPorts) and the business (Fairphone) could become strained.

@maciek134
Copy link
Contributor

While I can see your point, we generally have the technical knowledge to gauge these things. There is absolutely no technical reason to remove a SIM card from a device while it's being flashed. If we did everything the official way of every manufacturer, the installer wouldn't exist because they don't recommend flashing custom software 😅

As for the battery level, I think it's a good idea and I've created an issue to fix it across the whole installer (ubports/ubports-installer#4283) - an older device with a weak battery could have trouble keeping charge for example.

@gpatel-fr
Copy link

If we did everything the official way of every manufacturer

hmm, yes but there are to the best of my knowledge only 2 manufacturers that don't ignore the project: Volla and Fairphone. Don't seem a good idea to take the risk of antagonize one, the more so that the other could consider that it shows that the project is not a good team player (with these German fellows it's something that has some weight I think). While it's a good idea to make the process easier for users, I still think that this should be cleared first with the manufacturer OR it should provide at the user's choice a way to do it the manufacturer's preferred way.

@amartinz
Copy link
Member

There is definitely no risk in having SIM cards inserted while flashing (I am working for a German Smartphone manufacturer you have not listed and this is stated nowhere in any public or non-public documentation anywhere).

Copy link
Member

@amartinz amartinz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's "just" about unnecessarily downloading the image, I'd personally go for make it work first, improve later.

@gpatel-fr
Copy link

I'll sign off here for this subject as I have said all I wanted to say and arguing further would not lead to a meaningful outcome. J appreciate that you want to make the installer better about the charging. Best of luck.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants