Database Users

Official ICS Beta released for ARC S, Neo V and Ray

I dont really understand why only for this devices but please someone make it work on the Play!
Link: http://forum.xda-developers.com/showthread.php?p=20329850#post20329850

From xperia blog -
The alpha ROM will only work on three Xperia phones: arc S, neo V and ray. For those Xperia arc and Xperia neo users wondering whether they should try this, you are warned not to as the phones have different partition layouts compared to the arc S and neo V.
EDIT- Was meant to explain why it was only for those devices ; they prob have the same partition layout.

Nabeel_Nabs said:
From xperia blog -
The alpha ROM will only work on three Xperia phones: arc S, neo V and ray. For those Xperia arc and Xperia neo users wondering whether they should try this, you are warned not to as the phones have different partition layouts compared to the arc S and neo V.
Click to expand...
Click to collapse
But that does not mean that a dev can not change it a bit to make it work on the play correctly.

im downloading the arcs build now to examine it

i would take al look on this.
Maybe i get it working for the play (would be nice)

nickholtus said:
i would take al look on this.
Maybe i get it working for the play (would be nice)
Click to expand...
Click to collapse
nick extract the kernel from the arcs build and try flashing that with your ICS update.zip
might work!

In the arc forum they confirmed that the arc s build works on the arc. Maybe it works on the play too?

directly flashing the files to play partly works, im working through fixing issues now
edit: ok currently stuck at : D/dalvikvm( 630): GC_CONCURRENT freed 260K, 4% free 9790K/10119K, paused 2ms+3m
s
I/SurfaceFlinger( 647): SurfaceFlinger is starting
I/SurfaceFlinger( 647): SurfaceFlinger's main thread ready to run. Initializing
graphics H/W...
E/HAL ( 647): load: module=/system/lib/hw/gralloc.msm7x30.so
E/HAL ( 647): Cannot load library: link_image[1908]: 647 missing essentia
l tables
E/FramebufferNativeWindow( 647): Couldn't get gralloc module
E/SurfaceFlinger( 647): Display subsystem failed to initialize. check logs. exi
ting...
happens for both sensors and gralloc,

from wich phone are you using the files?
neo v arc s or ray

DJ_Steve said:
directly flashing the files to play partly works, im working through fixing issues now
edit: ok currently stuck at : D/dalvikvm( 630): GC_CONCURRENT freed 260K, 4% free 9790K/10119K, paused 2ms+3m
s
I/SurfaceFlinger( 647): SurfaceFlinger is starting
I/SurfaceFlinger( 647): SurfaceFlinger's main thread ready to run. Initializing
graphics H/W...
E/HAL ( 647): load: module=/system/lib/hw/gralloc.msm7x30.so
E/HAL ( 647): Cannot load library: link_image[1908]: 647 missing essentia
l tables
E/FramebufferNativeWindow( 647): Couldn't get gralloc module
E/SurfaceFlinger( 647): Display subsystem failed to initialize. check logs. exi
ting...
happens for both sensors and gralloc,
Click to expand...
Click to collapse
That means exactly? Also did you use the arc version or the neo v version?

IE-coRe said:
That means exactly? Also did you use the arc version or the neo v version?
Click to expand...
Click to collapse
Edit: haha nick was quicker xD
oh i clicked the quote insetead the edit button. Sorry^^

arc s version, was first one i picked it means its missing something somewhere but im not certain what

But you where able to install it and it boots?

it flashes and attempts to boot but no display due to those errors, but adb is runnind (although i needed to slightly mod boot img to get adb )

okay... doomloard said he will take a look on the play when he is done with the arc. lets hope he can help.

ill keep playing also
---------- Post added at 06:46 PM ---------- Previous post was at 06:45 PM ----------
my modified boot image that forces adb mode rather than mtp is available : http://build.streakdroid.com/bootic.img

maybe you can use neo v (did you replaced files in boot.img with some files from play boot.img?

what files would need replacing, other than for uevent maybe, ill look at that next

............

nickholtus said:
maybe you can try it with this kernel: http://www.multiupload.com/7K22QRYC05
Click to expand...
Click to collapse
what kernel is that and what phone is it for ?

[Q] Python Issues when running a certain application

Hi all! First post to xda-developers, hoping for some assistance with an app that ran fine on stock, now not running on OmniROM. The application is Katawa Shoujo Ver5, the 334MB Monolithic release. I logcatted it down to an error that basically tells me that it cannot open _imaging.so and _sqlite3.so. I researched and found that these libraries belonged to a whole laundry list of 32bit libraries that my python 2.7 does not have. So, I have to figure out how to either add these libs manually or import them into python, how would I go about fixing the issue??
Device: SGH-T999L (T-Mobile)
ROM: OmniROM 4.4.4
Kernel: BMS (Not sure of exact, my phone is dead atm, sorry!) Will Update if needed when I get home
Linux Version: 3.4.y

austinyork1 said:
Hi all! First post to xda-developers, hoping for some assistance with an app that ran fine on stock, now not running on OmniROM. The application is Katawa Shoujo Ver5, the 334MB Monolithic release. I logcatted it down to an error that basically tells me that it cannot open _imaging.so and _sqlite3.so. I researched and found that these libraries belonged to a whole laundry list of 32bit libraries that my python 2.7 does not have. So, I have to figure out how to either add these libs manually or import them into python, how would I go about fixing the issue??
Device: SGH-T999L (T-Mobile)
ROM: OmniROM 4.4.4
Kernel: BMS (Not sure of exact, my phone is dead atm, sorry!) Will Update if needed when I get home
Linux Version: 3.4.y
Click to expand...
Click to collapse
Um, Omni does not include python to begin with, so... Issues you're having with third-party apps missing components (from an Omni perspective, python on a mobile device is a third-party app) aren't something relevant to Omni
Oh yeah, your device is also not officially supported. Even of the d2 family were, an alternate kernel means you have a modified configuration and we're not going to waste time on it. Argue that your issue is kernel-related all you want, it shows that you've modified the system so who knows what else you hacked.

[ARM/ARM64] Android 5.0 Lollipop bootanimation memory leak fix

/* Info */
There's a known issue on Android 5.0 Lollipop.
The bootanimation binary(/system/bin/bootanimation - Responsible for initial boot animations during bootup) causes a serious memory leak, too exhaustive that core system services or other processes can be killed during boot,
or on the worst case, endless boot loop due to core system services unable to initialize.
/* Why? */
My theory is, the current bootanimation implementation does not releases the resources held to play previous frames.
Testing this on a Galaxy S4 with a 1080p bootanimation.zip file resulted in 200MB of RAM usage in 3 seconds, and the kernel starts to kill processes in 10 seconds.
With a Nexus 7, luckily, it did pass on the bootanimation and showed up the lock-screen. However, some services got killed during boot and resulted in an overall unstable system.
I've been able to reproduce this bug on majority of devices including Galaxy Note 3, Galaxy S4, Nexus 7, Nexus 5, Nexus 4 and much more with CyanogenMod 12, Google's pure/stock AOSP and LG's Lollipop firmware.
I'm almost certain that other Android 5.0 Lollipop ROMs may have the same problem(except for Samsung's Touchwiz - Touchwiz uses qmg format and I was unable to reproduce this bug on Touchwiz).
You maybe asking yourself -
"But CM12 has this issue solved?"
Short answer is no, they've just put a band-aid on it - reducing framerate and clearing up caches more aggressively to "workaround", and this is not a permanent solution.
"What about other manufacturer's ROM?"
On my test, Samsung's Touchwiz was the only ROM that has this issue solved(probably thanks to the their proprietary qmg format). Other manufacturers - LG, hTC and more - may also suffer from the same bug.
"Can I expect this fix to be integrated with CyanogenMod 12 nightlies?"
Maybe. I've sent this fix to CyanogenMod Gerrit code review. If they approve it, it'll be integrated into future nightly builds.
/* Solution? */
Before I could have come up with a permanent solution, I suggested users to remove /system/bin/bootanimation from their devices for now, as this is a very serious issue.
Now, I've got a working, permanent fix.
V2 - Much cleaner code & misc fixes with some bootanimation.zip files
The attached "bootanimation.zip" contains 3 binaries.
cm12/bootanimation is for CyanogenMod 12(or its fork) users
aosp/<CPU architecture>/bootanimation is for pure/stock AOSP(or its fork) users & manufacturer's ROM users & Nexus users with stock ROM installed.
<You must install the right bootanimation binary for your device's CPU architecture; users will most likely install 32bit unless they use Nexus 9 or LG G flex 2>
Download the "bootanimation.zip", extract the right "bootanimation" binary and put it under /system/bin - replacing the old one.
The correct owner is root:root,
the correct permission is 755(rwxr-xr-x).
If those binaries do not work for you, I'm afraid your ROM developer/builder have to integrate the fix into the source code, or not use the bootanimation at all
/* Some more technical information */
If you're a ROM developer, who wants to integrate this fix, please read below and cherry-pick the correct fix.
Android Issue tracker - https://code.google.com/p/android/issues/detail?id=140061
CyanogenMod Gerrit code review - http://review.cyanogenmod.org/88968
CyanogenMod Gerrit GitHub - https://github.com/CyanogenMod/andr...mmit/de11ae6610f3c96b07b8e2e1d0dc1531c21ac82f
Android Gerrit code review - https://android-review.googlesource.com/132681

Reserved
Reserved

My thanks limit is 8 thanks per day so I am typing Thanks here I will press thanks button tomorrow

Good I go to test thank bro

Added to my Temasek CM12 BUILD v6.8!!
Thanks

How we that we use stock LG rom can fix this bug???

arter97 said:
/* Info */
There's a known issue on Android 5.0 Lollipop.
The bootanimation binary(/system/bin/bootanimation - Responsible for initial boot animations during bootup) causes a serious memory leak, too exhaustive that core system services or other processes can be killed during boot,
or on the worst case, endless boot loop due to core system services unable to initialize.
/* Why? */
My theory is, the current bootanimation implementation does not releases the resources held to play previous frames.
Testing this on a Galaxy S4 with a 1080p bootanimation.zip file resulted in 200MB of RAM usage in 3 seconds, and the kernel starts to kill processes in 10 seconds.
With a Nexus 7, luckily, it did pass on the bootanimation and showed up the lock-screen. However, some services got killed during boot and resulted in an overall unstable system.
I've been able to reproduce this bug on majority of devices including Galaxy Note 3, Galaxy S4, Nexus 7, Nexus 5, Nexus 4 and much more with CyanogenMod 12, Google's pure/stock AOSP and LG's Lollipop firmware.
I'm almost certain that other Android 5.0 Lollipop ROMs may have the same problem(except for Samsung's Touchwiz - Touchwiz uses qmg format and I was unable to reproduce this bug on Touchwiz).
You maybe asking yourself -
"But CM12 has this issue solved?"
Short answer is no, they've just put a band-aid on it - reducing framerate and clearing up caches more aggressively to "workaround", and this is not a permanent solution.
"What about other manufacturer's ROM?"
On my test, Samsung's Touchwiz was the only ROM that has this issue solved(probably thanks to the their proprietary qmg format). Other manufacturers - LG, hTC and more - may also suffer from the same bug.
"Can I expect this fix to be integrated with CyanogenMod 12 nightlies?"
Maybe. I've sent this fix to CyanogenMod Gerrit code review. If they approve it, it'll be integrated into future nightly builds.
/* Solution? */
Before I could have come up with a permanent solution, I suggested users to remove /system/bin/bootanimation from their devices for now, as this is a very serious issue.
Now, I've got a working, permanent fix.
The attached "bootanimation.zip" contains 3 binaries.
cm12/bootanimation is for CyanogenMod 12(or its fork) users
aosp/<CPU architecture>/bootanimation is for pure/stock AOSP(or its fork) users & manufacturer's ROM users & Nexus users with stock ROM installed.
<You must install the right bootanimation binary for your device's CPU architecture; users will most likely install 32bit unless they use Nexus 9 or LG G flex 2>
Download the "bootanimation.zip", extract the right "bootanimation" binary and put it under /system/bin - replacing the old one.
The correct owner is root:root,
the correct permission is 755(rwxr-xr-x).
If those binaries do not work for you, I'm afraid your ROM developer/builder have to integrate the fix into the source code, or not use the bootanimation at all
/* Some more technical information */
If you're a ROM developer, who wants to integrate this fix, please read below and cherry-pick the correct fix.
Android Issue tracker - https://code.google.com/p/android/issues/detail?id=140061
CyanogenMod Gerrit code review - http://review.cyanogenmod.org/88918
CyanogenMod Gerrit GitHub - https://github.com/CyanogenMod/andr...mmit/6b0cabc4d0a131800bd7ff75f0653e4c0cd7d3a4
Android Gerrit code review - https://android-review.googlesource.com/132562
Click to expand...
Click to collapse
Explains why my new CM12 flashes end up in a bootloop.

I have a Nexus 6. How would I know if I have this problem?

Is there an easy way I can check if this works?
I mean, my phone still boots fine, but I expected to see the sudden frame drops to be gone, but they're still here...

how about using the lollipop bootanim on the older android version like kk. do I need to do the same fix as well ? show me the light please

If this is because Google is using its AnimationDrawable for the bootanimation, then it's part of the half-ass SDK Google is still putting out.
AnimationDrawable loads ALL frames and never releases previous-frames during playback until the entire drawable is unloaded.
You would think after GIF, MPEG, MNG or APNG (animated PNG), SVG, etc, Google wouldn't go back to pre-school raw-frame animations.
edit: looking at the actual patch, that animation GL animation code from Google is pretty bad. Generating a new texture id per frame is stupid, and using only one texture otherwise, is just as bad. It should be 2, or 3 texture ids reused continuously in a ring-buffer, and that's it.
So, removing the GL code at lines 786-791 is bad because it's generating a texture for all the frames that are coming up. Dropping that means it drops all the frames that was going to get used.
Deleting lines 837-841 causes a texture memory id leak, though no texture-memory leak due to lines 786-791 being deleted. I'd agree with comment https://code.google.com/p/android/issues/detail?id=140061#c6
The way "Animation" on line 608 is used, it looks very much like an AnimationDrawable. So this whole thing is typical of Google not having coders that can do proper animation code.

sweet find bro!

arter97 said:
/* Info */
/* Why? */
My theory is, the current bootanimation implementation does not releases the resources held to play previous frames.
Click to expand...
Click to collapse
As long as the loaded frames get reused, this makes a lot of sense, doesn't it?
It's faster to display the frame from memory than to load it again.
As long as the boot animation doesn't get overly large, which it usually doesn't do, this should not be an issue.
Or do I miss something here?

domenukk said:
As long as the loaded frames get reused, this makes a lot of sense, doesn't it?
It's faster to display the frame from memory than to load it again.
As long as the boot animation doesn't get overly large, which it usually doesn't do, this should not be an issue.
Or do I miss something here?
Click to expand...
Click to collapse
https://code.google.com/p/android/issues/detail?id=140061
See before(#7) and after(#8).
The differences are HUGE and #7 is definitely an issue

arter97 said:
/* Info */
There's a known issue on Android 5.0 Lollipop.
The bootanimation binary(/system/bin/bootanimation - Responsible for initial boot animations during bootup) causes a serious memory leak, too exhaustive that core system services or other processes can be killed during boot,
or on the worst case, endless boot loop due to core system services unable to initialize.
.....
/* Some more technical information */
If you're a ROM developer, who wants to integrate this fix, please read below and cherry-pick the correct fix.
Android Issue tracker - https://code.google.com/p/android/issues/detail?id=140061
CyanogenMod Gerrit code review - http://review.cyanogenmod.org/88968
CyanogenMod Gerrit GitHub - https://github.com/CyanogenMod/andr...mmit/de11ae6610f3c96b07b8e2e1d0dc1531c21ac82f
Android Gerrit code review - https://android-review.googlesource.com/132681
Click to expand...
Click to collapse
Thanks man! If I get around to building ROMs I'll include this patch for sure!

arter97 said:
https://code.google.com/p/android/issues/detail?id=140061
See before(#7) and after(#8).
The differences are HUGE and #7 is definitely an issue
Click to expand...
Click to collapse
Sorry, didn't read this earlier. Good find if true.

NuShrike said:
If this is because Google is using its AnimationDrawable for the bootanimation, then it's part of the half-ass SDK Google is still putting out.
AnimationDrawable loads ALL frames and never releases previous-frames during playback until the entire drawable is unloaded.
You would think after GIF, MPEG, MNG or APNG (animated PNG), SVG, etc, Google wouldn't go back to pre-school raw-frame animations.
edit: looking at the actual patch, that animation GL animation code from Google is pretty bad. Generating a new texture id per frame is stupid, and using only one texture otherwise, is just as bad. It should be 2, or 3 texture ids reused continuously in a ring-buffer, and that's it.
So, removing the GL code at lines 786-791 is bad because it's generating a texture for all the frames that are coming up. Dropping that means it drops all the frames that was going to get used.
Deleting lines 837-841 causes a texture memory id leak, though no texture-memory leak due to lines 786-791 being deleted.
Click to expand...
Click to collapse
I'm not a OpenGL expert, I've just messed around the code to find out how to fix it "apparently".
You may wanna go read comments here https://code.google.com/p/android/issues/detail?id=140061 (especially #7 and #8).
Can you come up with a better patch?

I guess I'll cherry-pick this tonight, why not.
We also need this revert, correct? https://android-review.googlesource.com/#/c/132680/1

take note for change owner must be;
0 - root & group 2000 - shell

There is no problem with LG firmware
@arter97 I own a LG G3 updated to latest Lollipop firmware from LG(i.e. official firmware) , and I assure you that this bug has been fixed by LG and everything is working as it should , no bootloops or anything in the normal usage is buggy.

Build-in VPN broken in Nougat 7.0/7.1/7.1.1 - Jiayu S3 Jiayu S3 [MT6752]

Hello,
I'm opening this thread to provide some info about a bug introduced in the nougat releases.
Since 7.0 first release build-in VPN client is broken, any connection end with an error under the menu entry, without any traffic goingout of the device.
Logcat shows a link error un the racoon binary (responsible of ipsec connections):
Code:
12-11 10:16:19.669 3496 3496 F libc : CANNOT LINK EXECUTABLE "/system/bin/racoon": cannot locate symbol "DES_is_weak_key" referenced by "/system/bin/racoon"...
12-11 10:16:19.669 3496 3496 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 3496 (racoon)
12-11 10:16:19.725 3497 3497 F DEBUG : pid: 3496, tid: 3496, name: racoon >>> /system/bin/racoon <<<
This feature was working in LP/MM, but is broken since first N release. Digging a bit into the MM libs looks like the symbol "DES_is_weak_key" was in the dynamic table of libWVStreamControlAPI_L3.so library (which is missing in N):
Code:
$ ./aarch64-linux-android-objdump -T /mnt/vendor/lib/libWVStreamControlAPI_L3.so | grep DES_is_weak_key
0019b9ac g DF .text 00000028 Base DES_is_weak_key
Hope this helps to develop a fix in next updates.
Best regards,

Hello magamo79,
thank you for providing these infos. That is probably the best bug report, we have ever got .
We are using an older racoon binary in vendor which is wrong. I already made a bigger cleanup on s3 plus (which also removes this binary from vendor so that it gets build from source). This change is missing in s3 repos. We will work on merging them in the next days. Then this error will also be fixed.
Short correction: DES_is_weak_key isn't defined by libWVStreamControlAPI_L3. It is only used in libWVStreamControlAPI_L3 and racoon. This symbol got defined by openssl which isn't used in android anymore.
Cheers

Hi again,
The VPN error is fixed in that last build (Build [7.1.1] 20170105 - Stable 6). Great Job @fire855 & Team :good:
Best regards,

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.