@Flohack thanks, for warnings.
What I wanted to know, if somebody knows about some write protections to bootloader. So currently we are not sure if the bootloader protects itself from changing while running, right?
For few year I've used UT on bqE5 maintained by Canonical. Recently I've bought new phone FP2 and I've installed UT by Ubports. I'm familiar with linux (10 years no other OS) and I'm using Ubuntu on all my devices. I've a degree in cybernetics and I think I'm slight above average in reading/writing code. I'm familiar with C++ (I hate it), Pascal/Delphi (this was long time ago), PHP (along with html/css/js for work), SQL (for work), Matlab (long time ago for school) and Go/Golang (my current favourite). I've tried other programing languages (Python, Haskel, Java, ...), but I'm just above beginer level in them. I speak Slovak, English and German and I'm currently learning Japanese (fresh beginer).
@zubozrout parada... ehm... great
So, let's say, we have a custom bootlogo for my device, named
splash.img. Any hints, where should I start to look, if I want to use the
dd command to rewrite the splash screen image? And is there any possibility, that I could irreparably brick my phone, if something goes wrong?
Just a crazy idea, that brought up a question. Is it theoretically possible to change the boot splash screen image using only the phone itself?
Not using some external commands via adb os ssh. Just using terminal and some skillfully crafted program.
It happened to me few times too. Someone called me. I canceled the call, cause I wanted to call back (I had some free minutes). Opened phone app, tapped green call button, and it started to make a call to the person I called a day ago last time. For some reasons (intuition?) I expected that the last (incoming or outgoing) number would be called as default.
I tried apt install screen on ubport and apt can't run.
You need to install
screen into your libertine container.
$ libertine-container-manager install-package -p screen
Then you can run a screen session.
$ libertine-container-manager exec -c "screen"
NOTE: first time I got access permission error for
/var/run/screen. You can fix this by logging into container and change permissions.
$ libertine-container-manager exec -c "/bin/bash" root@ubuntu-phablet:/# chmod 777 /var/run/screen/ root@ubuntu-phablet:/# exit
After this, I was able to run a screen instance, deattach, bu no reattach success after libertine container was exited and run again.
# enter container, run screen and deattach $ libertine-container-manager exec -c "/bin/bash" root@ubuntu-phablet:/# screen -ls No Sockets found in /var/run/screen/S-root. root@ubuntu-phablet:/# screen -dmS worker root@ubuntu-phablet:/# screen -ls There is a screen on: 30070.worker (15.02.2019 17:57:40) (Detached) 1 Socket in /var/run/screen/S-root. # worker is in deattached state, reattach root@ubuntu-phablet:/# screen -r worker # Now I'm succesfully attaced to worker, using "ctrl-a d" to deatach again [detached from 30530.worker] root@ubuntu-phablet:/# screen -ls There is a screen on: 30530.worker (15.02.2019 18:00:38) (Detached) 1 Socket in /var/run/screen/S-root. # exit container and reenter again root@ubuntu-phablet:/# exit libertine-container-manager exec -c "/bin/bash" root@ubuntu-phablet:/# screen -ls There is a screen on: 30530.worker (15.02.2019 18:00:37) (Detached) 1 Socket in /var/run/screen/S-root. root@ubuntu-phablet:/# screen -r worker Error: Cannot find master process to attach to! root@ubuntu-phablet:/#
How can I keep program running and quit the ssh tunnel?Then reconnect to it, to seen what the program has returned?
For this purpose, I'm using screen*. Thus, haven't tested it in UT, yet.
Edit: I'm using an "*" for link reference and not an link (like screen), cause if I do with the link above, I'm flagged as spammer by Akismet. Just saying.
I think, battery duration got slightly better on FP2.
Last observation on 2019-W06 resulted in battery drain 21% in 15 hours (~17% in 12 hours) with Wifi on, mobile data & bt off and no usage (conditions as my previous tests).
This is worse than on android, but 2x better, than last year OTAs. Good work, keep it up. Sooner or later battery usage will be as good as on android.