Raspberry Pi Forums

Konsta wrote: ↑

Sat Jan 18, 2020 5:30 pm

And you haven't made any of your own modifications to e.g. /boot/config.txt or anywhere else? I just find it extremely strange if you can reproduce that even by changing the ramdisk.img in the 20200106 build with the one from 20200116 because there should be only those couple of things changed (you can also test switching the ramdisk.imgs the other way around).

https://developer.android.com/studio/command-line/adb has links to download adb for different OS and some documentation on how to use adb.

Finally found some time to take a look at this adb stuff. I doubt I could get it going, I do not program nor do I develop anything.

No, I have not made any changes. But I had one unused card left that I tried today. I did not make any changes in setup , no wifi, nothing, just let it run. It worked like a charm. Then I went to connect wifi, reset time zone, no restarts. USB storage was recognized, all apps I wanted installed without a problem. I am beginning to suspect it was a card problem even though except for the very first one, the cards were new out of the box. Forth card working. I do not understand it. I might try again with another card if I find one, just to see what happens. For the record: tried 1 SanDisk Ultra 128GB, 2x SanDisk Ultra 32GB, 1x Transcend Premium 32GB. One of the SanDisk Ultra 32GB was the one working.

Anyway, I am very happy now and will go about thinking how to set everything up. I was thinking about a media center with Kodi, but it seems that I really don't have enough content and only will be using a few apps, so I might just set up a visually pleasing home screen.

Thank you very much for your support. I really do appreciate the time you took and of course also the time you took to develop this version.

ChrisChris wrote: ↑

Wed Jan 22, 2020 7:00 pm

Finally found some time to take a look at this adb stuff. I doubt I could get it going, I do not program nor do I develop anything.

No, I have not made any changes. But I had one unused card left that I tried today. I did not make any changes in setup , no wifi, nothing, just let it run. It worked like a charm. Then I went to connect wifi, reset time zone, no restarts. USB storage was recognized, all apps I wanted installed without a problem. I am beginning to suspect it was a card problem even though except for the very first one, the cards were new out of the box. Forth card working. I do not understand it. I might try again with another card if I find one, just to see what happens. For the record: tried 1 SanDisk Ultra 128GB, 2x SanDisk Ultra 32GB, 1x Transcend Premium 32GB. One of the SanDisk Ultra 32GB was the one working.

Anyway, I am very happy now and will go about thinking how to set everything up. I was thinking about a media center with Kodi, but it seems that I really don't have enough content and only will be using a few apps, so I might just set up a visually pleasing home screen.

Thank you very much for your support. I really do appreciate the time you took and of course also the time you took to develop this version.

Good to hear you got it working.

There's a lot of moving parts on a device like this and sdcard is one of the obvious bottlenecks. Proper class 10 sdcard is recommended while old and abused cards might not work that well. It's still strange because I haven't come across any sdcards that haven't worked. And I think I've only managed to break one card during my years of Android dev on the Pi.

Hello,

Just wondering what the status of v3d support is within android on the pi4.

I believe Mesa DRM/KMS is supported within android, so i'm just wondering what it would take to enable it.


Regards,
Chris.

discombobulated wrote: ↑

Thu Jan 23, 2020 12:27 am

Hello,

Just wondering what the status of v3d support is within android on the pi4.

I believe Mesa DRM/KMS is supported within android, so i'm just wondering what it would take to enable it.


Regards,
Chris.

Currently waiting for full KMS support on Pi 4 kernel side. Plan was to use mainline Android graphics HALs (drm_hwcomposer, minigbm gralloc). Fake/firmware KMS (vc4-fkms-v3d) that Pi 4 currently only supports doesn't seem to work with Android HALs on Pi 3 either.

@konsta do you have any instructions on how to build this from source? Like what additions had to be made to the regular Android build process to make this build?

I'd like to get Android Automotive working on a RpI4 and might need to get deeper into the guts of things to make that happen.

kevinlieb wrote: ↑

Fri Jan 24, 2020 8:13 pm

@konsta do you have any instructions on how to build this from source? Like what additions had to be made to the regular Android build process to make this build?

I'd like to get Android Automotive working on a RpI4 and might need to get deeper into the guts of things to make that happen.

There's source code and build instructions for the LineageOS 14.1 and 15.1 builds for the Pi 3 (https://github.com/lineage-rpi/android_local_manifest).

Unfortunately it is not possible for me to share the source code for LineageOS 16.0 builds for Pi 3/4 in current situation. Raspberry Pi is a bit special because it's not an Android device to begin with. There's commercial Android builds available for the Pi. Even today someone is still selling builds off of sources I've released without even complying with the open source licensing which is why I've stopped releasing the full source code. I know it's very unfortunate for the open source community, but I don't feel like this is something I need to give away for free and let someone else sell it for their personal profit.

Konsta wrote: ↑

Sat Jan 25, 2020 6:13 am

kevinlieb wrote: ↑

Fri Jan 24, 2020 8:13 pm

@konsta do you have any instructions on how to build this from source? Like what additions had to be made to the regular Android build process to make this build?

I'd like to get Android Automotive working on a RpI4 and might need to get deeper into the guts of things to make that happen.

There's source code and build instructions for the LineageOS 14.1 and 15.1 builds for the Pi 3 (https://github.com/lineage-rpi/android_local_manifest).

Unfortunately it is not possible for me to share the source code for LineageOS 16.0 builds for Pi 3/4 in current situation. Raspberry Pi is a bit special because it's not an Android device to begin with. There's commercial Android builds available for the Pi. Even today someone is still selling builds off of sources I've released without even complying with the open source licensing which is why I've stopped releasing the full source code. I know it's very unfortunate for the open source community, but I don't feel like this is something I need to give away for free and let someone else sell it for their personal profit.

Not sure I understand the reasoning...
Are you going to sell it or just prevent someone else from selling it?

I've added LineageOS 16.0 back into PINN.

Dobbey wrote: ↑

Sat Jan 25, 2020 8:44 pm

Not sure I understand the reasoning...
Are you going to sell it or just prevent someone else from selling it?

IMO if someone wants to sell Android builds for the Pi (or start crowdfunding projects or whatever), you need to do a lot more than just take other people's existing free and open source efforts and stick your own name and brand on top of it (talking about Exton and RaspAnd here). One very effective way for me to prevent this from happening again is to stop releasing the source code. If you are selling other people's free and open source software you should also take care you're complying with the open source licensing the code was released under...

I'm coming from Android custom ROM scene and this is just a hobby project of mine. You couldn't even consider selling custom Android builds on any regular Android device but Raspberry Pi seems to be special because it's not an Android device to begin with. Licensing on the latest images I've made publicly available doesn't allow commercial use. Creating customized Android images for businesses is certainly an option to consider.

There's tens of thousands of people using my free Android builds for the Pi yet there is zero donations coming in. In that regard doing this makes absolutely no sense so I guess lucky for you I haven't been doing this for the money. Reality just is that in a world where things are usually free and open source, money and wrong people making it complicates things.

procount wrote: ↑

Sat Jan 25, 2020 10:39 pm

I've added LineageOS 16.0 back into PINN.

Cool. BTW, does TWRP recovery also work? I checked some of your scripts and I see you're doing some changes to fstab. You'll likely need to make similar changes to the one inside ramdisk-recovery.img as well.

TBH, I've not looked at TWRP yet, nor modifying gapps.sh if that is still applicable. I just figured out why it had stopped working and fixed it for 16.0.
I also updated the installation slideshow. I hope it is more appropriate now, but if you'd like to show something else, just send me some alternative png and I'll be happy to replace them.

procount wrote: ↑

Sun Jan 26, 2020 9:40 am

TBH, I've not looked at TWRP yet, nor modifying gapps.sh if that is still applicable. I just figured out why it had stopped working and fixed it for 16.0.
I also updated the installation slideshow. I hope it is more appropriate now, but if you'd like to show something else, just send me some alternative png and I'll be happy to replace them.

TWRP has been included in my builds for 18+ months and it's also useful for other things besides installing gapps. gapps.sh hasn't been a thing for even much longer than that. It really shouldn't take other than similar changes to the fstab you're doing Android side of things.

This is not an official LineageOS release so I'm not entirely sure if all the official 'marketing' material applies here but I don't feel like doing any GIMPing myself either.

Konsta wrote: ↑

Sun Jan 26, 2020 10:33 am

TWRP has been included in my builds for 18+ months and it's also useful for other things besides installing gapps. gapps.sh hasn't been a thing for even much longer than that.

Yeah, it's been a while since I did my first conversion

Konsta wrote: ↑

Sun Jan 26, 2020 10:33 am

It really shouldn't take other than similar changes to the fstab you're doing Android side of things.

I assume so. I'll have to give it a try when I get some more time.

Konsta wrote: ↑

Sun Jan 26, 2020 10:33 am

This is not an official LineageOS release so I'm not entirely sure if all the official 'marketing' material applies here but I don't feel like doing any GIMPing myself either.

I don't blame you I just did some cut n' shut images, but at least they relate to the right OS now!

Hello Konsta,
if the lineageOS loading sign shows up and afterwards a picture with all colors (rainbow pictue) pops up and after a few seconds the system reboots itself, is this related to a not supported monitor? I've read your FAQ, but was just wondering if the Pi will re-boot because of a not supported monitor or if this is another problem.
I let it run for about 10 minutes but it was always the same. Boot, show image, reboot.

Do you have an idea what this could be?
Regards Sku

Skuriles wrote: ↑

Mon Jan 27, 2020 4:06 am

Hello Konsta,
if the lineageOS loading sign shows up and afterwards a picture with all colors (rainbow pictue) pops up and after a few seconds the system reboots itself, is this related to a not supported monitor? I've read your FAQ, but was just wondering if the Pi will re-boot because of a not supported monitor or if this is another problem.
I let it run for about 10 minutes but it was always the same. Boot, show image, reboot.

Do you have an idea what this could be?
Regards Sku

Previous person in this thread who had issues with reboots it was because of the sdcard. If you can test with another display, that's great, too.

Use a proper sdcard (at least class 10), use a proper power source (3A in case of Pi 4), and use a HDMI display that supports 720p resolution (or the official 7" touchscreen).

Really hard to give any other advice and it's impossible to say what is the reason exactly without seeing any logs. You'd need to have a serial console adapter to get logs from that stage of the boot process.

Hey,

thanks for quick reply. I'm currently playing with different OS (fullpageOs, Libreelec, Android). So it was just a test. Maybe if I find time I will try again.
It was a bundle with official power adapter for Pi 4 and a SanDisk Ultra SD Card. Maybe something went wrong on flashing (made this experience, that when you just flash sometimes it succeeded but checksum was wrong and this led to issues.
Monitor was a normal PC monitor which should support most resolutions by default.

So I will give feedback if I have any news.

Konsta wrote: ↑

Sun Jan 26, 2020 7:34 am

Dobbey wrote: ↑

Sat Jan 25, 2020 8:44 pm

Not sure I understand the reasoning...
Are you going to sell it or just prevent someone else from selling it?

IMO if someone wants to sell Android builds for the Pi (or start crowdfunding projects or whatever), you need to do a lot more than just take other people's existing free and open source efforts and stick your own name and brand on top of it (talking about E***n and R***A*d here). One very effective way for me to prevent this from happening again is to stop releasing the source code. If you are selling other people's free and open source software you should also take care you're complying with the open source licensing the code was released under...

I'm coming from Android custom ROM scene and this is just a hobby project of mine. You couldn't even consider selling custom Android builds on any regular Android device but Raspberry Pi seems to be special because it's not an Android device to begin with. Licensing on the latest images I've made publicly available doesn't allow commercial use. Creating customized Android images for businesses is certainly an option to consider.

Can we crowdfund legal fees to sue?

After all, you are entitled to royalties, since they are using outside the scope of the free license. It could also set an example for anyone else thinking about doing the same.

Konsta wrote: ↑

Sun Jan 26, 2020 7:34 am

There's tens of thousands of people using my free Android builds for the Pi yet there is zero donations coming in. In that regard doing this makes absolutely no sense so I guess lucky for you I haven't been doing this for the money. Reality just is that in a world where things are usually free and open source, money and wrong people making it complicates things.

As someone who has gotten donations from Android projects, I can tell you that the amount of donations you get is directly proportionate to the cost of the device. A $55 Pi4 isn't going to bring much in, as the target audience (usually) does not have money to spare. However, making a ROM for a $1,000 flagship, usually, the users have some spending cash.

Trust me, I have been screwed in the Android community before. Wasn't really selling, but in the days before git, just taking my optimizations, adding one more, and claiming they did it all. So I understand how it feels to be jaded by this development community.

I am working on an AOSP tree in partnership with another group, it is nowhere near ready so I will not link it to get any hopes up. I assume that the aforementioned parties are likely watching it or will be.

In any case thanks for all you have done already and what you have left open source, it has been great reference, even if P and Q are much different.

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

Can we crowdfund legal fees to sue?

After all, you are entitled to royalties, since they are using outside the scope of the free license. It could also set an example for anyone else thinking about doing the same.

IMO there should be ways to resolve these things out of court. That should be the final option and I'm not sure we're quite there yet. Then again, I've also come to realize there is no reasoning with that person...

It would be certainly interesting to see how the GPLv2 would hold out in court (previously it has). I've managed to get multi-billion companies to comply with the GPLv2 and release source code they're obligated to provide. In this case I even have some of my own work under the license.

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

As someone who has gotten donations from Android projects, I can tell you that the amount of donations you get is directly proportionate to the cost of the device. A $55 Pi4 isn't going to bring much in, as the target audience (usually) does not have money to spare. However, making a ROM for a $1,000 flagship, usually, the users have some spending cash.

Yeah, not my first device either. Never done any of this with any target audience in mind. Rather done it for myself and just shared it publicly. Once you get the hang of making AOSP-based ROMs for Qualcomm phones, you could easily keep repeating it for the next hot and popular Qualcomm device if you were after donations/free devices. I've just rather chosen to develop on hardware/platforms no one else is (done the first custom ROM bring-ups on any msm8610, msm8909, and Intel CherryTrail device). Keeps it interesting as a hobby when you don't just keep repeating something that you already know, but there's always a chance to learn new things.

On Pi a lot of thanks goes to android-rpi project of course. It's been nearly three years, three Android versions, and two hardware revisions since I forked off so I've managed something on my own, too. There's certainly some things that makes Pi interesting target for Android development like what is going on with the kernel and mainline graphics. If/when we can get the mainline graphics drivers working, it's also going to run any new Android version in any foreseeable future (I think Pi 3 is already there).

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

I am working on an AOSP tree in partnership with another group, it is nowhere near ready so I will not link it to get any hopes up. I assume that the aforementioned parties are likely watching it or will be.

It looks like that you've managed to boot it(?) at least so congratulations on that.

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

In any case thanks for all you have done already and what you have left open source, it has been great reference, even if P and Q are much different.

O->P requires very few device specific changes (e.g. compared to N->O). lineage-rpi has source code for Oreo build for Pi 3 that uses software renderer. It's really not a long way to Pie build for Pi 4 that also uses software renderer (with everything else I've made available for Pi 4).

Konsta wrote: ↑

Tue Jan 28, 2020 6:34 pm

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

Can we crowdfund legal fees to sue?

After all, you are entitled to royalties, since they are using outside the scope of the free license. It could also set an example for anyone else thinking about doing the same.

IMO there should be ways to resolve these things out of court. That should be the final option and I'm not sure we're quite there yet. Then again, I've also come to realize there is no reasoning with that person...

It would be certainly interesting to see how the GPLv2 would hold out in court (previously it has). I've managed to get multi-billion companies to comply with the GPLv2 and release source code they're obligated to provide. In this case I even have some of my own work under the license.

I agree, but as you say they clearly know what they are doing and don't care, and at this point the offenders are the only ones not suffering as a result (you are upset, we don't get the source code, but they keep building and selling roms with what they have)

Konsta wrote: ↑

Tue Jan 28, 2020 6:34 pm

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

As someone who has gotten donations from Android projects, I can tell you that the amount of donations you get is directly proportionate to the cost of the device. A $55 Pi4 isn't going to bring much in, as the target audience (usually) does not have money to spare. However, making a ROM for a $1,000 flagship, usually, the users have some spending cash.

Yeah, not my first device either. Never done any of this with any target audience in mind. Rather done it for myself and just shared it publicly. Once you get the hang of making AOSP-based ROMs for Qualcomm phones, you could easily keep repeating it for the next hot and popular Qualcomm device if you were after donations/free devices. I've just rather chosen to develop on hardware/platforms no one else is (done the first custom ROM bring-ups on any msm8610, msm8909, and Intel CherryTrail device). Keeps it interesting as a hobby when you don't just keep repeating something that you already know, but there's always a chance to learn new things.

My favorite Intel device was a Nextbook that went through the effort of locking down Fastboot, but let you boot raw custom UEFI If you look up "zefieOS" on Github, I ended up making a restore system that should work on any UEFI tablet (that allows custom unsigned UEFI boot).

Konsta wrote: ↑

Tue Jan 28, 2020 6:34 pm

On Pi a lot of thanks goes to android-rpi project of course. It's been nearly three years, three Android versions, and two hardware revisions since I forked off so I've managed something on my own, too. There's certainly some things that makes Pi interesting target for Android development like what is going on with the kernel and mainline graphics. If/when we can get the mainline graphics drivers working, it's also going to run any new Android version in any foreseeable future (I think Pi 3 is already there).

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

I am working on an AOSP tree in partnership with another group, it is nowhere near ready so I will not link it to get any hopes up. I assume that the aforementioned parties are likely watching it or will be.

It looks like that you've managed to boot it(?) at least so congratulations on that.

Nah, not into the OS yet, memtrack crashes on both v3d test and swrast builds. my v3d testing is to the point where as far as Android is concerned, it works, but the screen is black :/ (trying to use the FydeOS cros_gralloc)

Konsta wrote: ↑

Tue Jan 28, 2020 6:34 pm

zefie wrote: ↑

Tue Jan 28, 2020 3:08 pm

In any case thanks for all you have done already and what you have left open source, it has been great reference, even if P and Q are much different.

O->P requires very few device specific changes (e.g. compared to N->O). lineage-rpi has source code for Oreo build for Pi 3 that uses software renderer. It's really not a long way to Pie build for Pi 4 that also uses software renderer (with everything else I've made available for Pi 4).

I was reading that P -> Q swapped the roles of HWC/Gralloc? Or maybe that was N -> O?

zefie wrote: ↑

Wed Jan 29, 2020 11:23 am

I agree, but as you say they clearly know what they are doing and don't care, and at this point the offenders are the only ones not suffering as a result (you are upset, we don't get the source code, but they keep building and selling roms with what they have)

An offender and he has already moved on to leeching off of brobwind's sources for Pie. But yeah, still selling old builds off of android-rpi and lineage-rpi sources as well. Funny how it's been at least three completely different things but the brand he puts on top always stays the same.

I'm absolutely sure this gets sorted eventually one way or another. I'm doing fine, but I'd much rather spend my time on something other than dealing with this. This situation is of course not good overall considering open source Android development on the Pi.

zefie wrote: ↑

Wed Jan 29, 2020 11:23 am

Nah, not into the OS yet, memtrack crashes on both v3d test and swrast builds. my v3d testing is to the point where as far as Android is concerned, it works, but the screen is black :/ (trying to use the FydeOS cros_gralloc)

memtrack I'm using (https://github.com/lineage-rpi/android_ ... 1/memtrack) is just a empty dummy HAL and it doesn't do anything. It was only added to prevent some log spam and it's not even needed to boot.

zefie wrote: ↑

Wed Jan 29, 2020 11:23 am

I was reading that P -> Q swapped the roles of HWC/Gralloc? Or maybe that was N -> O?

They haven't. Same hwcomposer & gralloc I'm using on P also work on Q.

Konsta wrote: ↑

Wed Jan 29, 2020 1:29 pm

zefie wrote: ↑

Wed Jan 29, 2020 11:23 am

Nah, not into the OS yet, memtrack crashes on both v3d test and swrast builds. my v3d testing is to the point where as far as Android is concerned, it works, but the screen is black :/ (trying to use the FydeOS cros_gralloc)

memtrack I'm using (https://github.com/lineage-rpi/android_ ... 1/memtrack) is just a empty dummy HAL and it doesn't do anything. It was only added to prevent some log spam and it's not even needed to boot.

Yeah, I found a few hikey inspirations
Oddly now my v3d test is at a point where there is still no display, but it kinda stalls without any spam or log. Clean console, lol...
Killing surfaceflinger once will kickstart the OS when it restarts, but then zygote crashes with null pointer references or some crap, IDK what I did, haha.

Konsta wrote: ↑

Wed Jan 29, 2020 1:29 pm

zefie wrote: ↑

Wed Jan 29, 2020 11:23 am

I was reading that P -> Q swapped the roles of HWC/Gralloc? Or maybe that was N -> O?

They haven't. Same hwcomposer & gralloc I'm using on P also work on Q.

Is that for the rpi3's kms as well? or just no changes for swrast?

Another thing that may be complicating things is that I am targeting 64-bit mode.

zefie wrote: ↑

Wed Jan 29, 2020 2:35 pm

Is that for the rpi3's kms as well? or just no changes for swrast?

Another thing that may be complicating things is that I am targeting 64-bit mode.

Both, i.e. same what I'm currently using on LineageOS 16.0 on Pi 3 and Pi 4.

It's kind of confusing to talk about swrast because mesa has swrast which is something other than SwiftShader. SwiftShader only builds for 32-bit arm architecture.

Konsta wrote: ↑

Wed Jan 29, 2020 4:54 pm

zefie wrote: ↑

Wed Jan 29, 2020 2:35 pm

Is that for the rpi3's kms as well? or just no changes for swrast?

Another thing that may be complicating things is that I am targeting 64-bit mode.

Both, i.e. same what I'm currently using on LineageOS 16.0 on Pi 3 and Pi 4.

It's kind of confusing to talk about swrast because mesa has swrast which is something other than SwiftShader. SwiftShader only builds for 32-bit arm architecture.

I didn't know they were separate. My SwiftShader (misnamed swrast) target does show the boot animation but does not boot the OS. It does also appear to be placing SwiftShader libs into lib64.

zefie wrote: ↑

Wed Jan 29, 2020 6:55 pm

I didn't know they were separate. My SwiftShader (misnamed swrast) target does show the boot animation but does not boot the OS. It does also appear to be placing SwiftShader libs into lib64.

Ah, apparently things have changed from Pie (https://android.googlesource.com/platfo ... roid.mk#32). SwiftShader should even work with just gralloc.default so you don't need to use any other gralloc and hwcomposer (it's just really slow without hwc). Likely some other issue holding up if you can see the bootanimation.

Konsta wrote: ↑

Wed Jan 29, 2020 7:41 pm

zefie wrote: ↑

Wed Jan 29, 2020 6:55 pm

I didn't know they were separate. My SwiftShader (misnamed swrast) target does show the boot animation but does not boot the OS. It does also appear to be placing SwiftShader libs into lib64.

Ah, apparently things have changed from Pie (https://android.googlesource.com/platfo ... roid.mk#32). SwiftShader should even work with just gralloc.default so you don't need to use any other gralloc and hwcomposer (it's just really slow without hwc). Likely some other issue holding up if you can see the bootanimation.

I'm targeting Q (specifically android-10.0.0_r25). they added arm64... or its just running in 32bit since I'm building multilib. IDK. It literally stalls so I must be missing something.