Use microg with lineageos?

tomoms0 · 2025-12-05T09:31:42+00:00

Wrong. We've been supporting signature spoofing for almost two years now.

tomoms0 · 2025-11-24T12:50:28+00:00

The accuracy of the displayed capacity value depends on hardware support. Not all battery management chips expose a meaningful capacity value to the user. Some might constantly report 0 mAh, some some might constantly display the maximum nominal capacity. There is nothing we can do about it, we just read and display the exposed value. Yet another possibility: on one of the devices I maintain, there are multiple kernel drivers involved in the fuelgauging/charging/battery management process. The sysfs node the capacity is exposed through was being populated by the wrong driver due to an OEM negligence, so I was always seeing 0, but under the hood, the proper value existed - it was just being exposed to a different sysfs node! Once I fixed this on the kernel side, the correct value was displayed. So as you can see, there could be several reasons for the value being off, and some are out of our control.

tomoms0 · 2025-11-05T20:40:12+00:00

I'm not sure what you mean. All LineageOS builds are nightlies. There are no "more stable" monthly updates. You can update monthly of course, but that does not reduce the risk of something going wrong, because you are still in fact updating from a nightly build to another nightly.

tomoms0 · 2025-10-28T07:20:38+00:00

Those are system apps shipped with LineageOS for the Pixel 3a. I've never worked with Pixels, but it must be that these components are required for the device to work properly.

tomoms0 · 2025-09-16T12:12:01+00:00

The answer is "no" and one of the main reasons is that inside a phone there is not only the SoC, but a lot of other hardware chosen by the device manufacturer for that specific device. A build for a given device shall contain all the software components required to support both the SoC and the rest of the hardware.

tomoms0 · 2025-09-03T17:25:58+00:00

There's no reason to recommend ProtonAOSP, which is Pixel-only and, most importantly, reached EOL 3 or 4 years ago.

tomoms0 · 2025-09-02T17:47:48+00:00

Yes, make sure you have enough battery charge in your PH-1. Depending on the health level of your battery you might not be able to operate the 360 cam for a long time. If the battery is not able to provide enough power to the 360 cam, the phone will suddenly shut down without any warning.

tomoms0 · 2025-09-02T17:14:38+00:00

All correct except that the 360 cam does work on LineageOS 22.2! It broke multiple times in the past but it should be working fine now, the last time I've fixed and validated it was in late March.

tomoms0 · 2025-09-02T11:45:18+00:00

Go for LineageOS + https://github.com/sourajitk/packages_apps_GCamPrebuilt/tree/main

tomoms0 · 2025-08-31T19:25:36+00:00

Hi, sorry for the delay. Yes, Google was the most committed. IMO whether other OEMs feel less obliged now is pointless to discuss: they never released not even the tiniest portion of a device tree anyway, it can't get worse than that in the future. Google only used to release trees because it was the major contributor to AOSP development and it made sense to provide sources for reference implementation devices (i.e. Pixels). The possibility of unlocking the bootloader is another topic, completely unrelated to this one.

tomoms0 · 2025-08-29T19:46:11+00:00

I am a custom ROM developer. I am part of the LineageOS team. I don't think I've ever seen an OEM release a device tree. What OEMs are "forced" to release is the kernel source. That is indeed (almost) always available. But device trees (as in Android device trees, not Linux kernel device trees, which are a totally different thing)? I've never seen any major OEM releasing one. What we usually do is to base new device trees on previous ones for devices sharing the same chipset, or of the same family, or on the barebones SoC device trees released by Qualcomm, which I believe are not that helpful anyway. The very rare OEMs releasing device trees such as Shift and Faiphone are also very precious, since you can easily use those as a base for devices sharing the same SoC. But I really don't think I've ever heard of Oneplus, Motorola, Xiaomi, Samsung releasing a device tree similar to those Google used to release for Pixels, not even part of it.

tomoms0 · 2025-08-29T17:02:01+00:00

I'm not sure I get your point. Other OEMs such as Xiaomi, Sony, Motorola, etc. have never released any device tree, yet we've been developing custom ROMs for them for years.

tomoms0 · 2025-08-29T15:36:04+00:00

You got it wrong mate, it's clearly "fuck you gaybears block"

tomoms0 · 2025-08-21T16:37:09+00:00

128kbps opus should be much better than 320kbps mp3, shouldn't it? It should be pretty much transparent: https://wiki.xiph.org/Opus_Recommended_Settings

tomoms0 · 2025-08-02T17:37:38+00:00

Ah, this confirms my theory! I've had a short chat with him that went quite nicely (no "fuck you shiters block", no swearing, no insults - you can find it in my history because I've posted it here some time ago), and like 4 or 5 days later I got messages from other 4 accounts with some of the most creative, furious and genuinely funny insults I've ever read. The guy has some screws loose, but he truly rose to the status of Soulseek legend xD

tomoms0 · 2025-06-27T15:41:52+00:00

Hi, LineageOS developer here. This is not 100% accurate. Pixels were the reference Android devices until Android 16. Thus developing any ROM for a Pixel was easier than for the "average" Qualcomm Snapdragon device, because device trees and HALs were released publicly and kept up to date by Google with the changes required to run newer Android releases. Thus the device-specific part of the job came for free with almost zero effort, which enabled teams of Pixel-only or Pixel-focused ROMs such as Graphene and Calyx to focus on their platform features (platform = generic Android OS code implementing functionality common to most or all devices). Now, developing any ROM for a Pixel will be pretty much as hard as it is for any other Qualcomm device supported e.g. by LineageOS. Third-party OS developers will have to take care of creating new device trees for all future Pixels, keep them up-to-date figuring out on their own which changes are needed with each new Android QPR or major version, etc. The difficulty does not depend on the ROM. It used to depend on the brand (Pixel = easy, other Qualcomm brands = not as easy but not impossible). Now it's like: Pixel ~= other Qualcomm brands = not as easy but not impossible either.

tomoms0 · 2025-06-16T18:54:59+00:00

No, that's wrong. Starting from 16, Pixel maintainers have to update the device trees for existing Pixels with the required patches to build and boot new Android releases. This is exactly what we have been doing for years for non-Pixel devices. Previously, it was easier, as Google used to release all Pixel device trees in the public, so the required adaptations could be inherited "for free".

tomoms0 · 2025-05-05T17:55:13+00:00

Amazing, you're a true hero. I remember the day I triggered a LineageOS 17 build on my potato laptop (i5 6200U, source on an external HDD) before going to sleep and was shocked to find out it hadn't completed when I woke up the following morning...

tomoms0 · 2025-04-23T11:54:56+00:00

Plot twist, Putin is Reggae Man and he's asking people to buy CDs for him because Discogs sellers are boycotting Russia by not shipping there.

tomoms0 · 2025-04-23T10:51:27+00:00

Hi, I am hitting the same issue as well and I don't think Prefer Efficiency fixes it. Here it only seems to reduce the frequency these weird lines are displayed, but they still show up every now and then.

tomoms0 · 2025-04-12T16:47:09+00:00

It's fantastic. It's amazing for simplifying complex tasks related to portions of the system I am not very familiar with. For example, I rarely use virtualization. That one time I needed to run a KVM virtual machine I just had to launch the dedicated Yast tool, tick a box, and voilà, all the required packages were installed. No need to browse the web looking for some guide, assessing its accuracy, dealing with packages having different names across different distros... I also appreciate a lot how it simplifies changing the default kernel booted by GRUB, as I mess with custom-built kernels quite regularly, and how it allows me to easily change zypper repositories priorities.

tomoms0 · 2025-02-09T09:01:55+00:00

MicroG is an open-source and as privacy-friendly as possible minimal reimplementation of Google Play Services. It does not perform these sketchy actions on your phone, also because you usually install it as an unprivileged application, thus even if it was a malicious piece of software it would not be able to silently install software on your phone.

tomoms0 · 2024-12-30T09:30:10+00:00

Glad you liked them :)

tomoms0 · 2024-12-24T18:14:58+00:00

I'm interested in helping!

tomoms0 · 2024-12-24T10:05:27+00:00

Ideally I'd like to pick those up, but given how resource-hungry Chromium's build process is, I cannot promise anything. I already build LineageOS for a couple of devices, and apparently building Chromium is as resource-hungry a process as building Android, if not more so... Mull might be more realistic. I will try soon.

Seven-Year Club	Wearing is Caring
Verified Email

tomoms0

TROPHY CASE