Orders of magnitude larger scale operation. BTW, Micay regularly complains about them… I agree their fundraising model is semi-good: they sell phones (for high markup), and sell hotspots memberships.
eelo aka e
From what I’ve observed, their first and last priority are on making money for Duval and associates, and they are “snake oil” salespeople…but yes, they have “front” mailing addresses, and bank transfers you can use to pay “donations” or pay for-profit shell companies for overpriced phones and cloud services. They should not be mentioned in this thread. Please start a different thread if you wish to keep spamming their names.
Everything you don’t want to hear is spam for you. Think outside the box for once …
When one person tells you some of your posts look like spamming, maybe it is misunderstanding. When two people tell you this same thing, you should consider “changing your status quo”. When three people tell you your tone is demanding or annoying, it is becoming a movement. But go ahead, keep responding like an ass in kindergarten.
There is definitely no hardware error on two devices LG G3 INTL d855 3/32 GB + 2/16GB, because Bluetooth works with Stock Android 6.0.x, /e/OS-R, LineageOS 18.1 and LineageOS-18.1-for-mircoG - only with DOS 18.1 Bluetooth cannot be activated.
When the DOS 18.1 system boots, Bluetooth is turned off, even if it was previously turned on in stock Android 6.0.x. If Bluetooth is turned on, the two centered dots to the left and right of the Bluetooth icon move and the additional text “Turning on…” is displayed, but nothing happens - except that Bluetooth is not activated and no connections can be made. This process is repeated in the DivestOS 18.1 builds September and October 2021.
As a result, DivestOS 18.1 was replaced with LineageOS-18.1-for-mircoG, and - Bluetooth is enabled and ready to use immediately after the first system boot.
Bluetooth is indispensable. Can this DivestOS 18.1 bug be fixed immediately?
Making a ‘logcat’ is no longer possible, because I already installed LOS 18.1 and /e/OS-R once on both devices before the message. With a possibly next time I’ll try to remember to make a logcat.
Hey devs, really nice to see a custom security and privacy focused ROM - especially in a time when android moddability and general security and privacy are diminishing. A few questions -
1.What does it mean when the devices page says “Verified Boot: Yes”, but then also that the bootloader cannot be locked(with DivestOS installed)? As far as i know, for verified boot, bootloader needs to be locked.
How were builds made for a specific device without testing the builds on it? Does untested mean only previous builds were tested? If so, then if no one (including the maintainer) is testing the newer builds, why and how are they maintained?
(Not directly related to divestos, but dont really know of a better place to ask) Message (that i sent) logs from a linux distro for smartphones - the message relates to android verity, and it was only later I realised that the message probably didnt fit in that channel? The second message kisted below is the questions, with the other messages for additional context. Btw, is there an irc bridge for the divestos xmpp?
2021-10-25 19:46:21 mrbean_ does this imply that flashing a vbmeta that isnt empty doesnt disable avb?
2021-10-25 19:47:17 mrbean_ which could mean that avb for custom roms can be used without needing avb v2 for that device?
2021-10-25 19:51:02 mrbean_ this could mean that pmos could also leverage this - creating vbmeta with chechecksums of system binaries ( for example, that binaries that handle decryption of data). system binaries could be flashed on a different partition to make this happen
Ignore question formatting - questions 2 & 3 appear at an indent to question 1, but idk how to fix it lol.
@fossys
The issue with Bluetooth appears to go deep.
I can reproduce non-working BT on my d852, but it is not a denial.
On these older LGE devices the MAC addresses are just stored in /misc.
During boot Lineage copies it to /persist and then to /data/misc, from where the system then reads it.
However hwaddrs notably violates the default SELinux policy via neverallow on -user, which I patched long ago.
It however seems that hwaddrs doesn’t even launch, as I altered it to always generate a new MAC and it was still unavailable.
hwaddrs has always been a headache both for Lineage and myself.
I will mark it on the site and need to dig deeper.
Yes, bootloader must be locked for verified boot to be enforcing. For devices that are marked as can’t be locked and have verified boot marked as supported it likely can’t be used. There is a small selection of devices where they allow locking with test-keys, but that is a bit silly.
Untested means never tested. Tested means I tested it or got a report of it being tested. Just one report, not all builds are tested. For the devices I have, I do test them nearly every release. For others, I wait until someone reports any issue.
My current testing roster:
14.1: toroplus, and sometimes grouper (nand is failing)
With respect to 3, the vbmeta contains checksums of partitions. My guess was that if we flashed a vbmeta with the checksums of modified partititons, verity could work.
@m1k
Latest osprey build likely fixes your previously reported issues.
clark/osprey/surnia all keep the firmware stored compressed and need to be uncompressed.
The selinux denials preventing the firmware script from working have been resolved.
Due to it being a recovery change you either need to flash the latest recovery first or flash the update twice.
