DivestOS: long term device support with enhanced privacy and security

Well, I understand that as a minor deviation from your own installation instructions, which specify flashing the avb_custom_key only after¹ initial setup.

Locking

  1. After¹ install of a properly signed system you must verify boot, verify functionality, verify update support, and verify the ability to factory reset.
  2. Reboot to the bootloader via key combination or $ adb reboot bootloader
  3. AVB devices only: $ fastboot erase avb_custom_key
  4. AVB devices only: $ fastboot flash avb_custom_key avb_pkmd.bin
  5. $ fastboot oem lock or $ fastboot flashing lock
  6. It is recommended to keep ‘Allow OEM unlocking’ checked under ‘Developer options’ in Settings for recovery purposes.

Whether this has a decisive effect remains to be seen. I will try both variants.

Samsung Galaxy S II (i9100)

DOS build divested-14.1-20210909-dos-i9100.zip

I tried a total of five custom ROMs for the S II, the first four of them successfully: LOS 16.0 / 9.0 / Pie | LOS 17.1 / 10.0 / Q | LOS 18.1 / 11.0 / R, /e/OS-p (16.0 / 9.0 / Pie) and DivestOS 14.1 / 7.1.2 / Nougat.

The maintainers of the first four ROMs point out that pre-installing PIT : i9100-LOS-16.0-Emulated-Storage.pit is mandatory. The installation instructions of DOS aka LineageOS Wiki don’t talk about this.

Starting point for the (not successful) test of DivestOS 14.1 / 7.1.2 / Nougat was the successful installation of 9100-LOS-16.0-Emulated-Storage.pit as well as i9100-LOS-16.0-Emulated-Storage-TWRP-3.3.1-1 together with /e/OS e-0.14-p-20201217-UNOFFICIAL-i9100.zip

In TWRP 3.3.1-1 I’ve executed: → Format Data → Type [yes] → Davik / ART Cache → Cache → System → Non-emulated Storage → Swipe to Wipe. Then followed via adb sideload divested-14.1-20210909-dos-i9100.zip

After reboot to system the DivestOS ROM gets stuck in the animated multicolored DOS logo - a bootloop is the result. Back to TWRP and a factory reset - did not remove the bootloop either.

Pictures

Will the bootloop be caused by PIT : i9100-LOS-16.0-Emulated-Storage.pit ? Will a successful installation DOS 14.1 succeed with a starting point Stock Android 4.1.2 “Jelly Bean”, i.e. without PIT : i9100-LOS-16.0-Emulated-Storage.pit?

flashing the avb_custom_key only after¹ initial setup.

I will update this

i9100 DivestOS ROM gets stuck in the animated multicolored DOS logo

I do not have this device, and do not know what is required to install it.
But I do know there are active updater checks to my server from i9100 devices and there is even a video about it here: https://www.youtube.com/watch?v=HvzUeDoG_J0

Yeah, this video manufacturer is known to me from other performances. He has already presented numerous ROMs.

Can you please give me a downlink for the DivestOS version 14.1-20210806-dos-9100 he uses?!


Update 10.09.2021 - 05:25 PM

I had forgotten that I had already downloaded the DOS build divested-14.1-20210806-dos-i9100.zip AND divested-14.1-20210806-dos-i9100-recovery.img . This way I can start a new installation with the August 2021 build and update to the September version if necessary. Before that, I’ll use the original LineageOS 14.1.

Can you please give me a downlink

I do not keep old builds. And there have only been a very small handful of tested changes to the 14.1 branch. I strongly doubt any breakage between the two builds.

There are numerous installation notes with various customizations of stock kernel, TWRP and i9100-1GBsystem-6GBdata.pit Only it remains: LineageOS Wiki mentions nothing about this being necessary.

Now I’ve downloaded one of the last, if not the last official ROM of lineage-14.1-20181216-nightly-i9100-signed. At the next opportunity, I’ll freshly set up Stock Android 4.1.2 and install it according to the LOS-Wiki and then move on to DOS 14.1.

Attempting to track multiple issues, all crammed into this single topic, is unwieldy. Using desktop firefox, the forum hijacks the browser’s “Ctrl+F” find functionality and does not colorize to highlight the found search term. Similarly (crammed) in this forum we are apparently relegated to composing all-in-one posts rather than separate, back-to-back, posts when hoping to respond to multiple unrelated comments.

Please consider creation of a r/DivestOS subreddit, to serve as a multi-topic meetingplace.


a point of wonderment:
Although DivestOS provides extensive and well-written documentation, the project has received scant mention within the xda-developers forum (and elsewhere). Does the project not seek to expand its userbase? It “is what it is” the status quo is fine, as is?

Perusing the various DivestOS git project repositories, I did not find a single (open, nor closed) merge request. This detail suggests (to me) that the status quo is non-ideal but maybe the plan has been to remain the best-kept secret among the current custom ROMs?

In recent months, CalyxOS has received attention (has been “hailed by the media, and mentioned across various forums”) yet DivestOS has not. Also /e/ ~~ and, yes, I noticed the topic discussing DivestOS within the /e/ forum was “shut down, hard” (automagically closed after 26 days “is a thing”?)

As a point of reference, I’ll mention that I am a long-time (C, perl, python, yaddayadda) linux developer, but am a greenhorn in the AOSP realm ~~ and haven’t touched java since way-back-when (around the time the “Swing” toolkit [aka “AWT”?] was introduced).

The factionalization among the AOSP -derived (er, LineageOS -derived) projects seems quite crippling. LineageOS doesn’t celebrate its child forks? They (NIH) refuse to embrace attempted contributions, e.g. DivestOS kernel exploit patcher, from downstream?

I would hope to contribute to DivestOS development (or at least contribute toward expanding its already excellent documentation) but here’s a point of reservation: Is “help” really welcome? Tad’s (often self-proclaimed “overly opinionated”) postings to various discussions seems to suggest “it’s my way, or the highway”. That’s fine by me – in other words, if “its development is not intended to be a community endeavor” I can respect that decision – so, in advance, I’m asking: would DivestOS celebrate, cooperate with, and welcome selective contribs from a potential [rebranded] child fork?

Frankly, I wouldn’t shoulder the burden of personally maintaining a rebranded fork. For me, a custom self-build will suffice. However, I sense that such a fork will be, or already is, necessary. The wants/needs of the users, and prospective users, seem to be misaligned with the status quo featureset proffered by the project. In my case, as a prospective user, the misalignment involves attention toward favoring privacy (anti-exfiltration via network) -centric features over hardline BestestPractices security-centric features.

Please consider creation of a r/DivestOS subreddit, to serve as a multi-topic meetingplace.

I have been banned twice from Reddit in attempt to respond to people asking about DivestOS on there.
Among other reasons, I will not give anymore of my time to such a malicious website.

Does the project not seek to expand its userbase?
has received attention … yet DivestOS has not

I emailed many a people, posted to many a forum, talked in many a chat room. It is not enough. Users need to share their enjoyment for it more.

/e/ “shut down, hard”

Questionable. But I’m not gonna start drama there.

The factionalization among the AOSP -derived

I really do wish there was more collaboration in this area. Too much is siloed as it stands.

LineageOS … refuse to embrace attempted contributions

Some of the Lineage members happily respond to my emails, others ignore me.
Of extra note they only accept direct contributions via Gerrit which requires a Google account to sign-in.

kernel exploit patcher

I have little insight on their discussions about this, but was sorely disappointed.

Is “help” really welcome?

Yes. I would greatly appreciate help in any way you can spare, but do not feel obligated.

opinionated

I wouldn’t be here making this stuff if I wasn’t :stuck_out_tongue:.
I do believe a lot of things in this area have few right ways, and most people are used to doing things not the right way due to being “trained” by other ROMs or general misinformation available on the various forums.

People insist on having root and neglecting the downsides for benefits that can be achieved without it. People think that relocking == instant brick. I mean /r/fossdroid regularly recommends proprietary apps. I’ve seen people say “Android has no sandboxing, only GrapheneOS does”.

potential [rebranded] child fork

You are welcome to fork and I’ll be happy to merge in any suitable patches that you’d like to upstream.
Rebranding is also trivial, see this.

misalignment involves attention toward favoring privacy-centric features over hardline BestestPractices security-centric features.

Can you elaborate on this?

For what it is worth DivestOS does not have the goal of being 99% free or 99% private or 99% secure. It aims to provide longer support lifetimes with more security and more privacy where not completely impacting usability.
I try to ensure that you can put DivestOS on a device and give it to your mum and also be happy to run it yourself.

I also have absolutely no intent on venturing into the land of things like IMEI changing.

Motorola Moto G 2015

DOS build divested-17.1-20210806-dos-osprey.zip

Hello!
I’ve flashed
Moto G 2015 XT1541 (8Gb storage, 1Gb memory)
with the divested-17.1-20210806-dos-osprey-recovery.img, reseted the phone and then sideloaded the aforementioned build image.

Moto G 2015 experiences bootlooping with divestOS animation appearing from time to time. I can press volume buttons and sometimes it’ll result in volume slider movements, but the phone just won’t boot.

Lineage OS (microG) and e/os/ with appropriate recoveries load, boot and seems to work fine for the time being (not both at once, of course).

Best regards,
m1k.

Motorola Moto G 2015

DOS build divested-17.1-20210912-dos-osprey.zip

The build boots!

And mostly works.
Moto G 2015 XT1541 having 1Gb of memory works okay with apps like:

  • AnkiDroid
  • Tor Browser
  • Bromite
  • Mull

so far.

Though
no sound is present on the device,
newpipe won’t play videos (though videos can be played in either a web browser or video player like mpv),
orbot will get stuck at “reloading keys” actions when VPN mode is on (for, say f-droid and system updater).

Some logs were made with Logcat command-line tool and f-droid | Logcat


MOTO_G_2015_logs_20210913.zip (156.1 KB)

1 Like

@m1k
Glad to hear.
Strange that the other didn’t boot.
I don’t recall changing anything that would affect it.

Orbot can be a chore to get started sometimes. Play around with it a few minutes via force stop or exit (the results seem to change).
Also try the latest from here Release Orbot 16.5.1-BETA-2a-tor.0.4.5.9 · guardianproject/orbot · GitHub

I will go through your logs and see if anything jumps out.

Edit 2:
I have fixed this issue:

Key google_analytics_ssaid_collection_enabled expected String but value was a java.lang.Boolean.  The default value <null> was returned.

Edit:
Was this a fresh install?
And audio works under official LineageOS 17.1?

Any news for OP 7 pro devices? I see that status is still broken.

@Cotillion

OnePlus 7

I do not have one, nor can I currently afford to acquire one.

You can try the build that is going up soon, and see if anything has changed.

Was this a fresh install?

Data and Cache was wiped prior to DivestOS ROM installation.
(there is no format /system option under divested-17.1-20210912-dos-osprey-recovery.img)

LineageOS 17.1 had been the previous system.

And audio works under official LineageOS 17.1?

Yes, it works through both the speaker and the 3.5mm jack.
(Worked on stock Android 6.0.1, too)

Orbot can be a chore to get started sometimes.

Orbot raises a
“NOTICE: Our IP address has changed. Rotating keys…”
whether a VPN Mode is checked
be it before or after otherwise normal start up.

Fix hamper analytics patches (a9f44dee) · Commits · DivestOS Mobile

Well. it’s not so obvious that obviously boolean values are to be passed as string ones.

A new installation attempt on September 12, 2021

OnePlus 6 (enchilada)

DOS build divested-18.1-20210814-dos-enchilada

The starting point for another test with OnePlus6 and DOS was a completely fresh installation of OxygenOS 10.3.6, then upgrading to OxygenOS 11.0.0 22.J.60 Build A6003 22 210805.

Unlocking the bootloader was done in less than a minute: adb reboot bootloader > fastboot devices > fastboot flashing unlock. Registration was not necessary for the European (International) model. Likewise, no waiting time and no unlock code.

For a first device check I installed LOS 18.1 lineage-recovery build lineage-18.1-20210907-recovery-enchilada.img according to the LineageOS Wiki, then via adb sideload copy-partitions-20210323_1922.zip because of A/B support and afterwards via adb sideload lineage-18.1-20210907-nightly-enchilada-signed.zip. Everything went like clockwork. The OnePlus 6 booted immediately and could be set up ready for use.

For the DivestOS installation I used the already installed Lineage-Recovery 18.1-20210907. Now tap Factory Reset, then Format data / factory reset and continue with the formatting process. Return to the main menu, I using adb sideload divested-18.1-20210814-dos-enchilada.zip. Before booting, I deleted avb_custom_key with fastboot erase and installed the AVB-key with fastboot flash avb_custom_key avb_pkmd.bin.

Immediately after I tapped “Reboot system now”, the screen went black and without any intermediate message I was shown the blue-red horror message QUALCOMM CrashDump Mode.

Picture

The heart-stopping circumstance for me this time was that I could turn off the “enchilada” but I could no longer (as before - see above) boot it into FASTBOOT mode. The reboot shows the Fastboot logo for only one second, and then immediately shows the Qualcomm CrashDump Mode again. I tried to revive the “enchilada” for well over an hour - to no avail. Frustrated, I put the phone aside, switched it off, and began to resign myself to the fact that my Oneplus 6 was hard-bricked.

Twenty minutes later, I picked up “enchilada” again to try to revive it with the device key combination Volum Up + Power. At first nothing happened and then, I couldn’t believe it at first, I saw the LineageOS boot animation. After what felt like endless seconds, but was actually only a few seconds, LineageOS 18.1 started and could be completely set up. The scenario resembled the image “like a phoenix rising from the ashes”. It was a load off my mind, which everyone can imagine.

divested-18.1-20210814-dos-enchilada

This old build didn’t contain the upstream fix I linked a few posts back.
https://review.lineageos.org/c/LineageOS/android_kernel_oneplus_sdm845/+/315208
Only Lineage (and derivative) builds after September 2nd (09/02) will boot on the OnePlus 6/T on the 11.0 firmware.

Hence why Lineage 09/07 booted just fine, but DivestOS 08/14 landed in crashdump.

The 09/13 build for enchilada along with the 09/04, 09/09, and 09/13 builds for fajita all include that patch.

This old build, the August 2021 build DivestOS 08/14 was downloadable until a few hours ago. A note about the stock ROM OOS 10 | OOS 11 problem was not given in the download area. Anyone not following this thread here knows nothing of the circumstances. Anyone who overreads the note in this thread, is himself to blame for what awaits in. After all, the motto is: Everyone is responsible for his own actions.

@fossys
Fair point, I should’ve pulled it.
I just did, and I added a note (along with the key combo you mention) to the known issues page.

@fossys post contains the only mention of NikGApps within the f-droid forum, so far.

I recently viewed the NikGApps source code repo at github and was surprised to discover that the project has a git “workflow” in place which enable you to “fork, then tweak the config, then submit a merge request” so that a CUSTOM build will be automatically performed and signed. Wow, that’s impressive!

I noticed / discovered a potential logic error within their config processing. ISTM the code presumes (does not check) that an equivalent component is present at runtime and, if the config specifies GBoard=-1 …the system could wind up without a “keyboard” app.

For me, the seemingly most appealing feature of NikGApps is/was the degree of granularity in choosing the most minimal set of “pieces” necessary for my expected usage. I had looked into (but have never used) MicroG, which similarly advertises pick-n-choose granularity via its config (to achieve a result containing less than what the “pico” MicroG would install)… but (sigh) the enumerated list of “extra_files” which one might choose to forego, it has been nulled within the NikGApps source code. Apparently exposing these to users had proven to be a “footgun” .

Bells-n-whistles. Gingerbread. I cannot understand the rationale for bundling “cannot-live-without” 3rd-party apps within the (NikGApps, same with MicroG) ROM. Sure (I checked), MiXplorer file manager is FOSS… but is unavailable via f-droid. If it truly is that great, why has no one (forked, and/or) packaged it for f-droid?

another concern (point of wonderment): NikGapps depends on busybox, installs it (from a prebuilt) if it is absent. Neither the user-facing NikGapps docs, nor the sourcecode, indicate that the system will wind up with busybox -provided “su” command.

NikGapps depends on TWRP, specifically, by name. If I have already audited and chosen to utilize SkyHawk recovery (I have not, yet)… too bad, so sad ~~ I’m relegated to prospect of auditing TWRP and its bundled//prebuilt components… or caving to the “rational ignorance” mindset of “oh SURELY it’s well-vetted”.

It’s not FOSS