Database Users

[Q] ROMs using JustArchi's optimizations

Hello
I was wondering if there are any Nexus 4 ROMs using JustArchi's optimizations (link). I did my best to compile OmniROM with these fixes, but I am not very experienced with Android development.

+1 to this post

Looks like our devices are too fast to use these "insignificant" compiler optimizations
I'll give my 5 cents these days to try compiling it..
Cheers

+1 for this thread.. I asked just the same thing in the general Q&A thread and nobody answered.. I'd like to see CM, ParanoidAndroid...etc.. built with ArchiDroids optimizations..

Like to see that too!
I've been searching for a rom with f2fs support + JustArchi's optimizations. Can be possible?

I created a topic earlier here
opssemnik said:
i can tell from personal experiences, its mostly placebo, tried archi´s rom on my gs3, and aside from the fact that the google camera dosent crash after first shot(witch occors on alot of roms ,even official cm, again on my s3), the rom is same speed, if not less than official cm. (on my s3 i9300)
Click to expand...
Click to collapse
Nevertheless, there are other statements that say it is faster, we can only know for sure if we benchmark this and find someone willing to compile a rom. Perhaps @legolas93 is willing to be so kind?

joefso said:
I created a topic earlier here
Nevertheless, there are other statements that say it is faster, we can only know for sure if we benchmark this and find someone willing to compile a rom. Perhaps @legolas93 is willing to be so kind?
Click to expand...
Click to collapse
yeah i saw those,luck for them, thats why best rom threads are not allowed on xda, people get different results on their devices ,i plan to compile aosp with those just to test on the n4, but i doubt i will :/

No one is going to try this anytime soon.
The code is no where near perfect and it sets up an environment where there is a lot of room for errors which will result in VERY bugy, glitchy, crashing Roms.
The code is really sloppy and so far only JustArchi is the only one that has successfully used this in a ROM with out error.
There is still a lot of going back and forth in whether this really works since android isn't 90% thumb
All this is good for is benchmark scores. Just like F2Fs its all placebo in real world performance.
With a quadcore 2 gig phone... You're not missing much.
Legecy devices will benefit in the least from this.
Sent from my SM-T217S using Tapatalk

First build is ready!
It is mako-userdebug.
I used Linaro toolchain(JustArchi's link) and JustArchi "JustArchi's ArchiDroid Optimizations V3" - https://github.com/JustArchi/android_build/commit/d8cc50d2472e497b431b5652516c9248ad7f3947
It is without Gapps (so PA Gapps must be used).
Build Env :
Debian GNU/Linux testing (with make downgraded from 4.xx because AOSP lunch require this).
AOSPA soruces 4.4.2_r1 used for the build.
No ART patches! ART will fail if you try using it.
Will test this today on my phone, and if successfully boot, I'll post a link for the ROM.
p.s : From back these days, where people find that AMD64 arch is here, Linux builds started to optimize the speed of your GNU/Linux for your specific CPU (Gentoo for example, or Debian GNU/Linux moved from i386 to i686 and after that to AMD64). Well, the tests and builds performance charfs finished with this : improvement of the speed was was something like 0.6/0.9% ... So in the real world reality do not expect much from this!
Regards ...
Edit:1
Boot failed
Next time, I'll enable the proprietary drivers in the build.
Currently new build is running with enabled prop drives settings like:
Source:http://nosemaj.org/howto-build-android-nexus-4
To use these proprietary files, comment out this line in device/lge/mako/full_mako.mk:
#PRODUCT_RESTRICT_VENDOR_FILES := true
Cheers!

Newsmy Carpad NU3001 CM13 ROM

Hi,
So as many of you already knew - I'm working on porting CM13 onto my NU3001.
I has it on my desk table, so I could work on it during my days. (I have another NR3001 installed in my car)
I already made some work for our unit SW. This is quick screenshots. Sources based on xdAuto and CM13. This is a very BETA and many things not working for now.on.
Why? : When I realize than CyanogenMod 13 (6.0.1) works on my Motorola XT1080 better than stock - I start thinking of porting CM13 to our device. And when I have spare set - I start porting.
How? : I took easiest way - try to do not modify kernel a lot, instead adopt bionic and other libraries for out 3.0.36+ kernel.
Currently working staff (it is very beginning):
1. Recovery TWRP 3.0.2
2. CM13 (LineAge OS) booting.
3. Graphics working (there is some blinking present).
4. Wifi working
5. Android audio working
6. Bonovo Radio working
4. Most of the rest is on the way (GPS, BT, rest of Bonovo apps)
UPDATE_1:
I decide to do not stuck with CM 13 and switch to AOSP N release (7.0) (mostly because on my daily job - we also going to Android N, so it should be more familiar to me now)
Currently working staff:
1. Recovery TWRP 3.0.2
2. SELinux needs to be carefully ported (kernel part), cause starting from 7.0 is can not be disabled (as I did for CM13 to easy port)
During this port I will try to minimize inpact to AOSP release, so any future updates should be much more easier.
For you to understanding of amount of needed work - kernel already has 100+ patches on top of xdauto release. Approximate left about 250-300 patches to revise/port.
Android 7.0 port abandoned because of bigger and bigger amount of work need to be done to port SELinux on top of our outdated kernel.
UPDATE2:
I setup review build environment, so who want to look at NOT-FULLY-WORKING CM13 could download sources and binaries. I do not provide instructions how to flash it, because who wants to look and contribute already know hot to flash, and who doesn't probably don't really want this NOT-FULLY-WORKING CM13
UPDATE3:
So I finally managed to get functional networking. So now Wifi working, internet working, display working.
I starting to port all necessary items. No more 'hard' showstoppers so far.
New build (I believe it is build number 5) should be ready in an our on build server, so I could test it more fully.
UPDATE4:
Cause CyanogenMod is no more maintained - switched to it's successor Lineage OS 13.0, starting from build 8
UPDATE5:
Build number 15 has working audio + radio
UPDATE6:
Most of Bonovo changes ported, new build 20 ready.
This build contains zip file which should be flashable via twrp, but I not test it this way.
Issues remaining so far(most noticeable to me):
1. Display flickering (my suspect is to vsync/fence mechanism slightly changed in Android 6.0, need to investigate)
2. HW Volume buttons not working on device
3. No audio In
UPDATE 7:
Starting from build 23 following images available:
cm_rk3188-ota-XX.zip - update to use via TWRP
nu3001-la-cm13-XX-userdebug.tar.gz - build image for flash via command line rkflashtool under linux (full or partial flash)
rkflash_nu3001-la-cm13-XX-userdebug.zip - Full image to be flashed via PC GUI RK Batch Tool.
kernel_nu3001-la-cm13-XX-userdebug.tar.gz - just kernel with debug symbols for debugging purposes.
To just download sources:
repo init -u https://gerrit.nc.org.ua/manifest -b nu3001_cm13
If you plan to contribute - login to Gerrit with GMail, push your SSH public key, choose login name and then do:
repo init -u ssh://<user>@gerrit.nc.org.ua:29418/manifest -b nu3001_cm13
Builds will be available on Jenkins build server (login also via GMail, PM for access grant on current project stage):
https://jenkins.nc.org.ua/
1.5 GB folder on MEGA
4 files
mega.nz
Please do not spoof this thread with questions like "When?", I will try to post updates regularly in this message.
This thread created is mostly to exchange experience with this build once it is published (issues, TODOs, etc)

**Reserved **
First!

Second! Lol
I'm not a developer so unfortunately I can't contribute, but hopefully those who can will.
At the very least I can beta test when its a little more complete.

Android port system less complicated than the application Bonovo.app and MCU. Good luck and patience.

Black're a legend !!
Your project is great !!! see Android 6.0 on Carpad would be great.
Thanks for the great effort you make for all

Woooow great !!
Good luck

nice one, i hope a very important feature:
"that can be use apps, which require android +4.4.4, like lollipop"
I say that because android auto "stand alone" coming soon, so if will be possible install this app in the radio, we have android auto pure, ( not automate that is awesome but is not the same like original ), and maybe mp3 stuttering from usb can be solved in this rom.
keep up work!

Thanks for the sneak peak, looks promising. I'll gladly help sponsor a new device if you happen to brick yours. I love this headunit and how far the community has gotten in supporting it.

I want to buy NU3001 now, is there any way to get it?

vivacious said:
I want to buy NU3001 now, is there any way to get it?
Click to expand...
Click to collapse
NU3001 or ROM ? if you want NU3001 - you should go to aliexpress from wiki link. If ROM - it is not ready yet. I have half-working CM13.0 - no connectivity working (wifi, bt) so it is useless for now, and Android 7.0 porting in progress.

VBlack said:
NU3001 or ROM ? if you want NU3001 - you should go to aliexpress from wiki link. If ROM - it is not ready yet. I have half-working CM13.0 - no connectivity working (wifi, bt) so it is useless for now, and Android 7.0 porting in progress.
Click to expand...
Click to collapse
I want NU3001 because it has hdmi option. But check in aliexpress newsmy store said it is no production now. Is there someone have stock?
---------- Post added at 01:48 AM ---------- Previous post was at 01:43 AM ----------
VBlack said:
NU3001 or ROM ? if you want NU3001 - you should go to aliexpress from wiki link. If ROM - it is not ready yet. I have half-working CM13.0 - no connectivity working (wifi, bt) so it is useless for now, and Android 7.0 porting in progress.
Click to expand...
Click to collapse
I want NU3001 because it has hdmi option. But check in aliexpress newsmy store said it is no production now. Is there someone have stock?

vivacious said:
I want NU3001 because it has hdmi option. But check in aliexpress newsmy store said it is no production now. Is there someone have stock?
Click to expand...
Click to collapse
I just put NU3001 to aliexpress search bar and found a lot of propositions, I think there should be available one.

Hi VBlack,
it's nice to know you're making progress on the new ROM CM13. All are rooting for you !! Your work would be wonderful !!
I have only one question:
With the ROM of XDAuto I found an annoying problem that occurs when i turn off and then relight the Carpad.
When the power back very often the Carpad car remains with black screen until i touch it with my finger.
I think the problem is somehow related to the USB ports.
Even with your ROM does this happen ?? When you turn on the car, the Carpad remains ever with black screen ??
Thank you!!

VBlack said:
NU3001 or ROM ? if you want NU3001 - you should go to aliexpress from wiki link. If ROM - it is not ready yet. I have half-working CM13.0 - no connectivity working (wifi, bt) so it is useless for now, and Android 7.0 porting in progress.
Click to expand...
Click to collapse
Do you have your efforts posted on github anywhere? Would you mind doing so?
There is a chance I may be working on these devices again after all, and having a working CM provides a *LOT* of possibilities. Namely the Theme engine.
If you would be willing to post your work, I'm sure there are a handful of us who could help with the port.
Thanks,

Zaphod-Beeblebrox said:
Do you have your efforts posted on github anywhere? Would you mind doing so?
There is a chance I may be working on these devices again after all, and having a working CM provides a *LOT* of possibilities. Namely the Theme engine.
If you would be willing to post your work, I'm sure there are a handful of us who could help with the port.
Thanks,
Click to expand...
Click to collapse
Nice to hear from you. Sure I will share. Current situation is next:
CM13 - no wifi (looks like netfilter from userspace not match netfilter from our outdated kernel), no selinux (completely disabled), and increased system partition to be able to add opengapps, twrp - works.
AOSP 7 - it is strongly rely on selinux, so i could not just disable it, and now I'm trying to merge new selinux with our old kernel...
So, i will upload CM13 in current state, and continue on aosp 7, if i fail with aosp 7 i will back to cm13. This is current plan.
Sent from my DROID MAXX using Tapatalk

Zaphod-Beeblebrox said:
Do you have your efforts posted on github anywhere? Would you mind doing so?
There is a chance I may be working on these devices again after all, and having a working CM provides a *LOT* of possibilities. Namely the Theme engine.
If you would be willing to post your work, I'm sure there are a handful of us who could help with the port.
Thanks,
Click to expand...
Click to collapse
I update first post with sources and build information

@VBlack, you mention "our outdated kernel". Does this imply that the kernel sources aren't available? I am very interested in this project because I am looking for a head unit with fully update firmware that can be kept up to date with security patches, and some of the Android security patches include the kernel (e.g. the recent "dirty cow" vulnerability).

shatteredsilicon said:
@VBlack, you mention "our outdated kernel". Does this imply that the kernel sources aren't available? I am very interested in this project because I am looking for a head unit with fully update firmware that can be kept up to date with security patches, and some of the Android security patches include the kernel (e.g. the recent "dirty cow" vulnerability).
Click to expand...
Click to collapse
No, we have kernel sources, but our kernel version 3.0.36 and looks like nobody release Android kernel 3.14 or 3.18 for rk3188. 3.14 and 3.18 mostly used in Android M and N. So combining Android M or N with such outdated kernel is not a trivial task. Because of this incompatibility we currently have all networks issue on this CM13 project.

Kernel 3.0.36 is 4.5 years old. The 3.0 branch is no longer maintained with security patches, and hasn't been maintained in over 3 years. There have been numerous security exploits in the Linux kernel since then, many of which are applicable to Android. Is it worth even persevering with this under such an extreme kernel constraint?

shatteredsilicon said:
Kernel 3.0.36 is 4.5 years old. The 3.0 branch is no longer maintained with security patches, and hasn't been maintained in over 3 years. There have been numerous security exploits in the Linux kernel since then, many of which are applicable to Android. Is it worth even persevering with this under such an extreme kernel constraint?
Click to expand...
Click to collapse
You'd be surprised how many phones in the market use old kernels (3.0 is not too old for Android - it is about 2-3years off from active development).. But true is that Android kernel despite it's version less vulnerable than Desktop one, and has many fixes included (it is does not increase kernel version, like mainline kernel). Because of this it is generally hard to say which security issue will be there for sure. But on the other hand Android N and Android M has SELinux enabled, and Android N could not have it disabled. It is dramatically increase overall security of the system. But for the most of traditional Android user kernel exploits does not produce many harm - it is not a corporate server with sensitive information. And many of them used to obtain root on bootloader locked systems.
So generally for what I have in mind:
1. If succeeded just with CM13 - I have disable SELinux there - it is will be not less secure than original 4.x release - just system/google components will be upgraded, which allow us use modern UI features from Android M, and also adds more compatibility with new applications revisions.
2. If succeeded with AOSP 7.0 - SELinux will be enabled there, so we will have security addition on top of old kernel, which actually will increase security alongside allowing UI features from Android N.
So in any case it is very nice to have.

Android Oreo 8.0 / Lineage 15.0 Dev Discussion

Currently on hold due to working on Nougat first.
I've got a booting or should I say bootlooping build of Lineage 15.0 for I9000. (galaxysmtd)
I've had to use crazy hacks like adb binary from 7.1 in ramdisk.
Just to get `adb logcat` working.
For now it's stuck at bootlogo. I've attached the logcat here.
I'm looking into it to figure out what needs to be done.
Sources:
manifests and patches I've used.
https://github.com/galaxys1-resurrected/local_manifests
https://github.com/galaxys1-resurrected/android_patches
Kernel:
https://github.com/galaxys1-resurrected/android_kernel_samsung_aries
Device Tree:
https://github.com/galaxys1-resurrected/android_device_samsung_aries-common
https://github.com/galaxys1-resurrected/android_device_samsung_galaxysmtd
Thanks:
@rINanDO for backporting kernel side of things to 3.0
@xc-racer99 and @Coldwindofnowhere for getting the device upto android 7.1
And all others who had worked from beginning till now on this device.

Is there anyone still working on this?
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.

a1shakes said:
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.
Click to expand...
Click to collapse
Unfortunately, no one is really actively working on Oreo. As you've found out, it's an issue with the graphics drivers that is holding everything back. No device (that I've found) that uses a PowerVR graphics chip (we use the PowerVR SGX 540) has working graphics drivers on Oreo. There were rumours that someone had found newer working blobs, but weren't able to release them publicly due to intellectual property laws that they were trying to figure out (but this was months ago).
Our GPU does support sufficient enough OpenGL, but only using BGRA8888 as opposed to RGBA8888. BGRA hasn't officially been supported in Android since ~4.2, but there's been a hack used to make things work. Come Oreo, things have changed and the hack no longer applies cleanly. However, I think the really issue is that the gralloc blobs was extended by PowerVR (see https://github.com/xc-racer99/andro...6.0/exynos3/s5pc110/include/hal_public.h#L119) but with the binderized HALs/VNDK/other low-level Oreo changes something has broken. I had a go at trying to work around things, but failed too.
There are a few ways I can think of getting working graphics:
1) Someone finds some updated blobs for the PowerVR SGX 540 for ARM (I've found x86 ones, but they don't work for obvious reasons)
2) Someone hacks around the source code so that the blobs work - but I'm not sure if it's PowerVR "extension" of the gralloc interface that is causing issues or not...
3) We simply use software rendering, but this would be so slow with our ancient CPU that I haven't bothered to try
4) We work on porting a newer kernel so we have the Samsung DRM kernel driver, use the Linux PowerVR blobs coupled with drm_gralloc/drm_hwcomposer and maybe a wrapper like https://github.com/TexasInstruments/dri3wsegl and somehow cobble together working support
In terms of the mediaextractor crash, that's due to the kernel missing seccomp support. There's a whole bunch of different backports, some more successful than others. Due to our ancient kernel, backporting is no longer very easy...
If we could somehow get the graphics drivers working, we'd have a pretty good base as there are free implementations of all HALs/drivers except for GPS and TV-Out (and, of course, graphics....).

Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?

nailyk said:
Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?
Click to expand...
Click to collapse
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.

xc-racer99 said:
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.
Click to expand...
Click to collapse
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.

nailyk said:
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.
Click to expand...
Click to collapse
If you're serious about trying to mess with graphics drivers, it might be interesting to check out the blobs from https://www.renesas.com/pt-br/produ...ion-boards/renesas-starter-kit-for-rzg1e.html as it's an ARM-based device with the SGX540. It's possible that they're new enough to not run into the same issues as the older blobs (but equally possible that even the kernel part is closed source). The binary blobs are only semi-SoC specific as I've managed to use the OMAP blobs with only having hardware decoding being broken.

Is it for real???
I9000 !!

Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490

Use android go it will be better.

MYEUHD said:
Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490
Click to expand...
Click to collapse
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time

xc-racer99 said:
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time
Click to expand...
Click to collapse
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).

xc-racer99 said:
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).
Click to expand...
Click to collapse
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
ChronoMonochrome said:
In 9.0, to get graphics to work, device is required to support HWC2 (or use either HWC2on1 or HWC2onFb adapters).
Click to expand...
Click to collapse
ChronoMonochrome said:
Yes, HWC has to be at least 1.3, to work with one of aforementioned adapters. With one of those adapters it will work like it was HWC 2 (but actually not exactly same).
Click to expand...
Click to collapse
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung

MYEUHD said:
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung
Click to expand...
Click to collapse
Was unaware of the fact. Are you volunteering to make the patches?
I've uploaded my changes to https://github.com/xc-racer99/proprietary_vendor_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_hardware_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_kernel_samsung_aries/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_telusgalaxys4gmtd/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_aries-common/tree/ddk-1.14 but I think this might be the last I work on this as I don't really have the motivation to work on it anymore. Note the patches are against a custom version of Unlegacy Android 4.4 so you'll need to cherry pick the changes to your ROM of choice if desired.
The changes build, the EGL appears to initialize, but I always get
Code:
E/libEGL ( 471): validate_display:254 error 3008 (EGL_BAD_DISPLAY)
And in dmesg:
Code:
[ 8.509291] init: computing context for service '/system/vendor/bin/pvrsrvinit'
[ 8.509601] init: starting 'pvrsrvinit'
...
[ 8.601890] PVR_K: UM DDK-(4081762) and KM DDK-(4081762) match. [ OK ]
...
[ 8.765955] init: process 'pvrsrvinit', pid 99 exited
...
[ 55.560021] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.563491] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.597577] s3cfb s3cfb: [fb0] video memory released
Whether the issue is in the HWC or the gralloc blob that we've stolen from OMAP, I have no idea.

xc-racer99 said:
Was unaware of the fact. Are you volunteering to make the patches?
Click to expand...
Click to collapse
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??

MYEUHD said:
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??
Click to expand...
Click to collapse
You really do need jdk-7... I used the "reference implementation" available at http://jdk.java.net/java-se-ri/7 and made sure the java executables were in the PATH before the java I actually have installed.
Note that my Unlegacy Android trees will not work for the i9000 (well, they might, but you'd need to install u-boot as well at a bare minimum...)

It's kinda Insane that people are trying to get an 8 year phone to run oreo

@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?

MYEUHD said:
@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?
Click to expand...
Click to collapse
I've got the .repo folder, but don't have the individual files expanded as I don't have the disk space Could run a repo sync and look at things but don't have the disk space for a full build.

The_Pacific_gamer said:
It's kinda Insane that people are trying to get an 8 year phone to run oreo
Click to expand...
Click to collapse
its kinda insane that people are still using this phone.

Bake AOSP Pie for Xperia XZ?

Hi all!
As Sony has posted instructions on how to compile Android Pie for our XZ (among others), I just wondered if anyone here has tried it?
The posted guide looks quite straight forward, but as I have no experience on using fit-repost and such I'm not sure I'm up for the challenge of taking this project on.
If tried, what could be expected to work? I know that for all previous Xperia devices, camera and wifi components has always been weak-points in AOSP-roms..
Please discuss and advice!
Regards, Static.

I'm currently trying to build android P for XZ with the guide from Sony.
I'm downloading the code ATM.
I'll give you feedback about my journey to Pie ^^

Awesome!
I'm eager to hear about your endeavors in this!

L'ily said:
Hey me too, do you have a single- or dual-SIM variant?
Click to expand...
Click to collapse
I have a single sim variant

L'ily said:
Nice, I have the F8332 so we can test on both models. I have no idea what I'm doing though and whilst an unofficial GApps 9 build is available (albeit only in Stock) it doesn't appear Sony have released the vendor images yet so even if we successfully build I'm disinclined to believe they'll boot, although I'm going to try with the last release anyway.
Click to expand...
Click to collapse
Didn't Sony released beta vendor images for kernel 4.9 ?
I thought that would be compatible with pie.
That being said, it should be bootable without it. We will just have to check the kernel version and flash the vendor image accordingly.

@L'ily and I have been trying to build Pie for F8331 and F8332 but sadly it didn't work ...
The first issue we had was with the repo syncing. On my end it took an incredible 48h (@400KB/s peak) and also failed 3 times but by relaunching it I made it to the end. My partner however had a worst yet faster time with syncing. Maybe it is due to localisation (Australia and France) . We think it is simply because the repos weren't ready. I mean they are still no vendor files for Pie.
Second issue was with building. None of us could get through it. We kept having an error (see screen shot). It seams like it is a file missing but we didn't know we're to look for it as the sync was complete.
We tried both engendering build and userdebug. Same error.
@L'ily also tried build Oreo but it didn't work either ...
If anybody has an input on what we could do we would be grateful
Cheers,
Ickule

Here is the screenshot I mentioned in my previous post.
I forgot to include it ...

Ok so I managed to get through the building process. The missing files have matching name with files in an other folder (4.4 instead of 4.9).
That being said it sadly didn't boot.
That was kind of expected if you ask me ^^'
Still I don't get why i didn't had the files in the first place ...
Any input guys ?

I'm currently trying to build Pie myself (for the 309234023492094th time in the last two days) with other errors every time I set up a new machine. But what I can say about the error with the missing kernel file is that there's a script in the sony repos that looks like it'd be building the missing file, although I'm not sure if we have to call it manually first

31, so single-sim and unfortunately, I don't have the logs anymore as I always started with fresh machines.
I'm currently checking the other forums because I'm not really satisfied with the solution of using 4.4 kernel binaries with a 4.9 build
Edit: I might have achieved something, I compiled the kernel from 4.9 sources I hope and it's now building. Fingers crossed ?
Edit 2: It boots!

I definitively agree on the fact that using 4.4 files aren't optimal for a 4.9 build ^^'
I tough of compiling the kernel before hand.
Let us know how it turns out
However I'm puzzled with 31 as being the choice for F8331. On my laptop it's 55 (engeneering build). 31 Being marlin userdebug.

Ickule said:
I definitively agree on the fact that using 4.4 files aren't optimal for a 4.9 build ^^'
I tough of compiling the kernel before hand.
Let us know how it turns out
However I'm puzzled with 31 as being the choice for F8331. On my laptop it's 55 (engeneering build). 31 Being marlin userdebug.
Click to expand...
Click to collapse
That's exactly what I did and it seemed to work
With 31, I meant F8331
Edit: I think I chose 56 or so, it was the userdebug option for F8331

Magic-Fabi said:
That's exactly what I did and it seemed to work
With 31, I meant F8331
Edit: I think I chose 56 or so, it was the userdebug option for F8331
Click to expand...
Click to collapse
So you managed to get Pie working or only compiling the kernel ?
Thanks for clarifying the 31 thing

Yes, Pie booted on my device! But no gapps or camera, for that we'll have to wait

Xperia z1 has carbon Android pie and gapps link
This may help you.

Magic-Fabi said:
Yes, Pie booted on my device! But no gapps or camera, for that we'll have to wait
Click to expand...
Click to collapse
That's awesome !
Did you dio anything special aside from the instructiosn sony gave ?
I try to build Pie and the Kernel by the books but i always seam to fail for some reason ^^'
I'm usung Ubuntu 18.04 for the building OS.

No, all I used was Sony's guide and referenced Google's build instructions for the libraries I have to install. For the missing kernel file I used their (manual!) Kernel compilation guide
I used Ubuntu 18.04 LTS as well, the only "unusual" thing I did was that I didn't install any openjdk version and even deleted the one preinstalled as they have openjdk bundled with aosp ?*
Edit: Note that you have to copy and rename the compiled kernel file in arch/arm64/boot/Image.gz-dtb to kernel-dtb-kagura in /kernel/sony/msm4.9/common-kernel. You can easily read past that as I did in the beginning

Well let's assume I had a bad syncing time or something cause I followed the very same instructions ^^'
Anyway, it seam like we still miss the vendor files from sony so ...
I'll give it another shot when they'll be out.

Just a curious thing, will GCam work on Pie like it did on AOSP Oreo?

I believe the requirement for GCam is Camera API 2 and raw support which is built into AOSP.
It surely will be compatible.

[SOLVED!] Bluetooth doesn't work after compiling a kernel based on LOS 18.1 sources.

I'm kinda new here, so please excuse me if this is not the best place to ask and it should instead be posted in another section.
First, a bit of context: I recently bought a refurbished H910 to practice android development since it was fairly cheap, and after testing its features and unlocking the bootloader to install custom roms, i opted to start compiling a kernel of my own with some changes to begin involving myself with the development side of things. For now, i am using the Lineage OS 18.1 kernel sources on github as a base for the kernel, then after making sure that the kernel compiled, i flashed it into the phone and basically everything works with the only exception being the bluetooth, and maybe the IR Blaster, but that one is working just like the stock kernels on different Android 11 roms.
Now getting to the issue itself in more details... it boils down to the phone's bluetooth refusing to turn on while running that custom kernel of mine on any Android 11 ROM, be it Lighthouse, Superior OS Xcalibur or Lineage 18.1, the bluetooth tile gets stuck on the "Turning on..." icon animation for a while and then returns to the disabled state. Reverting to the stock kernels or even using other custom kernels like Lyb's or Gamma make the Bluetooth work again without needing a wipe, which tells me that the problem is definitely somewhere in my kernel. I could of course test it on some Android 10 ROMs, but the outcome will most likely be the same.
I even took some logcats via ADB Shell but they are kind of broad and mostly explain that the service had some problems with "com.android.bluetooth service has died: psvc PER", followed by a "scheduled restart of crashed service com.android.bluetooth...". Both of which never happen on those ROM's stock kernels, where the bluetooth works as expected. I looked around on Lyb/Gamma kernel sources on github, and there aren't any major differences to the defconfigs for example with the bluetooth driver configuration also being just about the same.
I'm not sure if this will be of any help, but as for the toolchains and compilers, i am using clang 11.0.2 383902b1 as the main compiler, gcc 4.9 as the ARM32 cross-compiler, and gcc from 4.9 up to 10.3 as the AARCH64 cross-compiler, all running on Manjaro. I also changed that combination dozens of times, but to no avail.
So am i missing something during the compilation process? With all those things i already checked, i keep getting a feeling that something really simple is going over my head. Also, i can post the link to my github repository here if needed, there's a branch made specifically to check the BT since it has only the changes made to assure that the kernel compiles.
Edit: The problem was solved!!! It actually comes down to using the exact toolchains provided by the lineage OS source tree for the device (that might be optional, but it's how i managed to get it working) and checking if everything has been installed correctly. It seems some files failed to download the last time i did a 'repo sync' on the source and that was what might have caused this.