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

[DEV][ROM][UNOFFICIAL] LineageOS 19.0 (Android 12) for Raspberry Pi 4 B

Search This thread

szabonight

Member
Dec 12, 2018
12
2
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?
 

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
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?
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
 
Last edited:

szabonight

Member
Dec 12, 2018
12
2
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?
 

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
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?
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.
 
Last edited:

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
How can I build these images myself?

Are the sources for this available, or it's not open source?
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).
 

WhyNotHugo

New member
Dec 10, 2021
4
0
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).
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.
 

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
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.
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.
... since using a closed source OS isn't really an option for me.
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.
 
Last edited:

WhyNotHugo

New member
Dec 10, 2021
4
0
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.

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 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.
 

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
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'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.
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.
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.
 
Last edited:

WhyNotHugo

New member
Dec 10, 2021
4
0
I'm sure there's going to be tons of pain if you try to get any Raspberry Android builds working in a VM.

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.

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.

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

People do things like this for various reasons and money is certainly not the only one!

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.
 

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
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.
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).
Would would be needed for the RPI build steps to end up in https://wiki.lineageos.org/devices/ ?
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.
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.
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.
 
Last edited:

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
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:
Code:
interworking=1
hs20=1
auto_interworking=0

One way to do it:
Code:
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).
 
Last edited:

rabbited

Member
Mar 10, 2020
30
3
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:
Code:
interworking=1
hs20=1
auto_interworking=0

One way to do it:
Code:
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).
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!
 

rabbited

Member
Mar 10, 2020
30
3
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:
Code:
interworking=1
hs20=1
auto_interworking=0

One way to do it:
Code:
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).
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.
 

KonstaT

Senior Member
Jan 20, 2016
575
358
KonstaKANG.com
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.
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.
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.
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).
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    So that's not a real LDAC?
    Like said, even if there was such option it does nothing. There is no support for _any_ proprietary bluetooth audio codec.

    Edit. I take that back. LDAC should work on any device with Android 8+. AFAIK Qualcomm's aptX needs some proprietary stuff but it wouldn't be too surprising if I'm wrong on that as well (Edit2. It does, and I wasn't https://android-review.googlesource.com/c/platform/system/bt/+/318907/). :p
    2
    New Build.


    -add new options to Raspberry Pi settings (force rotation & CPU governor)
    -fix GPS issue caused by incomplete location data
    -small improvements to HDMI audio support
    -prepare for OTAs
    -update to TWRP 3.6.0_11-1-KonstaKANG
    -update to Mesa 21.3.4
    -update to Linux 5.10.90 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
    -Android security patch level: 5 January 2022 (merged)

    -----

    There's also Android TV version available.


    -initial LineageOS 19.0 Android TV build
    -add support for Pi camera modules using libcamera, preview & photos work - camcorder doesn’t (thanks to Roman Stratiienko)
    -drop old v1 camera HAL and use external camera HAL for UVC USB webcams (camera needs to support MJPG format - preview, photos & camcorder works)
    -fix reboots related to Hotspot 2.0 networks/ANQP requests (see issue #6)
    -Vulkan 1.1 (thanks to people at Igalia for Vulkan 1.1 conformance and Roman Stratiienko for latest Mesa fixes)
    -add new options to Raspberry Pi settings (force rotation & CPU governor)
    -prepare for OTAs
    -update to TWRP 3.6.0_11-1-KonstaKANG
    -update to Mesa 21.3.4
    -update to Linux 5.10.90 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
    -Android security patch level: 5 January 2022 (merged)
    1
    Is there a problem with audio streaming through bluetooth? I have tryed to play audio over bluetooth on my car radio and it has some cut offs.
    There is a know issue with bluetooth audio and Google location services after installing gapps. This only happens with gapps installed and if you've enabled location access during the gapps setup. Google location services scan nearby bluetooth devices to determine the device location which doesn't work great when your using bluetooth audio at the same time. There's also workaround available if disabling Google location access is not enough https://forum.xda-developers.com/t/...aspberry-pi-4-b.4212945/page-14#post-85769441
    Greeting. I installed Android 12 on Rpi4 and connected the Sony WH-1000XM3. When I checked which audio codec was being used, it says LDAC. So not only Rpi, but the headphones are currently working on that codec, while they are connected to Rpi. How is that possible ?
    It means nothing. Bluetooth codec options in developer options are no-op.

    Edit. LDAC should work, see https://forum.xda-developers.com/t/...raspberry-pi-4-b.4356891/page-7#post-86219431
    So I know to make the MPU6050 work I have to remove the # on #dtoverlay=android-i2c-sensor,mpu6050, I've done that and had my other sensor working fine however it's an MPU9265 technically and the compass on it doesn't report since the software wasn't setup for it. I want the compass to work so I got a LSM303DLHC since it was theoretically plug and play. I then tried writing a line dtoverlay=android-i2c-sensor,lsm303dlhc thinking it needed that to look for the input from the sensor. Unfortunately I've had no luck, I've even tried using the 6050 line again just to see if the accelerometer data might be there but of course that doesn't work. I got a 2nd one thinking maybe it was defective but unfortunatly it still isn't working. The one from adafruit is no longer available... I may have one that for one reason or another isn't compatible I don't really know, or maybe I have no idea what I'm doing? It says it uses the LSM303DLHC sensor but the board is calling itself a GY-511, it still has the correct pins however and I figured if the chip on board is correct then the rest of the stuff is just the power conditioning and should still connect properly over the I2C data paths.
    There is a settings option in Settings -> System -> Advanced settings -> Sensors. You should use that for the supported sensors instead of modifying config.txt manually. Edit. Besides, it's 'dtoverlay=android-i2c-sensor,lsm303dlhca,lsm303dlhcm' for this sensor module.

    Check 'dmesg' and 'i2cdetect -y 1' (in rooted shell) to see that your sensor module is detected and what I2C address is uses. If your sensor module uses different I2C address than expected (https://github.com/lineage-rpi/andr...erlays/android-i2c-sensor-overlay.dts#L43-L71) it can also be configured in the config.txt.
    1
    Forgot to mention thanks for all of you in taking time to make this build possible. As this in my opinion is a very impressive early android 12 build for the raspberry pi 4 and 400.
    1
    There's tons information available about Android that applies to all devices running it. It would be practically impossible for me to maintain documentation that covers everything. I try to do it for the stuff that applies to my builds specifically. IMO I have a pretty good FAQ which unfortunately too few bother to read (maybe it's already getting too lengthy) because half of my replies usually include "please read the FAQ" (*grrhmm* you certainly didn't read the FAQ on installing gapps ;)).

    I'm not aware there being any display density related options in developer settings. Settings -> Display -> Display size does similar thing.

    Which manifests itself when you use non-standard resolution/density. LOL, maybe just adjust your settings to something that doesn't cause them to overlap then.

    Any IMO the whole 'Show arrow keys while typing' feature is utterly useless on non-touchscreen devices and how often do you ever need to press (virtual) power button while typing anyway (BTW, Android 12 now has one in notification shade as well).

    I take things are going pretty well if this is the biggest issue you can come across. :)
    Pretty damn well yes!
  • 8
    Here’s my build of LineageOS 19.0 for Raspberry Pi 4 Model B and Pi 400. It is unofficial and unsupported by the LineageOS team. It’s for advanced users only. Pi 4 model with at least 2GB of RAM is required to run this build.

    Important! This image includes parts that are licensed under non-commercial license (Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International). You may use this build freely in personal/educational/etc use. Commercial use is not allowed with this build!

    Screenshot_20211103-211529.png


    There is also Android TV version available.

    Screenshot_20220114-084413_Settings.png


    Working:
    • Audio (HDMI, 3.5mm jack, USB microphones, bluetooth speakers/headphones, etc)
    • Audio DAC (using GPIO DACs e.g. Hifiberry DAC+)
    • Bluetooth (and bluetooth tethering)
    • Camera (using official Pi camera modules & UVC USB webcams)
    • GPIO
    • GPS (using external USB modules e.g. U-Blox 7)
    • Ethernet
    • Hardware accelerated graphics (V3D, OpenGL & Vulkan)
    • HDMI display (and HDMI-CEC)
    • I2C
    • IR remotes (using external GPIO IR modules e.g. TSOP4838)
    • RTC (using external GPIO I2C modules e.g. DS3231)
    • Sensors (using external GPIO I2C modules e.g. MPU6050, LSM6DS3, LSM303DLHC & BME280/BMP280 accelerometer/gyroscope/magnetometer/temperature/pressure/humidity)
    • Serial console (using external GPIO serial console adapters e.g. PL2303)
    • SPI
    • Touchscreen/multi-touch (official 7" touchscreen, USB touchscreens, Waveshare SPI touchscreens)
    • USB (mouse, keyboard, storage, etc)
    • USB-C (ADB, MTP, PTP, USB tethering)
    • Wifi (and wifi tethering)

    Not working:
    • Hardware video decoding & encoding (software decoding & encoding works, option to test highly experimental H.264 hardware video decoding)

    Issues:
    • Camcorder & some third party camera apps don't work with official Pi camera modules
    • SELinux is in permissive mode
    • and more…

    Sources:

    Thanks:
    • Peter Yoon and android-rpi project
    • Roman Stratiienko and GloDroid project
    • AOSP reference board developers (dragonboard, hikey, yukawa)
    • E. Anholt for V3D graphics driver
    • Maxime Ripard for Pi 4 KMS driver
    • Android-x86 project
    • LineageOS team and everyone who has contributed to LineageOS 19.0
    3
    New build.


    -switch to Linux 5.10 kernel by default
    -fix VC4 HDMI audio with 5.10 kernel (3.5mm jack is now used by default so select the right HDMI device from the settings)
    -add support for the official 7" touchscreen display with hw accelerated graphics (enable configurations for the touchscreen from the settings)
    -minor brightness fixes for the official 7" display
    -add support for Pi camera modules using libcamera, preview & photos work - camcorder doesn't (thanks to Roman Stratiienko)
    -fix UVC USB webcams that use external camera HAL (camera needs to support MJPG format - preview, photos & camcorder works)
    -add option to enable currently very WIP H.264 hardware video decoding using v4l2_codec2 (enable experimental feature from the settings)
    -fix reboots related to Hotspot 2.0 networks/ANQP requests (see issue #6)
    -Vulkan 1.1 (thanks to people at Igalia for Vulkan 1.1 conformance and Roman Stratiienko for latest Mesa fixes)
    -update to Mesa 21.3.1
    -update to Linux 5.10.83 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
    -Android security patch level: 5 December 2021 (merged)
    2
    Wow I didn't expect latest Android being supported on the Pie, thanks for the great work!
    I have two small questions though :
    • Do you know how is support for microG? It doesn't cause any problem? (was wondering about casting videos for example)
    MicroG requires a patch for signature spoofing that is not included in LineageOS for security reasons. I think this is also something that can be achieved using Magisk (which is now supported) but haven't looked into it.
    • I know it has been asked few times already, but now that Android 12 has been released are you confident it will be possible to have support for hardware acceleration soon? Would make a big difference to have a steady 1080p/60fps
    I'm pretty confident it will work eventually. Soon(™) is also a relative term.

    Short term goal is to get some proof of concept that stateful H.264 V4L2 dec/enc can work on Android on Pi 4. Just made some minor progress with v4l2_codec2 couple of days ago and got the dec/enc codec2 component to even do something in the first place. Not sure if the current issues I'm having are due to memory allocation or the codec component negotiating with the kernel driver. There's also still some hardcoded buffer sizes, etc that depend on the video resolution you're trying to dec/enc. Only real hardware that I'm aware that just recently has this working at least to some extent is dragonboard and John Stultz has tweeted some updates on the matter so check those out if you're interested.

    Sorry if this wasn't the news you were looking for but things like this take time.
    2
    Short term goal is to get some proof of concept that stateful H.264 V4L2 dec/enc can work on Android on Pi 4.
    And that didn't even take too long. \o/ But yes, H.264 V4L2 hardware decoding can work on Android on the Pi 4!

    Something still getting messed up somewhere in the pipeline so the colors are not correct and there's a green tint on the bottom half of the playback.
    https://www.dropbox.com/s/hlvcv23ejfpinn5/VID_20211108_194739.mp4?dl=0
    2
    New build. Added optional Linux 5.10 kernel add-on to test a lot of WIP stuff.


    -add option to show virtual volume down, volume up, and power keys on navigation bar (requires reboot)
    -add option for old TCP-based ADB over network
    -show IP address and port for ADB/SSH/VNC options
    -update to TWRP 3.6.0_11-0-KonstaKANG
    -update to Mesa 21.3.0
    -update to Linux 5.4.161 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
    -Android security patch level: 5 November 2021 (merged)

    Linux 5.10 kernel: (optional add-on)
    -various KMS driver improvements (DSI panel support, etc)
    -support for Pi camera modules using libcamera, preview & photos work - camcorder doesn’t (thanks to Roman Stratiienko)
    -option to test currently very WIP H.264 hardware video decoding using v4l2_codec2 (Settings -> System -> Advanced settings -> Hardware video decoding)
    -HDMI audio is not supported! (see issue #4651 & issue #4654)
    -new Raspberry Pi Android kernel bring-up based on AOSP android12-5.10-lts
    -update to Linux 5.10.81 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)