yashsingh1/xdaforums huggingface dataset:
[Raspberry Pi Original Development] KonstaT:
They didn't.

As I already answered you elsewhere, you would follow the implementation guide Quectel provides along with the Android RIL drivers for the specific modem hardware (that they also provide). There's also separate document for configuring/patching the Linux kernel to support their hardware.
[Raspberry Pi Original Development] jaffmanRS:
Hi, thanks for this build, I have used multiples on my RPi4 2gb its really useful for my build.

I was hoping to get some help regarding putting the pi to sleep and waking it up on status of a GPIO pin.

I've done a bit of Arduino coding before and the current setup on an Arduino Leonardo looks for a switched live and when it sees it drop low, sends a keyboard press to "press the off button" and likewise the enter button when the switched live goes high. however this doesn't seem to work consistently so I'm looking at scrapping the Arduino idea altogether and utilising the GPIO pins on the pi itself.

now I've never done any python writing so I have been entirely dependant on chatGPT to give me a brief overview of what can be done so it looks like i can get a script to run when the pi boots, to keep an eye on the GPIO pins for the switched live and start an app up. that script can then monitor the GPIO pins and sleep/wake the pi depending on the state of the switched live.

my problem is i dont know how to get to the point of actually getting the script onto the pi to be run in the first place. I think ive understood our robot overlords when they say i need to root the device to allow this? but I dont seem to have any sudo command capabilities in the terminal app i downloaded (RNX TMX). it always seems to error whenever i follow the instructions.

I do have magisk installed but to be honest that has confused me even more. so i would be grateful if anyone could guide me to the point where i can write a script to put the thing to sleep and wake it up alongside the input from the switched live.

anyone have any advice or starting points?
[Raspberry Pi Original Development] KonstaT:
Maybe you're just over complicating this a bit?

Please see the FAQ on how to create a DIY power button that will work exactly like power button on your regular Android device (short press to turn display on/off, long press to invoke power menu). Pi kernel doesn't support suspend so your device won't enter "deep sleep" in any case.

There's also a script to power down the device using GPIO (https://xdaforums.com/t/dev-rom-uno...raspberry-pi-4-b.4139059/page-6#post-83822011). You can't flash it with TWRP on Android 12/13 but you can copy the script to /vendor/etc/init.d/ (make sure to set permissions to make it executable). See previous discussion e.g. http://disq.us/p/2pxklpc. Pi has also has a bootloader level thing to power up the device from halt using GPIO3 or global and en pads (see http://disq.us/p/2rm9ps8).
[Raspberry Pi Original Development] jaffmanRS:
you may be right I feel like I'm overcomplicating it.

I suppose I better explain what I'm doing in a bit more detail, I'm using the pi to run an app called realdash to display on a 12" widescreen for an instrument cluster in my car. it all works pretty flawlessly which is why I'm so impressed with the build and the community notes that have basically made it easy to add google play etc.

the biggest issue I have is the loading times from stone cold dead to getting realdash on the screen using another app called "boot apps" is too long (circa 1 min 25 seconds) most of this time is in the lineage circles. so I have come up with a plan to have the pi on a permanent live in the car so its "always on" but controlled by a time delay relay so it turns it off after a day or so. the screen goes on and off with the switched live of the car so that isn't a problem. so I was looking to put the pi in a form of low power mode whilst the time delay relay is active but the car isn't. (hence the switched live requirement).

in theory then I could set the time delay relay to 24 hours and as long as I get in the car within that 24 hours the pi will be ready to go almost straight away, if I'm longer than 24 hours between getting in the car then I have to go through the whole boot sequence.

I have tried following the guide for a power button but it always brings up the power menu no matter how quick the press of the button is, and even then if I shut it down I have the boot time problem again.

if you can think of a better way of having the pi ready to go within a few seconds I'm all for it, but it seems I may be limited with the pi not being able to go "low power" and not being able to shave off anymore seconds from the boot sequence. if this could be achieved then it does significantly reduce the complexity of what I've got going on here

thanks for the reply
[Raspberry Pi Original Development] KonstaT:
I don't think there's any quick/easy solution to what you're trying to achieve.

Pressing the power button doesn't save any power as it will only toggle the display off/on. Sure, you could power down the device using GPIO with the script linked previously but it just takes time to boot Android from power off. It's not possible to improve the boot time drastically as it's going to take around minute in any case.
[Raspberry Pi Original Development] gcrozatti:
Switched to this Android TV version and bluetooth pairing still doesn't work. Well, it doesn't work after install GApps. I don't know how this makes sense but it is what it is...
[Raspberry Pi Original Development] KonstaT:
Google services are not part of my releases so you would need to report it where you got the GApps package. There's been some previous reports of issues with pairing bluetooth remotes on Android TV with GApps (https://github.com/opengapps/opengapps/issues/915).
[Raspberry Pi Original Development] gcrozatti:
I got the GApps link from your FAQ (MindTheGapps)... The last release available (MindTheGapps-12.1.0-arm64-ATV-20230321_143953.zip)

Without the GApps I could pair my bluetooth remote, so I will try this rom without GApps...
[Raspberry Pi Original Development] KonstaT:
I have recommended GApps package linked on each page as it's turned out to be an overwhelming task for some to even select the right package for the build otherwise. It's still an entirely different release.

Correct place to report this would be MindTheGapps issue tracker (https://gitlab.com/groups/MindTheGapps/-/issues) with the appropriate logs of course.
[Raspberry Pi Original Development] gcrozatti:
Well... this is the link you recommended in the FAQ from https://konstakang.com/devices/rpi4/LineageOS19-ATV/

When you put the xxxxx.... I realized that could be any released version since following the "12.1.0-arm64-ATV..." version... so I didn't get when you said "It's still an entirely different release."
[Raspberry Pi Original Development] KonstaT:
It means that I don't have anything to do with MindTheGapps, OpenGApps, NikGApps, FlameGApps, BiTGApps or any other GApps release that exists out there. These are someone else's releases - not mine.
[Raspberry Pi Original Development] Smokinimages:
Is it possible to copy this and boot from a m2 board rather than an SD card?
[Raspberry Pi Original Development] KonstaT:
Yes, if you're using it with an USB adapter. Please see FAQ section on how to boot from USB devices.

There is only some custom CM4 carrier boards that have NVME slot. I don't have any so I haven't added support for it otherwise.
[Raspberry Pi Original Development] elkir0:
Same problem as many, Can't manage to watch video on apple TV+ or Amazon prime...

I'm using RPI4B 4Gb, Same problem with Lineage 19 and 20, even tried magisk and zygist to make the RPI being certified, but still same problem "cannot load the video, try later" message.

I even tried zygist on Apple TV, or prime, always nothing.

Any Idea anyone ?
[Raspberry Pi Original Development] szabonight:
Hi I'm having trouble trying to display this build (Android 12) on my TV (Kogan KALED55JU8100VA)

I realise you wrote...

Q: My display is not working. I can only see the rainbow screen but no Android boot animation. What should I do?

A: This build only supports HDMI displays that report supported resolutions using EDID. 1920x1080 resolution is used by default with this build. You can change value in /boot/resolution.txt to use a different resolution that your display supports. Removing /boot/resolution.txt will use the preferred resolution of your display.

Can you show me an example of what to write in resolution.txt?

I'm not sure if my TV has EDID but on your Android 11 Build it showed the OS on my TV but only in 640x ?(Something) and I could not change the resolution in Linage (It's like Linage can't see my TV) is there a way to force the display/Resolution?

Note: I've read here somewhere on the forums that it may something to do with overscan, but I'm not sure what that all means?
[Raspberry Pi Original Development] KonstaT:
There's one example if you look what the resolution.txt has by default. If you remove it and it still doesn't work then your display doesn't report any EDID information. Nothing to do with overscan.

One discussion that covers pretty much everything you need to know and the last resort workaround as well. https://github.com/lineage-rpi/android_device_brcm_rpi4/issues/4
[Raspberry Pi Original Development] szabonight:
I added 'drm_kms_helper.edid_firmware=edid/1920x1080.bin' to the end of the line in /boot/cmdline.txt.

It went back to 640x480

I keep thinking, There must be a way of telling Linage what resolution I want.. maybe bypassing EDID?
[Raspberry Pi Original Development] KonstaT:
Something very wrong with your display/setup in that case.

You can use /boot/resolution.txt to force one of the resolutions that your display reports as supported via EDID. You can force the kernel to use specific EDID (regardless of what your display reports if any) with the cmdline parameter (kernel only includes some EDID firmwares by default but you could add more as well). I'm not aware of any other ways around this.
[Raspberry Pi Original Development] MateUserHHTT:
[deleted]
[Raspberry Pi Original Development] WhyNotHugo:
How can I build these images myself?

Are the sources for this available, or it's not open source?
[Raspberry Pi Original Development] KonstaT:
There is no current plans to open source my full device configuration. It's still under consideration if I'll make some minimal device configuration available for people who are interested in contributing to actual development work on various parts that may still need it (hw video dec/enc, camera, etc). In any case it will not support all the features you find on my build though all the basic hardware support would be there.

You can build the Linux kernel (and other GPL licensed parts), graphics drivers/HALs, and various other HALs/components using the sources I've released (https://github.com/lineage-rpi). Other open source Android implementations for Raspberry Pi I can recommend are GloDroid (https://github.com/GloDroid) and android-rpi (https://github.com/android-rpi).
[Raspberry Pi Original Development] szabonight:
OMG !! It was my F**kn Cable - Just a reminder folks ! - Check your HDMI cable if you aint getting EDID info.

:(
[Raspberry Pi Original Development] KonstaT:
Yep, and check your adapters as well. :) At least one micro-HDMI to HDMI adapter I have kills EDID as well.
[Raspberry Pi Original Development] WhyNotHugo:
The expectation being that someone would work on and send back improvements of a part of this fork, while the project as a whole won't be open source?

I can't imagine why someone would be willing.

Thanks for the references, I'll check those out, since using a closed source OS isn't really an option for me.
[Raspberry Pi Original Development] KonstaT:
Rather just provide a base for people to do their own development work. And I would like to have that part of the device configuration available under permissive open source licence (Apache 2.0 vs. some parts of the builds I'm sharing here are licensed under non-commercial license and likely to stay that way). People can contribute to development by simply open sourcing their efforts and making it available for others to use. In any case there isn't exactly people lining up to do any of this work.

I guess that must make life pretty difficult for you. Unfortunately Raspberry Pi is not an option for you as it uses closed source firmware to boot any OS. Also half of LineageOS device specific implementation on any other regular Android device is just closed source binary blobs extracted from the vendor stock firmware/chipset manufacturer BSP. Google services on Android are closed source and proprietary. Replicant (https://replicant.us/) is probably the only thing that comes in mind if you want a fully open source mobile OS.
[Raspberry Pi Original Development] WhyNotHugo:
I'm actually needing to run a VM with LineageOS. Given that rasperry-pi images can somewhat be made to run with qemu, then LOS-RPI images seemed like a sensible starting point for that.

Yeah, I know I'm signing up for a lot of pain.

I don't agree on the order of causality here. Of course nobody's lining up to do it, nobody's going to volunteer to do work for an closed-source project, which they also then can't re-use themselves on anything they get paid for. So, free work for someone else which one can't even re-use...?

If you intend to use a non-commercial license, that'll kill chances of contribution the most IMHO: imagine someone who has a project idea and wants to work full-time on it. Anything that's non-commercial is basically non-existent for that person, since they cannot use it themselves.
[Raspberry Pi Original Development] KonstaT:
I'm sure there's better options for that. I think you can build LineageOS for cuttlefish but I'm not sure what's the exact status on that (https://source.android.com/setup/create/cuttlefish). Android-x86 definitely runs on VM but the Android versions are very outdated nowadays. I'm sure there's going to be tons of pain if you try to get any Raspberry Android builds working in a VM.

Thus "I would like to have that part of the device configuration available under permissive open source licence". And if someone actually wanted to contribute to open source they could use this to do it directly to the upstream project (e.g. v4l2_codec2 on AOSP or libcamera), not just necessary to my device specific config on this project. People do things like this for various reasons and money is certainly not the only one!

But having already done all this previously with the Pi 3 I also know what that resulted. So we'll see, still under consideration like said. Mostly what is needed for this device is already open source and there's plenty of reference available so anyone who would be actually capable of doing something doesn't really need much help from me anyway.
[Raspberry Pi Original Development] WhyNotHugo:
Why do you think so? I expect slowness, but at least ARM has a more alive ecosystem than amd64. Running amd64 sounds like I'll be the odd one out running LineageOS natively on Intel.

And Linux itself runs fine on qemu.

Would would be needed for the RPI build steps to end up in https://wiki.lineageos.org/devices/ ?

Definitely, I agree. We'd have much less open source if people only did it for the money.

OTOH, some of us would love to get paid to work on open source because we'd find that would be far more fulfilling than our current day jobs.
[Raspberry Pi Original Development] rabbited:
adb.txt

drive.google.com
[Raspberry Pi Original Development] KonstaT:
It's been tried on QEMU (https://www.qemu.org/) at least a couple of times but can't find the discussions right now because it's been quite a while. IIRC alone the partition structure used with Android was a problem. I quickly looked it up and it doesn't even emulate Pi 4 hw, only Pi 2/3. Even in that case you would need to compile the kernel (to make Android qemu kernel, they only provide one for Raspbian). Kernel is open source so you can do that, you don't need to compile Android for this.

I'm not an emulation expert but emulating specific hardware and on a different architecture generally sounds like a bad idea. Yeah cool, if they've actually managed get something like that working but still.

Also amd64 = x86_64. Nothing to do with AMD and Intel (other than which one implemented the instruction set first https://superuser.com/questions/128...-called-amd64-and-32-bits-version-called-i386).

It would need the device to be officially supported by LineageOS (i.e. also official builds would be available at https://download.lineageos.org/).

For a device to be officially supported it needs to meet the device support requirements (https://github.com/LineageOS/charter) and it needs to have an active maintainer (who has made the device specific source code available of course to be forked under LineageOS project). Since Raspberry Pi is not an Android device to begin with it will never meet those requirements and I'm not interested in going through any politics and convincing anyone why this device should be an exception. There's several additional forked projects and patches this device requires, different way of creating the image you flash to the device, etc so this really doesn't fit the criteria for officially supported device and it's never even been my goal.

Yeah, sure. And that's the case for many big open source projects. People who are employed by some company and it's their actual job to contribute to open source projects. E.g. for Linux kernel the numbers are somewhere around 90% and only very small fraction of the overall contributions is from voluntary/unpaid developers. I guess the number for Android open source project is even higher as it's mostly Google employees and people who work for companies making Android devices. Slightly different thing than taking some independent developers open source efforts who did it for free and then trying to profit out of it.
[Raspberry Pi Original Development] KonstaT:
Thanks for the log. One quick and easy thing we could try is to enable HS2.0 on the wpa_supplicant (before trying to disable it somewhere in the framework).

Add the following lines to /vendor/etc/wifi/wpa_supplicant.conf:

interworking=1
hs20=1
auto_interworking=0

One way to do it:

su
mount -o rw,remount /vendor
echo "interworking=1" >> /vendor/etc/wifi/wpa_supplicant.conf
echo "hs20=1" >> /vendor/etc/wifi/wpa_supplicant.conf
echo "auto_interworking=0" >> /vendor/etc/wifi/wpa_supplicant.conf

This needs to be tested on a clean installation so boot to TWRP and factory reset after that.

Edit. I still think this is a kernel/wifi driver/wifi firmware issue. If I'm looking this correctly the Hotspot 2.0 is already reported not supported on the Android side otherwise. As it says in https://source.android.com/devices/tech/connect/wifi-passpoint "device manufacturers need to provide firmware support for 802.11u" which I'm not sure about (and why would they care as it's not an Android device to begin with).
[Raspberry Pi Original Development] rabbited:
One thing I found in AOSP docs a few days ago but forgot to mention:

Conversely if device implementations do not include support for Wi-Fi Passpoint:

[C-2-1] The implementation of the Passpoint related WifiManager APIs MUST throw an UnsupportedOperationException.

I'll try your advice today, thanks!
[Raspberry Pi Original Development] rabbited:
I added the lines to a fresh install before my first boot (via Ubuntu on my laptop). No change. Then I installed Raspberry Pi OS and noticed that two Passpoint networks in my area are greyed out on the WiFi setup menu I'm not sure if that means that the OS is set up to block out Passpoint networks or if it means something else.
[Raspberry Pi Original Development] KonstaT:
Thanks for testing. It really doesn't matter much what Raspberry Pi OS does as the higher levels of wifi implementation are totally different in Android. I guess we can at least assume that it doesn't support Hotspot 2.0 networks if you can't connect to them.

Which results wifi settings crashing on that exception. I made stubs of the passpoint related APIs instead which doesn't seem to break anything for me at least. Please test the attached TWRP flashable zip and report back (logcat if the issue still persists).
[Raspberry Pi Original Development] masscream:
Hello, I've installed the LOS 19.0 20211104 with TWRP 3.5.2_11-0 via Pinn OS, and I fully understand that the issue could be in their part of setup, however, I've spend some hours on this problem and so far without any success. I booted simply into TWRP and now I can't get out of it, because every single reboot leads to TWRP again. It may have something in common with difficulties mounting /system_root partition, as I've described here. If the issue is not in the LOS itself but Pinn OS's part, please can you tell me at least if there's any temp workaround until they fix it? (Restoring the right boot img via cmdline, in older versions there used to be a sh script as I've read about...) Thank you.
[Raspberry Pi Original Development] KonstaT:
I'm not supporting any multi-boot solutions so you need to report this to PINN developer procount (as I see you already have https://github.com/procount/pinn/issues/598). Also previously discussed on my site (http://disq.us/p/2l29q40).

But yes, this is definitely broken on PINN side. Booting out of TWRP requires changes on the boot partition which (most likely) is not /dev/block/mmcblk0p1 on multi-boot. Kevin (procount) should be aware of the changes needed for TWRP so I don't know why they are not there for LineageOS 19 (as TWRP works on PINN with previous LineageOS versions).

There is still a shell script (/vendor/bin/rpi4-recovery.sh). You can check what it does and make the changes manually on the boot partition.
[Raspberry Pi Original Development] EthanRIP:
@KonstaT

@EpicLPer

Hello! I seems as you have had success on getting the official 7" touchscreen working for Android 12. I have had the 16.0 version working but would like to switch to 19.0 I have tried and tried to get it working without success, with different Android os as well. Nobody seems to know how or have clear instructions, and I would be very grateful to get this working.
[Raspberry Pi Original Development] rabbited:
logcat2.txt

drive.google.com

I really appreciate your efforts in assisting with this project! No luck so far, but the logcat has changed. It does look like ANQP is still initializing.

In TWRP I went to the Install tab and selected the attached file, I assume that that's the proper procedure (using a fresh install)?

The RPOS test was more just to see if the hardware was definitively supported. Obviously, it's possible the chip could work with Passpoint and that RPOS isn't implementing it properly but I was checking for proof that it DID work before recommending that the package be removed.
[Raspberry Pi Original Development] KonstaT:
Current steps are to install the 5.10 kernel add-on (in TWRP), run a script in rooted shell (in Android) and attach the official display. https://xdaforums.com/t/dev-rom-uno...raspberry-pi-4-b.4356891/page-2#post-86008217 already has the info.

If/when there's another release it will come with 5.10 kernel by default and there is a settings option to enable the necessary configs for the official display.
[Raspberry Pi Original Development] KonstaT:
It's a long-standing issue with my builds so of course I would like to have it resolved in one way or another. If it was something I could reproduce it likely would have been fixed ages ago.

Yes, just install the zip in TWRP. I attached another one to test that should disable making ANQP requests. Please test and report back.

I don't see how Raspberry Pi OS would imply anything in this regard (hw might support it but software doesn't or neither supports it). So, Raspberry Pi OS can display the SSID of the Hotspot 2.0 network but that's it. Android doesn't have any problem getting the BSSID/SSID either (as you can see them in the logs) but something goes wrong with ANQP requests which Android automatically wants to send whenever it sees a Hotspot 2.0 network(?).