LineageOS 17.1 x86

6,226 views
Skip to first unread message

Francescodario Cuzzocrea

unread,
Apr 11, 2020, 1:18:02 PM4/11/20
to Android-x86
Good Evening (or morning, depending on your fuse :D)

In  those days I worked toward porting android-x86 on top of lineageos-17.1 (so Q) with the help of Jon West 

That is what I ended up with :

https://gitlab.com/lineageos-x86?sort=name_asc

the manifests which I use is 

https://gitlab.com/lineageos-x86/android/-/blob/lineage-17.1/snippets/lineage-x86.xml

I arrived to the point that everything compile and produces an iso image. What I did was simply trying to adapt android-x86 commits on top of current lineageos codebase.

The image boots, but is stucked at Lineage boot logo, and I have no clue on how to debug that, as if I enter into debug mode, after a while the bootimage kicks in and I am not anymore able to see the logs. I have seen on the site that it is possible to debug with virtualbox and adb but I don't reach the status of having the network up to check the ip.
Also, if I try the usual combo to enter into tty, the logs appears for a fraction of second and the again I have the bootimage

So I would like to ask how I can debug further booting issues, and if there is someone interested into joining the project !

Thanks in advance for your replies,

Dario

Mauro Rossi

unread,
Apr 11, 2020, 4:49:14 PM4/11/20
to Android-x86
Hi Dario,

you could try with [ALT]+[F1], mounting a 2nd usb flash drive and copying over /data/log.txt and /data/tombstones/ (if any)

In case you know in advance with /dev/block/sd.. will appear when plugging the 2nd usb flash drive, supposing it is sdc1
you could use DATA=/dev/block/sdc1 entry in grub cmdline, but you need an ext4 formatted flash drive,
in this way you should get log.txt in the 2nd usb flash drive, even the system freezes

As other suggestion, it is better to start with drm_gralloc and with Intel HW when the goal is to reach first boot

Mauro

Francescodario Cuzzocrea

unread,
Apr 12, 2020, 4:10:37 AM4/12/20
to Android-x86
Grazie 1000 per il consiglio Mauro !! 

Thanks a lot for the advice, adding DATA=/dev/block/sda1 did the trick and I was able to pull log.txt !

Though, I cannot exactly determine the root cause of the issue (I am more used to search for issues in phones) :(

I will share the log here, if someone with a bit of free time wanna take a look, 4 eyes are better than 2


Buona Pasqua !! (Happy Easter)

Dario
log.txt

Francescodario Cuzzocrea

unread,
Apr 12, 2020, 4:14:58 AM4/12/20
to Android-x86
Also, after a closer look, to me it seems that Taskbar and TSCalibration2 miss some permssion (I guess lineage enforces that) and so everything just dies.

Or am I wrong and the root cause is another ?

Francescodario Cuzzocrea

unread,
Apr 12, 2020, 5:15:01 AM4/12/20
to Android-x86
It was that now it boots !!!!! I'm too happy ahah

Jon West

unread,
Apr 12, 2020, 10:10:12 AM4/12/20
to Android-x86
Awesomeness!!

Francescodario Cuzzocrea

unread,
Apr 12, 2020, 10:45:33 AM4/12/20
to andro...@googlegroups.com
Yeah I attach some pics here

Everything seems to works so far, and it also seems to be more stable than plain aosp.

I guess you can consider lineageos integration as mostly done :D

Feel free to comment on what I did on my sources (

I will try to look into building ffmpeg with Intel media SDK now, to try to have hw video decoding\encoding.

Il dom 12 apr 2020, 16:10 Jon West <electr...@gmail.com> ha scritto:
Awesomeness!!

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/1361e3cb-5468-47ac-8dea-2c3c3abf8d60%40googlegroups.com.
IMG_20200412_110752_459.jpg
IMG_20200412_110836_738.jpg
IMG_20200412_110913_530.jpg
IMG_20200412_110902_095.jpg

Mauro Rossi

unread,
Apr 12, 2020, 5:07:38 PM4/12/20
to Android-x86


On Sunday, April 12, 2020 at 10:14:58 AM UTC+2, Francescodario Cuzzocrea wrote:
Also, after a closer look, to me it seems that Taskbar and TSCalibration2 miss some permssion (I guess lineage enforces that) and so everything just dies.

Or am I wrong and the root cause is another ?


--------- beginning of crash
04-12 10:01:12.237  3076  3076 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: main
04-12 10:01:12.237  3076  3076 E AndroidRuntime: java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: {com.farmerbb.taskbar.androidx86: android.permission.WRITE_SECURE_SETTINGS, org.zeroxlab.util.tscal: android.permission.WRITE_SECURE_SETTINGS, org.zeroxlab.util.tscal: android.permission.SET_ALWAYS_FINISH, com.farmerbb.taskbar.androidx86: android.permission.PACKAGE_USAGE_STATS}

Just for my learning, how did you solve?

Mauro

Francescodario Cuzzocrea

unread,
Apr 12, 2020, 5:24:38 PM4/12/20
to andro...@googlegroups.com
ah for the moment I just killed both tscalibration2 and taskbar.
but the right solution would be 

https://source.android.com/devices/tech/config/perms-whitelist

so basically create 

/etc/permissions/privapp-permissions-android-x86.xml

with 

<privapp-permissions package="com.farmerbb.taskbar.androidx86">
   
<permission name="android.permission.WRITE_SECURE_SETTINGS"/>
   
<permission name="android.permission.PACKAGE_USAGE_STATS"/>
</privapp-permissions> <privapp-permissions package="org.zeroxlab.util.tscal">
   
<permission name="android.permission.WRITE_SECURE_SETTINGS"/>
   
<permission name="android.permission.SET_ALWAYS_FINISH"/>
</privapp-permissions>

and so on. Probably the right thing to do is to just read in the apps manifests the permission that they need and add them to the xml file.

This is the same thing opengapps is doing for granting permission for gapps


as you can see for every privileged app which does need special permission they add an xml 
--
You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/ZY2BXdvCBPY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/c98d231b-7488-497d-aa59-d011838159a0%40googlegroups.com.

Michael Goffioul

unread,
Apr 12, 2020, 5:26:57 PM4/12/20
to Android-x86
I think this is contained in this commit:

However, I think the right way would have been to whitelist the permissions, as explained here:

Or simply unset ro.control_privapp_permissions

Michael.

Mauro Rossi

unread,
Apr 12, 2020, 5:57:21 PM4/12/20
to Android-x86
Thanks a lot and congratulations for the successful porting
Mauro

Francescodario Cuzzocrea

unread,
Apr 13, 2020, 3:50:07 AM4/13/20
to andro...@googlegroups.com
Thanks to you for pointing me out how to grab the logs !

This should be the proper fix for the priv-app permission thing :

https://gitlab.com/lineageos-x86/android_vendor_lineage/-/commit/3676a7e8be917dced02350cf9dee3a1a7b4b8f06

Il giorno dom 12 apr 2020 alle ore 23:57 Mauro Rossi <issor...@gmail.com> ha scritto:
Thanks a lot and congratulations for the successful porting
Mauro

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/4dd1290e-eda4-4a11-ae7a-247b0bdb55d1%40googlegroups.com.

Harkaman

unread,
Apr 13, 2020, 5:05:03 AM4/13/20
to Android-x86
sorry for the off topic. Can I have ISO file/ can you please share ISO for test?


On Monday, April 13, 2020 at 9:50:07 AM UTC+2, Francescodario Cuzzocrea wrote:
Thanks to you for pointing me out how to grab the logs !

This should be the proper fix for the priv-app permission thing :

https://gitlab.com/lineageos-x86/android_vendor_lineage/-/commit/3676a7e8be917dced02350cf9dee3a1a7b4b8f06

Il giorno dom 12 apr 2020 alle ore 23:57 Mauro Rossi <issor...@gmail.com> ha scritto:
Thanks a lot and congratulations for the successful porting
Mauro

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.

Francescodario Cuzzocrea

unread,
Apr 13, 2020, 5:19:42 AM4/13/20
to andro...@googlegroups.com
Hi, I cannot share an ISO ATM as I am still doing experiments, I would like to try to link ffmpeg to Intel libmfx to try to have hw acceleration at least on Intel.

You can try blissos however, which is still based on Android Q :)

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/556ed530-35ae-4313-ab71-026788cd7243%40googlegroups.com.

Michael Goffioul

unread,
Apr 13, 2020, 8:07:27 AM4/13/20
to Android-x86
I suppose you already know that, but stagefright-plugins has support for VA-API on Intel. For the record, Intel's hw acceleration layer has never on my (older baytrail) hardware; it probably works fine on newer ones, though.


Francescodario Cuzzocrea

unread,
Apr 13, 2020, 9:48:16 AM4/13/20
to andro...@googlegroups.com
thanks for the reply ! I didn't knew that.

I was thinking about building ffmpeg with support for intel media sdk (https://github.com/Intel-Media-SDK/MediaSDK/wiki/Build-and-use-ffmpeg-with-MediaSDK

what do you think about it? would be worth it ?


Michael Goffioul

unread,
Apr 13, 2020, 11:14:38 AM4/13/20
to Android-x86
It's unclear what you'd gain using libmfx, which in the end also uses va-api, compared to ffmpeg using va-api directly. Maybe you have support for more codec, or can reach better performances. At the same time, my experience with Intel's MediaSDK has been that Intel only targets newer generations of hardware, so it's been a no-go for me. Still, it may be an interesting experience; you might also need to adapt stagefright-plugins to use the qsv codecs.

Michael.

Francescodario Cuzzocrea

unread,
Apr 13, 2020, 12:03:01 PM4/13/20
to andro...@googlegroups.com
thanks for the feedback. then I guess would be a nogo also for me as my testing hardware is and old baytrail tablet.

also, speaking about baytrail, does suspension work on your testing hw ? After getting in touch with hans de goede, with his help I was able to make it half working on my tablet (aspire switch 10 sw5). The tablet now is capable of suspending, but it does not resume.



Michael Goffioul

unread,
Apr 13, 2020, 12:11:50 PM4/13/20
to Android-x86
I don't think it works either on my hardware (it's a custom hardware, not a tablet), but at the same time I'm not using suspend/resume, because my hardware must be kept always alive. What I've noticed though, when using stock Android-x86, is that device goes to sleep after configured timeout in the settings, but trying to being it back does not work and the device goes back immediately to sleep (I can see the device turning on, then turning off; there's also a typical clicking sound when my device powers off). I haven't investigated, but it looks like somehow Android (or some other component) still thinks the device should be in stand-by and puts the device back to sleep right away. It's just a guess, though.

youling 257

unread,
Apr 13, 2020, 1:25:46 PM4/13/20
to Android-x86
2GRAM32G Bay trail tablet too slow run on 9.0/10.0 than cm14.1, not mesa problem, cm14.1 mesa19 faster than 9.0 mesa19.
a other problem is android 9.0 lmkd, i only open four chrome tab, background progress killed. cm14.1 can open ten chrome tab.
I ported linux mainline kernel with cm14.1 in these years for Hans big BYT/CHT work, sound、battery、backlight、headphone jack、suspend s0i3、dwc3 gadget.
it's a pity that camera not support, linux kernel give up atomisp camera.

Francescodario Cuzzocrea

unread,
Apr 13, 2020, 3:04:50 PM4/13/20
to andro...@googlegroups.com
Alright, thanks for the clarifications.

Do you know how one can debug this kind of issues ? 

Francescodario Cuzzocrea

unread,
Apr 13, 2020, 3:09:42 PM4/13/20
to andro...@googlegroups.com
Hi youling !!

To be honest android Q runs pretty smooth and snappy on this device even with Chrome.
That is the kernel I am using : https://gitlab.com/lineageos-x86/android_kernel_common/-/commits/lineage-17.1-switch10/

About camera and atomisp, I asked hans about that but he didn't answered. I even tried to forward port atomisp driver and got it compiled and the module loads fine on 5.6 https://github.com/fcuzzocrea/kernel_common/commits/q-x86-switch10

unfortunately however, it seems that my camera model needs some firmware or stuff which I do not have, nor I have enough skill to debug it further without the help of a more expert person

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

Michael Goffioul

unread,
Apr 13, 2020, 3:15:47 PM4/13/20
to Android-x86
First thing would be to check the logs. Best is to boot in debug mode, so that /data/log.txt is generated, and make sure /data is some kind of persistent storage (e.g. booting in LIVE mode uses tmpfs for /data, so that's not gonna help). Assuming that the device does _something_ when you attempt to resume, there's a chance there are some log entries that will tell you what it's trying to do. So I would boot in debug mode, suspend, resume, note the time of resume attempt, reboot, grab the logs.

Julian Nischler

unread,
Apr 13, 2020, 3:41:48 PM4/13/20
to Android-x86
Well done !!!
Looking forward seeing more of this.

Francescodario Cuzzocrea

unread,
Apr 16, 2020, 7:32:09 AM4/16/20
to Android-x86
Some news.
I was able to get suspend resume working using VULKAN and GBM GRALLOC.

I also tried to build ffmpeg with quicksync support. It compiled, but I do not know whether it works or not as I guess my bay trail hw is not compatible.
this is what I did : 

https://gitlab.com/lineageos-x86/android_external_ffmpeg/-/commit/c746acfcfbf7420e00914909d573d41fe79f510b

using https://gitlab.com/lineageos-x86/android_hardware_intel_mediasdk/-/commit/2de2638d984c44f6a919ae0fd25785cdc33b9227

and adding :

USE_MEDIASDK := true
BOARD_HAVE_MEDIASDK_OPEN_SOURCE := true
BOARD_HAVE_OMX_SRC := true

Il giorno lunedì 13 aprile 2020 21:15:47 UTC+2, Michael Goffioul ha scritto:
First thing would be to check the logs. Best is to boot in debug mode, so that /data/log.txt is generated, and make sure /data is some kind of persistent storage (e.g. booting in LIVE mode uses tmpfs for /data, so that's not gonna help). Assuming that the device does _something_ when you attempt to resume, there's a chance there are some log entries that will tell you what it's trying to do. So I would boot in debug mode, suspend, resume, note the time of resume attempt, reboot, grab the logs.

On Mon, Apr 13, 2020 at 3:04 PM Francescodario Cuzzocrea <francescoda...@mail.polimi.it> wrote:
Alright, thanks for the clarifications.

Do you know how one can debug this kind of issues ? 

Il lun 13 apr 2020, 18:11 Michael Goffioul <michael...@gmail.com> ha scritto:
I don't think it works either on my hardware (it's a custom hardware, not a tablet), but at the same time I'm not using suspend/resume, because my hardware must be kept always alive. What I've noticed though, when using stock Android-x86, is that device goes to sleep after configured timeout in the settings, but trying to being it back does not work and the device goes back immediately to sleep (I can see the device turning on, then turning off; there's also a typical clicking sound when my device powers off). I haven't investigated, but it looks like somehow Android (or some other component) still thinks the device should be in stand-by and puts the device back to sleep right away. It's just a guess, though.

Chih-Wei Huang

unread,
Apr 23, 2020, 10:54:40 PM4/23/20
to Android-x86
Hi Francescodario,
Thank you for the LineageOS x86 porting and
congratulation you made it work.
I'll invite you to the android-x86-devel group.
Let's discuss further plans there.


Best regards,
Chih-Wei

Jose Luis s

unread,
Apr 30, 2020, 5:38:43 PM4/30/20
to Android-x86
Hello.

Will this port be integrated into Android-x86 releases as were CM versions some ago?.

I can't wait to test a working iso.

AyushTheHostage

unread,
May 7, 2021, 3:36:42 PM5/7/21
to Android-x86
Do I have to build the iso in linux?
Reply all
Reply to author
Forward
0 new messages