devices/FP5: automatically flash stock Android 13 as part of bootstrap#299
devices/FP5: automatically flash stock Android 13 as part of bootstrap#299peat-psuwit wants to merge 1 commit intomasterfrom
Conversation
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.
|
So this looks fine functionally, but can we at least verify the firmware on the device first with some fastboot assertions? |
|
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? |
|
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. |
maciek134
left a comment
There was a problem hiding this comment.
lgtm code-wise, but I don't have the device to test it
|
Hello 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. |
|
No worries, the installer is for the users and so is the issue tracker :)
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 result would be the same or worse if they do this during UT flashing too.
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)
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 |
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'
these recommandations are listed at the url the installer is linking to (well, before the PR), under 'Before you start': |
|
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 |
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. |
|
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. |
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. |
|
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). |
amartinz
left a comment
There was a problem hiding this comment.
If it's "just" about unnecessarily downloading the image, I'd personally go for make it work first, improve later.
|
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. |
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.