@CatWithUT
Thank you for your work it seems very interesting to me!
Just a quick question: do you think it would be feasible to create a .click package and have it in the Openstore? In a similar fashion that uWolf and uFirefox does? Can we avoid libertine containers? Do you think upcoming Mir2.0 will change anything in this regard as it supports Wayland?
Do you use Mobian build scripts for ARM, for signal-desktop? https://github.com/0mniteck/Signal-Desktop-Mobian/releases
And also note: if we can get an initial version to build and make an UT package I'm willing to work on making patches to make the interface responsive as I have done with whatsapp web. I think this is the easy part.
But we should first make a set of scripts to build automatically a binary, and then a click package that can run on UT.
@Ingo Thank you for the ideas. This happens at random when the phone is switched on with screen off and I switch on the screen. Then, the colored noise can persist even after reboot.
Because of this pattern, I didn't identify any app as the troublemaker.
Thank you for the fairphone community map.
Since following 'https://support.fairphone.com/hc/en-us/articles/115001041206-Troubleshoot-your-Fairphone-2-issue > Display > My display shows a pixel image (coloured noise)' leads to the exact picture of my screen, I suppose this is most probably a known hardware issue.
I followed the instructions on @advocatux link, which means opening and cleaning every inner parts of the phone.
It works again but it has already been doing working - colored noise - working loops so I will keep you informed.
@dobey said in Security of data and passwords when phone is lost/stolen:
This is only true if the bootloader is already unlocked, or the device has a bug where unlocking the bootloader does not perform a system reset and destroy all data. Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.
You're right. Completely forgot that unlocking forced a wipe. Thanks for the correction.
Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.
Yes, that process is what I'm referring to when I say unlocking must be authorized from within the stock OS before it can be done to newer devices. (i.e., "must be flagged as unlockable from within developer settings" in the earlier post. I probably should have added the word "manually" before "flagged" to make that clear.)
yes, @Opolork : posts have specific topics, which makes them easy to find... so if someone has an issue, others who might have the same issue, or have had in the past, might be able to help, or get help.