Did you manage the upgrade?
Hi.
Why do I need to manually upgrade the OS
The updater app does not support upgrades from one Android version to another. It will hide any update of a different version. We are working on resolving this issue. While this issue is resolved, users need to manually upgrade their OS. Upgrading manually requires similar steps to installing /e/OS for the first time.
This is outdated - at least for me.
The OTA upgrade from a stable 1.8.1-R to a stable 1.9-S just worked for me flawlessly.
I did not even expect it - except that the system-upgrade info box warned me, that the new Android 12 - based version … bla bla… please make a backup - etc.
I thought that the upgrade information would be a typo or not realizing correctly I still had an Android 11-based version.
The wording from step 4 is confusing, it looks like this is a step one has to execute but no instruction how to do it because this how-to is explained in step 5. Maybe merge these two together to get a better understanding for the non-so-knowables like myself
Hi,
I followed the doc for installation on my FP3 :
https://doc.e.foundation/devices/FP3/install
Once downloaded and unziped this :
IMG-e-1.10-s-20230412278810-stable-FP3.zip
I launched the script to wipe and install eos on my phone :
chmod +x flash_FP3_factory.sh && ./flash_FP3_factory.sh
I got the following error:
error: cannot load ‘…/IMG-e-1.10-s-20230412278810-stable-FP3/tz.img’: No such file or directory
Editing the script and checking, I see that there are two files missing in the zip built:
flash_image_ab_or_abort “${sn}” tz “${IMAGES_DIR}/tz.img”
flash_image_ab_or_abort “${sn}” vendor “${IMAGES_DIR}/vendor.img”
Can you help ?
My mistake, sorry : the downloaded file was corrupted.
Yes @fab, I eventually understood how to do and used easyinstaller. Some steps were not working exactly as expected but the process succeeded. Now I have version 1.8.1 R and most things work fine.
That’s cool. So now you know how to upgrade to 1.10 stable!
Yes! I have done it two days ago. It was just easy and fast!
Maybe I am at the correct place. If not, please move.
I present my findings on the battery usage and charging of my FP3+.
Since January 8th 2023 (262.2 days) I noted some data to find out about time and effort related to it.
It is understood that this is relying on my personal using pattern which might not be average, since I go without email on it, rarely use „social‟ media and do seldomly look up anything but use my head instead.
So, I guess the numbers might not be fully representative.
I have a special charging pattern, too, as I tend to keep the battery between 30 and 70% and fully charge it to 100% about every 10th time charging to reset the controller. This is due to the given fact that batteries get stressed by being totally drained or fully charged, which decreases their lifetime.
My FP3+ is two years old now and so is the battery.
That said I recon that the knowledge of relationships of the different versions and subversions possibly are useful to the developers as well as the users.
I started to note on January 8th with v1.7, but began to note the special charging times (e.g. such as daytime of start and end, giving the average charging time for 1% battery life) with v1.9 on March 30th.
This results in graphs for the power usage starting with v1.7 and start of the charging graphs with v.1.9.
As I always install the rc-subversions as soon as they are available, which tend to sometimes give a wide range of results within the version. It is difficult to decide what the special reasons are, as sometimes version changes appear within a few days being accompanied by changes in the using pattern which I note as well.
E.g., the subversions of v1.13 (v1.13-rc, 1.13-rc2, 1.13-rc4 and v1.13) have an average of 4.91 lasting days. The subversions themselves appear to last 5.60 days (v1.13-rc), 4.19 days (v1.13-rc2), 5.77 days (v1.13-rc4) and 4.45 days.
As they had different durations (327:44 hrs or 13,7 days,102:30 hrs or 4.3 days, 55:43 hrs or 2.3 days, 424:17 hrs or 17.7 days) I included the relationship of installed time into the result (something like (([lasting subversion 1][intall time sv1])+([lasting sv2][intall time sv2])+([lasting sv3][install time sv3])+([lasting time sv4][install time sv4]))/[sum of version install time].
On July 2nd I installed a Matrix-client and started to use it increasingly due to it being a major communication channel on the Chaos Communication Camp which had to be prepared and I went there from August 11th through 20th. So, the actual numbers are clearly influenced by this and might not representate a „normal‟ user pattern, especially for myself. For the camp I noted „excessive use‟.
Here are the graphs for the usage and lasting times, firstly summarized under the main versions, then the single subversions:
And here we go with the charging times and duration, as well summarized under the main versions, then the single subversions:
Usually I tend to charge slowly on my desk- or laptop computer to further save battery life, as fast charging also means stress for the battery resulting in decreased lifetime. Since the heavy usage and very little time on the camp meant that I had to fastcharge it, I thought about the average time that I have to „care‟ for the thing.
I found that the „caring time‟ varies between 1.63% of total time (v1.12-rc.4, lasting 7.27 days, installed for 256:43 hrs or 10.3 days) and 8.72% of total time (v1.14-rc, lasting 2.24 days, installed for 61:57 hrs or 2.6 days).
hello everybody,
I try since a long time to understand how i can sync my APP GALERIE ON MY FAIRPHONE 3+ WITH my murena cloud.
It seems difficult for numerous other users.
Why not a tuto about sync?
Thanks a lot for all the good work you did.
Philippe
Yesterday I installed v1.16-rc.4, which means that v1.15 is final.
- Edit: I forgot to mention that the rc took 5:36 hrs to completely install which makes me wonder for what reason.
It seems that the tendencies are going in the right direction, as the usage decreases and the lasting gets longer.
The “caring time” for the phone seems to be stable more or less.
Here are the figures.
Lasting and usage:
and the subversions:
Charging and “caring time”:
and the subversions:
Now, I wondered how to display the endurance of the versions/subversions and tried this:
and for the subversions:
As I still stick to the habit to keep the battery between 30 and 70% and charge to 100% about every 10th time charging (to reset the controller) I found that in the higher percentages the charging time increases significantly.
When last time charging up fully I noticed at 97% an average of 4:00 minutes per % (charging from 60% through the time of 19:30 to - at the end - 22:40).
9 minutes later it had 98% and the average had risen to 4:07 minutes.
14 minutes later it had 99% with an average of 4:16.
It took another 28 minutes (!) for the last percent and ended up with an average of 4:45.
Have fun!
great graphs, at the very least helps catching outliers
seen this at Update e/OS very slow - #8 by tcecyk before
Oh, that’s a nice catch.
Yes, it makes sense - every time when I looked again, it seemed to gain speed.
I pushed it.
@Manoj the Upgrade documentation still needs to be updated. the zip provided is not a flashable zip anymore and therefore not compatible with the provided procedure (sideload).
procedure accoring to doc: sideload
provided image: fastboot
Thanks for pointing this out. Will share the feedback with the porting team to update the document.
Another update on the battery usage comes with the graphs for v1.16.
I corrected a few flaws in the older numbers.
From v1.14 it went up to 5.7 days and then fell back on 4.7 days lasting.
The charging-and-caring-procedure has decreased by a fifth while it is still on a linear uprise, in spite of a slight decrease of the linear loading time.
The runtime of the versions seems to have the tendency to stopping the current decrease.
Providing an update - its been a while.
v1.19.1 impresses by a massive recovery in runtime and charging effort, since 1.17 and 1.18 had continued the decrease of 1.16.
Also the usage of Advanced Privacy appears to have seized being the leader of the pack.
I repaired some mistakes in the Charging table, so it appears to have changed in some ways.
Here we go with the general Power Usage:
The afore mentioned slightly changed Charging numbers:
1.19.1 provides another improvement here, as the time for 1% charge decreases as well as the overall time to deal with charging.
Runtime/Lasting:
Here we go with another two versions.
I started to note the charging times east of 90%, as they are significantly higher than the others: They double from 90 to 96% and for the last percent (99 → 100) there are between 20 and 26 minutes, usually more around 4 minutes.
I have also changed from *.png to *.jpg for improved view.
Power usage:
1.20 had a little setback, while 1.21 fully recovered and is so far the third best during the observation period since January 2023 as battery usage is concerned.
The charging times show an increase for 1.20 - corresponding to increased usage - and a relaxing for 1.21:
This comes with much better lasting numbers for 1.21, one of the dev versions I installed had even 7,04 days (though the numbers could be slightly inaccurate due to the short measuring time of 2,5 days):
Another major step to v2.0 which performs quite poorly regarding battery usage - there are only three versions with lower lasting so far.
It appears a pattern showing up: from the start of measuring by v1.7 there were three versions worse, then a good one (1.11). Again three worse, then a good one (1.15), three worse, then a good one (1.19).
So, maybe battery life might recover by 2.1 if number magic does help.
Here are the graphs:
As I mentioned, I’m always installing the RCs (anyway I do NOT install alphas and betas), which are altering the graphical picture, as the the overall length of the install time differs from my method.
So I have altered the calculatory basis and now can show how it might look for someone who only upgraded the OS without other changes:
The FP3+ with e/OS was purchased on November 11th 2021 (a little over two-and-a -half years or 975 days old), and its been 546 days now to monitor battery life.
It is rarely shut off and I note any special things that happen or are done, e.g. excessive use, sudden specialities or changes in the user pattern, as there are meanwhile apps like Schildichat (Matrix), Signal, Threema and so on running.
I keep it between 30 and 70% battery capacity, every tenth charging I fully charge it, as the battery likes best to be around 50%, but the controller every now and then must be resetted to keep full capacity. So far between January 8th 2023 and today (546 days) I have fully charged it 45 times or every 12,1 days.
The charging time lies between 0:56 and 2:31 hrs per day, so the phone “enslaves” me between 3,7 and 10,5% of daytime with a median of 1:51 hrs or 7,7% of daytime (at nights, too). This is due to me charging it slow mostly due to battery convenience, and I note when I fast charge (21 times, last on October 23, 2023).
Version 2.1 is matching the pattern of systems I experience, as it seems to be + - - - + - - -…, meaning that after a version with good battery life so far three with less are following, then another good one, as for 1.7, 1.11, 1.15, 1.19.1 and now 2.1.
Here come the graphs:
These are the figures for the versions including subversions (I keep installing the release candidates (RCs), not alphas or betas).
Here’s what’s in it, if you only update the full versions:
It appears that Advanced Privacy has given up to be the leader of the pack as it used to be, and it seems to me that the better battery life results from that, too.
The charging development is here:
and excluding subverions:
It comes plain to be seen that in any case longer battery life decreases the caring time.
Momentarily I charge every second day which I consider quite convenient.
Two days ago it loaded quite fast (34% in 1:50 hrs, 3:14 mins/percent).
Last comes the runtime graph, including:
and excluding subversions: