• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[ROM][SDCLANG-6][microg ready][OMS exPosures]NLOS-16.0] - 20210916

Search This thread
Yes. But you can't update from f-droid. You need to manually download, manualy generate a arm/arm64 multilib package and follow the bromite instructions for replacing the rom-shipped webview - it's easier to build an updated rom... ;)
Sorry, but I am afraid, that I have to object here:
The Bromite repo is "plugged in" as external repo and the apk uses Bromite's signature (it is not signed with F-Droid's signature), so if you use the prebuilts from Bromite, as I do in my repository, or you directly download from bromite.org, it works w/o issue.
The instruction to replace webview assumes, that you don't have Bromite, yet - but updating works w/o issues.
However, I don't recommend it and advise to wait for the ROM update, otherwise, you may need to uninstall the update before flashing the new ROM to avoid issues caused by the new ROM's apk being newer than your installed update on the /data partition.
 
  • Like
Reactions: nvertigo67

nvertigo67

Senior Member
Dec 28, 2011
6,008
12,321
Sorry, but I am afraid, that I have to object here:
The Bromite repo is "plugged in" as external repo and the apk uses Bromite's signature (it is not signed with F-Droid's signature), so if you use the prebuilts from Bromite, as I do in my repository, or you directly download from bromite.org,

To my understanding you can only use the original bromite signature with the original apk files. But since your Makefile mangles the arm, arm64 and x86 original files in a new multiarch apk, this new file can't be signed with bromites original key (as long as you don't have access to the private part of the key, of course). To my understanding keeping the original key with "LOCAL_CERTIFICATE := PRESIGNED" does only work for unchanged apks and jars, but I may be wrong.
 
  • Like
Reactions: thomasnsr
To my understanding you can only use the original bromite signature with the original apk files. But since your Makefile mangles the arm, arm64 and x86 original files in a new multiarch apk, this new file can't be signed with bromites original key (as long as you don't have access to the private part of the key, of course). To my understanding keeping the original key with "LOCAL_CERTIFICATE := PRESIGNED" does only work for unchanged apks and jars, but I may be wrong.
My repo in fact does use the original apks. In fact, it does exactly the same as the LineageOS or also AOSP makefile:
It checks, for which architecture the ROM is built to use the fitting prebuilt apk, that's all. In other words, it simply does the following:
arm (32bit)? => take the arm prebuilt as is
arm64? => take the arm64 prebuilt as is
x86 (emulator)? => take the x86 prebuilt as is

Edit: When I was still on 16.0, I even used the F-Droid repo to update Bromite myself. (Did not like however to waste another 70MB of space and as indicated before, not ideal if the shipped prebuilt of an updated ROM is newer than the "update" in /data)
 
Last edited:
  • Like
Reactions: nvertigo67

nvertigo67

Senior Member
Dec 28, 2011
6,008
12,321
My repo in fact does use the original apks. In fact, it does exactly the same as the LineageOS or also AOSP makefile:
It checks, for which architecture the ROM is built to use the fitting prebuilt apk, that's all. In other words, it simply does the following:
arm (32bit)? => take the arm prebuilt as is
arm64? => take the arm64 prebuilt as is
x86 (emulator)? => take the x86 prebuilt as is

Just used your repo (but it's the same for los and aosp webvoew repos - and mine for that matter). Indeed the x86 is not used - but:
Code:
[email protected] /usr/local/src/los16 $ diff external/bromite-webview/prebuilt/arm64/SystemWebView.apk out/target/product/oneplus3/system/product/app/webview/webview.apk
Binärdateien external/bromite-webview/prebuilt/arm64/SystemWebView.apk und out/target/product/oneplus3/system/product/app/webview/webview.apk sind verschieden.
[email protected] /usr/local/src/los16 $ ls -la external/bromite-webview/prebuilt/arm64/SystemWebView.apk out/target/product/oneplus3/system/product/app/webview/webview.apk
-rw-r--r-- 1 ingo ingo  85773668 13. Jun 15:21 external/bromite-webview/prebuilt/arm64/SystemWebView.apk
-rw-r--r-- 1 ingo ingo 164377064 13. Jun 18:13 out/target/product/oneplus3/system/product/app/webview/webview.apk
[email protected] /usr/local/src/los16 $ unzip -l out/target/product/oneplus3/system/product/app/webview/webview.apk|grep -v -e res/ -e assets/
Archive:  out/target/product/oneplus3/system/product/app/webview/webview.apk
  Length      Date    Time    Name
---------  ---------- -----   ----
 96212432  01-01-2009 00:00   lib/arm64-v8a/libwebviewchromium.so
 58062616  01-01-2009 00:00   lib/armeabi-v7a/libwebviewchromium.so
   502100  01-01-2009 00:00   resources.arsc
    22228  01-01-2009 00:00   AndroidManifest.xml
  1775416  01-01-2009 00:00   classes.dex
    81272  01-01-2009 00:00   classes2.dex
    61513  01-01-2009 00:00   META-INF/CERT.SF
     1722  01-01-2009 00:00   META-INF/CERT.RSA
    61378  01-01-2009 00:00   META-INF/MANIFEST.MF
---------                     -------
165486167                     532 files
[email protected] /usr/local/src/los16 $

Conclusions:
  1. The source file for arm64 and the resulting file in the rom arn't the same.
  2. arm and arm64 apks are combined in the resulting apk in the rom.
  3. since the rom has not the original apk, the signature can't be left untouched, since there's no multiarch apk from bromite.
The presigned directive in a makefile generating a multiarch apk from two (or more) single arch apks doesn't make sense to me.

As you stated correctly, the presigned directive only makes sense if the source prebuilts are untouched.

EDIT:
Code:
[email protected] /usr/local/src/los16 $ jarsigner -verify -verbose -certs out/target/product/oneplus3/system/product/app/webview/webview.apk|grep "Signed by"
- Signed by "EMAILADDRESS[email protected], CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US"
[email protected] /usr/local/src/los16 $ jarsigner -verify -verbose -certs external/bromite-webview/prebuilt/arm64/SystemWebView.apk|grep "Signed by"
- Signed by "CN=csagan5, OU=Bromite, O=Bromite, L=Berlin, ST=Unknown, C=DE"
[email protected] /usr/local/src/los16 $
 
Last edited:
Just used your repo (but it's the same for los and aosp webvoew repos - and mine for that matter). Indeed the x86 is not used - but:

Conclusions:

  1. The source file for arm64 and the resulting file in the rom arn't the same.
  2. arm and arm64 apks are combined in the resulting apk in the rom.
  3. since the rom has not the original apk, the signature can't be left untouched, since there's no multiarch apk from bromite.
The presigned directive in a makefile generating a multiarch apk from two (or more) single arch apks doesn't make sense to me.

As you stated correctly, the presigned directive only makes sense if the source prebuilts are untouched.

EDIT:
Code:
[email protected] /usr/local/src/los16 $ jarsigner -verify -verbose -certs out/target/product/oneplus3/system/product/app/webview/webview.apk|grep "Signed by"
- Signed by "[email protected], CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US"
[email protected] /usr/local/src/los16 $ jarsigner -verify -verbose -certs external/bromite-webview/prebuilt/arm64/SystemWebView.apk|grep "Signed by"
- Signed by "CN=csagan5, OU=Bromite, O=Bromite, L=Berlin, ST=Unknown, C=DE"
[email protected] /usr/local/src/los16 $

As I don't build Lineage 16.0 any longer for the OP3T, I have used a 64bit Lineage 16.0 treble system.img, which I have mounted for the demo purpose. This is to illustrate, what I get and as it also is 64bit arm, that should not make any difference. I did not use my LIneage 17.1 build, because Android 10 'odexes' all system apps, and I wanted something truly comparable:

Code:
[email protected]:~/android/lin-16.0$ unzip -l external/bromite-webview/prebuilt/arm64/SystemWebView.apk | grep -v -e res/ -e assets
Archive:  external/bromite-webview/prebuilt/arm64/SystemWebView.apk
  Length      Date    Time    Name
---------  ---------- -----   ----
    22388  2001-01-01 00:00   AndroidManifest.xml
  1811892  2001-01-01 00:00   classes.dex
    82432  2001-01-01 00:00   classes2.dex
     4584  2001-01-01 00:00   lib/arm64-v8a/libcrashpad_handler_trampoline.so
112048280  2001-01-01 00:00   lib/arm64-v8a/libwebviewchromium.so
     3132  2001-01-01 00:00   lib/armeabi-v7a/libcrashpad_handler_trampoline.so
 62523424  2001-01-01 00:00   lib/armeabi-v7a/libwebviewchromium.so
   503540  2001-01-01 00:00   resources.arsc
    51721  2001-01-01 00:00   META-INF/BROMITEK.SF
     1346  2001-01-01 00:00   META-INF/BROMITEK.RSA
    51616  2001-01-01 00:00   META-INF/MANIFEST.MF
---------                     -------
185776285                     535 files
[email protected]:~/android/lin-16.0$ unzip -l ../BUILT/system/app/bromite-webview/bromite-webview.apk | grep -v -e res/ -e assets
Archive:  ../BUILT/system/app/bromite-webview/bromite-webview.apk
  Length      Date    Time    Name
---------  ---------- -----   ----
    22388  2001-01-01 00:00   AndroidManifest.xml
  1811892  2001-01-01 00:00   classes.dex
    82432  2001-01-01 00:00   classes2.dex
   503540  2001-01-01 00:00   resources.arsc
    51721  2001-01-01 00:00   META-INF/BROMITEK.SF
     1346  2001-01-01 00:00   META-INF/BROMITEK.RSA
    51616  2001-01-01 00:00   META-INF/MANIFEST.MF
     4584  2001-01-01 00:00   lib/arm64-v8a/libcrashpad_handler_trampoline.so
112048280  2001-01-01 00:00   lib/arm64-v8a/libwebviewchromium.so
     3132  2001-01-01 00:00   lib/armeabi-v7a/libcrashpad_handler_trampoline.so
 62523424  2001-01-01 00:00   lib/armeabi-v7a/libwebviewchromium.so
---------                     -------
185776285                     535 files

Conclusion:
The 64-bit arm prebuilt already includes the 32-bit library, it is not merged or rebuilt in the process.
But yes, "something happens" when the Makefile is processed, as the apk files differ and the sequence of listed files has changed.
And the resulting bromite-webview.apk in my treble build keeps the Bromite signature:
Code:
[email protected]:~/android/BUILT$ jarsigner -verify system/app/bromite-webview/bromite-webview.apk -verbose | grep "Signed by"
- Signed by "CN=csagan5, OU=Bromite, O=Bromite, L=Berlin, ST=Unknown, C=DE"

Did you use my repo "as is" (see README) or did you alter anything in your local clone?
 
  • Like
Reactions: nvertigo67

nvertigo67

Senior Member
Dec 28, 2011
6,008
12,321
Did you use my repo "as is" (see README) or did you alter anything in your local clone?
When I've used the term "used your repo", I did this:

I've not the slightest clue how/why an altered file can keep it's signature - the main purpose of a signature is to prove that the file is not altered and it's from the signer... :(
 

nvertigo67

Senior Member
Dec 28, 2011
6,008
12,321
Build 20210620

Releasenotes:

This build relies on OxygenOS firmware. OxygenOS 9.0.6 firmware is required. At this point you have two options:
  1. You don't care about loosing data on an unlocked bootloader and clean flash including format userdata according to the first time installation instructions in OP (recommended):
  2. You want to keep your current setup and like to dirty flash on top of beta builds:
    I've created a firmware package from OxygenOS 9.0.6. To avoid issues due to an unlocked bootloader and/or encrypted userdata partition, I've kept the bootloader and and keymaster partition to OxygenOS 5.0.8. This allows to run the pie-blobs builds with native Oneplus OxygenOS 9.0.6 firmware, but you don't need to reformat the userdata partition (for details see: https://forum.xda-developers.com/oneplus-3t/how-to/guide-cope-9-0-3-5-0-8-firmware-barrier-t3941164).
If you need to pass safetynet api flash sec-patch-2019-08-01_v02.zip from https://forum.xda-developers.com/on...-nlos-16-0-t3879405/post78433987#post78433987 .
Before you ask: though I've updated the blobs used in the rom to OOS 9.0.6, I've decided to stick with OOS 9.0.5 build fimgerprint, because 9.0.5 is the only version with identical fingerprint strings for op3 and op3t.

If you want to use Alipay with fingerprint authentication, follow @Galiis' directions in posting #6.

For a complete list of additional cherry picks see: current.pick.sh.

Changelog (Last repo sync: 20 Jun 2021, 08:27:07 CEST / 20 Jun 2021, 06:27:07 UTC):

  • nlos.xml: add Bromite System Webvoew from MSe1969's repo. — Nvertigo
  • nlos.mk: use Bromite System Webvoew from MSe1969's repo. — Nvertigo
  • kernel: patches mentioned in https://source.android.com/security/bulletin/2021-06-01?hl=en(ASB 2021 06):
    • qcacld-2.0: Add eapol checking for intra-bss fwd & indicate in IPA exc path — Tiger Yu
    • qcacld-2.0: Add eapol sanity checking for intra-bss forwarding & indicate — Lihua Liu
    • qcacld-2.0: Drop mcast and plaintext frags in protected network — Tiger Yu
    • qcacld-2.0: Discard frag frames if the PN is not consecutive — Tiger Yu
    • qcacld-2.0: Flush RX packets for peer after key installation — Tiger Yu
    • qcacld-2.0: Initialize preauth node — Liangwei Dong
    • qcacld-2.0: Fix SAP data tx block issue — Brandon Huang
    • qcacld-2.0: Fix a compile error — lihual
    • crypto: Fix possible stack out of bound error — Tanwee Kausar
    • HID: make arrays usage and value to be the same — Will McVicker
  • WG: squash WireGuard-linux-compat-1.0.20210606. — Nvertigo
  • Patch up: P_asb_2021-05. — Nvertigo

NLOS-Bootlogo
nlos_bootlogo-v0.1.zip
back_in_black_bootlogo-v1.0.zip(pre ob16 OxygenOS Bootlogo)


[SIZE="+2"]DOWNLOAD[/SIZE]​

Happy flashing!
 

nvertigo67

Senior Member
Dec 28, 2011
6,008
12,321
Build 20210714

Releasenotes:

If ypu've updated bromite system webview from F-Droid, remove the update in Settings->Apps & notifications - if you fail/forget/etc to do so, delete /data/app/*bromite-webview* from twrp.

This build relies on OxygenOS firmware. OxygenOS 9.0.6 firmware is required. At this point you have two options:
  1. You don't care about loosing data on an unlocked bootloader and clean flash including format userdata according to the first time installation instructions in OP (recommended):
  2. You want to keep your current setup and like to dirty flash on top of beta builds:
    I've created a firmware package from OxygenOS 9.0.6. To avoid issues due to an unlocked bootloader and/or encrypted userdata partition, I've kept the bootloader and and keymaster partition to OxygenOS 5.0.8. This allows to run the pie-blobs builds with native Oneplus OxygenOS 9.0.6 firmware, but you don't need to reformat the userdata partition (for details see: https://forum.xda-developers.com/oneplus-3t/how-to/guide-cope-9-0-3-5-0-8-firmware-barrier-t3941164).
If you need to pass safetynet api flash sec-patch-2019-08-01_v02.zip from https://forum.xda-developers.com/on...-nlos-16-0-t3879405/post78433987#post78433987 .
Before you ask: though I've updated the blobs used in the rom to OOS 9.0.6, I've decided to stick with OOS 9.0.5 build fimgerprint, because 9.0.5 is the only version with identical fingerprint strings for op3 and op3t.

If you want to use Alipay with fingerprint authentication, follow @Galiis' directions in posting #6.

For a complete list of additional cherry picks see: current.pick.sh.

Changelog (Last repo sync: 14 Jul 2021, 15:39:59 CEST / 14 Jul 2021, 13:39:59 UTC):

  • my_build.sh: remove jack-server hanling; update mktemp call. — Nvertigo
  • Patch up: P_asb_2021-07. — Nvertigo
  • Revert "nlos.xml: add Bromite System Webvoew from MSe1969's repo." — Nvertigo (Thanx @MSe1969
  • kernel: patches mentioned in https://source.android.com/security/bulletin/2021-07-01?hl=en(ASB 2021 07):
    • qcacld-2.0: Send assoc reject upon failing to post ASSOC_IND — Paul Zhang
  • WG: squash WireGuard-linux-compat-1.0.20210606. — Nvertigo
  • Patch up: P_asb_2021-05. — Nvertigo

NLOS-Bootlogo
nlos_bootlogo-v0.1.zip
back_in_black_bootlogo-v1.0.zip(pre ob16 OxygenOS Bootlogo)


[SIZE="+2"]DOWNLOAD[/SIZE]​

Happy flashing!
 

nvertigo67

Senior Member
Dec 28, 2011
6,008
12,321
Does anybody need the wireguard kernel mode?

Background: I can't use my device rooted currently (my banking app detects magisk though hide is configured correctly); this implies I can't check, test or debug wireguard kernel mode before shipping.

Since wireguard userspace mode works without root, I'd like to drop wireguard kernel mode. lf somebody really needs wireguard kernel mode, I'm going to ship the rom with the kernel patches, but without testing, debugging and support.
 
  • Like
Reactions: thomasnsr

nvertigo67

Senior Member
Dec 28, 2011
6,008
12,321

Top Liked Posts