Originally Posted by MSe1969
Hi @anupritaisno1 - thanks for your feedback.
Indeed a valid point - do you have a good idea how to "establish a link" between Settings in the ROM and the "backup tool" (see also next item)? One of my objectives is to provide functionality not necessarily requiring active root - so anything which would need to remount the system partition (which can only be done with root access) is out of scope.
Issue is that the backup tool by default first takes the contents of /system/addon.d, then executes the "pre-backup" tasks, then flashes the new ROM, then executes the "past-flashing" tasks - still with the /sytem/addon.d files from the previous ROM! The only thing I could think of would somehow be a modified updater-script in the flashable ZIP - which brings me to the question, where to find the place in the build tree, where that is defined (I have started searching for it, but wasn't lucky finding it yet - because if I consider that approach, I would like to make sure to build and use that modified updater-script automatically in the ROM ZIP). Any thoughts?
Well, a point which definitely is subject to the individual point of view. I don't want to object to your point stating "leave it up to the user", because you are right!
Nevertheless, this ROM has the idea of some "pre-delivered privacy" in focus (which means something "ready to use" rather than "gain root, search the net and take care yourself") and people keen on using microG instead of Google are usually also not the kind of people who consider unrelated ad pop-ups on sites, they visit, as something valuable, which they would miss, if not present . . .
My ROM e.g. also uses Bromite WebView and not the "vanilla AOSP" Webview and the question "why not leave that up to the user, whoever wants Bromite should flash it himself" would be equally valid. . .
True - Alternative is to activate root and use e.g. the AdAway app (from which I take my updates).
Without root, a frequent monthly update is better than nothing (one objective of this ROM is to provide features, for which you normally would need root).
The idea of defining an own DNS is still on my to-do list - independently of ad-blocking. More to come.
The motivation to use a different DNS is driven by different factors: circumvent censorship (which also is a topic in the "free and democratic countries", if you ask me - of course, it is then called "copyright" or "ban of fake news" instead of "censorship" ), no logging ("Hey Google!") or - as you indicated - filter out ads. The DNS servers recommended by those organizations supporting data privacy and net freedom have especially no-logging and no-filtering in mind - to my knowledge, ad-blocking DNS are mostly operated by commercial companies who in parallel are interested to sell their solutions. Different from the hosts file, which can be viewed by everybody, the filtering of such an ad-blocking DNS is not necessarily transparent. Maybe you have some DNS to recommend, which would address those concerns?
Further - some public WiFi / Hotel WiFI etc. have "funny" setups enforcing their specific DNS, which you can't really circumvent. The hosts file still works under those conditions . . .
Also, web sites fighting against ad-blockers are quite good in doing so if you use browser add-ins, but they mostly still work with an ad-blocking hosts file.
There's a blank reserve partition on the device. This partition is used for storing dm-verity metadata and the crypto footer but
Op3 doesn't use this partition to store the metadata
The crypto footer is the last 16 kib of the userdata partition
By spec the FRP bit is the last byte on the config partition on the op3. You can take that code as an example and use it to write a value out the the reserve partition which can then be read by the ROM installer
Backuptool is actually disabled by default. It is only shipped if the --backup=true argument is supplied to ota_from_target_files.py
Look for a commit "releasetools: squash backuptool support" in build/make or grep for "backup=true" in build
Webview discussion will be added in the next post I write
Actually that's quite a bad idea. Let us say you do define a DNS. A DNS server is as secure as your entropy source can be but if you're running on a vhost or some VPS you're not going to really have great entropy. The only way to make it secure would be to run a private DNS server yourself
True, you could buy a dedicated server, use Intel's probably backdoored entropy generator and mix it with haveged to get an almost random source but I'd leave that up to you
For DNS i just have a general rule:
"Any public-facing DNS server is inherently insecure"
I don't really care what you think about this. It's just my opinion and that's it
While I'm at it here's my DNS server configuration
#list of Root DNS Server
#Respond to DNS requests on all interfaces
#Authorized IPs to access the DNS Server
access-control: 0.0.0.0/0 allow
access-control: 127.0.0.1 allow
access-control: ::/0 allow
# Hide DNS Server info
#Limit DNS Fraud and use DNSSEC
#Add an unwanted reply threshold to clean the cache and avoid when possible a DNS Poisoning
#Minimum lifetime of cache entries in seconds
#Maximum lifetime of cached entries
This is a configuration file for unbound
This was taken from an archlinux machine. You'll have to read your distribution's docs before you use it
It enables all the security features cloudflare and Google employ and enables a few more
A good entropy source is a must for running a DNS server
---------- Post added at 23:12 ---------- Previous post was at 23:04 ----------
Originally Posted by MSe1969
Yes, you can. The delivered microG apk files have the F-Droid keys. And Bromite uses an own F-Droid repo, so obviously the same keys as the apks to download from Bromite.org (where I get them as well).
No additional modifications related to any feature of the ROM, so you can use a different kernel, if you like. Of course, I can't assure you that you won't have issues and I can't give you any support, but I think that should be clear anyhow.
Short answer: Still for a longer while
Long answer: I have started to test building Pie and bring the features of this ROM to a pie build. Besides this by far not finished yet, I have some significant issues right now with microG and coarse location: Sometimes it works, sometimes it does not work - have seen also similar issues raised by other OP3T users using the "official" lineage-16.0 microG ROM to the GMSCore repo of microG, but no clear indication yet. Have so far not come close to the issue (ok, did also not spend time with that recently) - don't know whether related, but the weather widget is also frozen in those cases and the lineage-15.1 fix to remove the unnecessary wake-lock did not help here . . .
If someone reading this has an idea, I will be grateful for any hint - @anupritaisno1 : maybe you have any idea? You are building pie already for the OP3T . . .
Actually glassrom has a very liberal stance on this and doesn't force the user to stay with any single configuration. You can boot without gapps, use microg and still use chrome's proprietary webview as a user app or you can just install the bromite webview to the system yourself
You can flash whatever gapps and so on
In other words there's no single "correct" way to use glassrom. Users often decide what they want and surprisingly few users actually use microg
I have these users:
Users who flash gapps (that includes me)
Users who don't flash gapps at all
However I don't know of anyone who's using microg on glassrom. Yes there is streetwalrus who added the microg support commits to glassrom but he does his own private builds and uses an op2 so I only know that the feature itself works but nobody really has used it on the op3, at least on glassrom that is
So I'm sorry about that. I cannot answer this question
In my testing GPS was fine but that was with the opengapps stock package
---------- Post added at 23:16 ---------- Previous post was at 23:12 ----------
Originally Posted by Jonny5isalivetm
There is no error it restores all fine, but bootloops before it reaches the lineage logo
After the bootloop immediately go to TWRP and copy all files in /sys/fs/pstore
Note that during bootloops there's often a fair bit of memory corruption going on too so you might have to reproduce the bootloop at least 3 times and collect 3 unique logs
While these logs usually do not contain any personally identifiable information it is best to submit these in private
---------- Post added at 23:32 ---------- Previous post was at 23:16 ----------
Another addition: do not edit the global updater-script unless you have a proper reason to do so
Example commit: https://github.com/GlassROM/android_...78d4fd1e71cc09
You should instead edit releasetools.py in your device tree and only make changes to this file if absolutely required