/* 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.
Related
CyanogenMod (pronounced /saɪ.'æn.oʊ.dʒɛn.mɒd/) is an enhanced open source firmware distribution for smartphones and tablet computers based on the Android mobile operating system. It offers features and options not found in the official firmware distributed by vendors of these devices.
http://wiki.cyanogenmod.org/w/About
Code:
#include
/*
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*
*/
Instructions
1. Download the zip(s) - firmware and Google Apps additional package (optional)
2. Download and install a compatible recovery
3. Wipe data, system & cache partitions and flash firmware
4. Optional: install the Google Apps additional package
Known Issues:
- XBMC and some games touch input will fail. A work around would be to purchase a bluetooth keyboard, they are pretty cheap from ebay, or use your existing one to navigate inside XBMC until we solve the problem.
- audio routing does not work when making calls with viber, hangout or skype while connected to bluetooth headset.
- MHL output the colours wrong and audio does not route to tv.
- Google movies will crash if you want to download locally.
- Anything else? you tell me
02/12/2014 stable build
cm-11-20141202-UNOFFICIAL-klimtwifi.zip
- Hulu not working fixed
- google movies not downloading locally fixed
- charging while tablet is off fixed
cm-11-20141202-v2-klimtwifi.zip
fix graphic glitches
added kernel Performance, powersave and userspace governors
All current and previous builds, kernels and fixes can be found HERE
Latest build by senior user miscom:
12/12/2014
https://www.androidfilehost.com/?fid=95854736883843077
upstream cm source update
17/12/2014
https://www.androidfilehost.com/?fid=95857557620393377
upstream cm source update
27/12/2014
https://www.androidfilehost.com/?fid=95864024717070862
upstream cm source update
04/01/2015
cm-11-20150104-UNOFFICIAL-klimtwifi.zip
cm-11-20150104-UNOFFICIAL-klimtwifi.zip.md5sum
corrected true battery values for klimtwifi thanks to github user moneytoo who brought to my attention
update CM source
1/03/2015
cm-11-20150301-UNOFFICIAL-klimtwifi.zip
cm-11-20150301-UNOFFICIAL-klimtwifi.zip.md5sum
Fixed Kodi/xbmc touch issues, and with many games that had no touch register issues.
all credit for the touch issue patch goes to @Patrick Lower
20/05/2015
cm-11-20150520-UNOFFICIAL-klimtwifi.zip
cm-11-20150520-UNOFFICIAL-klimtwifi.zip.md5sum
Google Apps additional package:
http://wiki.cyanogenmod.org/w/Gapps
TWRP:
http://forum.xda-developers.com/gal...recovery-twrp-2-7-1-0-touch-recovery-t2817100
Sources Barracuda:
device tree
kernel for exynos 5420
vendor files
thanks to CyanogenMod team, Google and thanks to:
Nvertigo67 fixing many bugs, eousphoros for starting the intital port to klimtwifi, danny19901, fedecape, rukawa84, kafandi, miscom and anyone else I forgot for testing the rom , crpalmer for his hard work.
Special big thanks to Nvertigo67.
How to build your own
The Guide
1) please visit this thread and follow the instruction to prepare your build environment.
2) once you have CM11 sources downloaded and ready on your build server.
You will need to find your roomservice.xml android/.repo/local_manifests/roomservice.xml and add the following entries:
<project name="barracuda7/android_device_samsung_klimtwifi" path="device/samsung/klimtwifi" remote="github" revision="master" />
<project name="barracuda7/android_kernel_samsung_chagallwifi" path="kernel/samsung/chagallwifi" remote="github" revision="cm-11.0" />
<project name="barracuda7/android_vendor_samsung_klimtwifi" path="vendor/samsung/klimtwifi" remote="github" revision="master" />
click save.
Note: if you fork the repos to your own github account, replace barracuda7 with your own github username.
3) from terminal type the following:
repo sync this should download the blobs, device tree and the kernel.
breakfast klimtwifi will add the rest of the repo's that are needed.
source build/envsetup.sh
brunch klimtwifi
if all above steps were done successfully depending on how fast is your build server you should end up with a zip in about an hour or more.
you can find the zip file here:
android/out/target/product/klimwifi
You are most welcome to post question on this thread regarding building the rom, please only PM me if it is not this rom related, in this way other users can benefit from
the information
Happy Building
reserved
one more
can you make one for t705?
rowihel2012 said:
can you make one for t705?
Click to expand...
Click to collapse
I already tried, not having the tablet makes it extremely hard, until a similar device gets Ported that I can base upon the answer to your question is sadly no.
Sent from my Nexus 5 using Tapatalk
Amazing really great and only 1 issue mic doesn't seem to be picking anything up at all
Barracuda77777 said:
I already tried, not having the tablet makes it extremely hard, until a similar device gets Ported that I can base upon the answer to your question is sadly no.
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Have you tried contacting crpalmer??
He is maintaining CM 11 on the tab pro lte version and both devices uses the same qualcomm snapdragon 800.hopefully this can point you in the right direction to get lte working.
also,thanks for the cm lovin on the t705,samdung's lagwizz on this beast's hardware is a complete waste.
and i believe many t705 owners will be willing to trip knox jus to get cm on this baby.
frostmore said:
Have you tried contacting crpalmer??
He is maintaining CM 11 on the tab pro lte version and both devices uses the same qualcomm snapdragon 800.hopefully this can point you in the right direction to get lte working.
also,thanks for the cm lovin on the t705,samdung's lagwizz on this beast's hardware is a complete waste.
and i believe many t705 owners will be willing to trip knox jus to get cm on this baby.
Click to expand...
Click to collapse
My T705 exynos 5 octa not snapdragon
my t705 is exynos 5 octa
rowihel2012 said:
my t705 is exynos 5 octa
Click to expand...
Click to collapse
So snapdragon won't help us as of different radios etc...
danny19901 said:
So snapdragon won't help us as of different radios etc...
Click to expand...
Click to collapse
yea
rowihel2012 said:
yea
Click to expand...
Click to collapse
so back to square one
so the 9500 is the closest to the 705 -805 tablet, but that one is a 3g not LTE
i think if we did not got t705 i will replace it with nexus 9
lagwiz roms make this tab dead
i had the lg pro 2 it was externally fast no lag at all i love snapdragon
my bad abut the cpu,mine is also the exynos octa but the next closest is not the n9500 but the n9005 (Note 3 exynos).
http://www.gsmarena.com/samsung_galaxy_note_3-5665.php
so i guess that where we should look at instead.
i havent been following the note series phone forum after the knox crap samdung tired to ram down consumers throats.but i am sure there are cm roms floating ard.
will keep an eye out on recognised dev to see if anyone can help.
is there a way to look at the lte tw roms for 705 to see if we can get any answers?
For everyone who is gonna try this out I have done some more testing and found a few things that need fixing
In build that's been uploaded
Mono speaker/only 1 speaker works = fixed in next update as I have both working
MIC = not working but also fixed in next update
SD card = won't read or mount but does in recovery
Camera = wrong orientation and looks weird also camera apps I have tested struggle/crash when going to front facing camera
These are what I have found so far
danny19901 said:
For everyone who is gonna try this out I have done some more testing and found a few things that need fixing
In build that's been uploaded
Mono speaker/only 1 speaker works = fixed in next update as I have both working
MIC = not working but also fixed in next update
SD card = won't read or mount but does in recovery
Camera = wrong orientation and looks weird also camera apps I have tested struggle/crash when going to front facing camera
These are what I have found so far
Click to expand...
Click to collapse
Can confirm this.
On the software side:
- battery stats is finally working
- on a dirty flash the unlockers from various programs are corrupted
- trebuchet still crashes on boot
- people apps works
- synapse doesn't work anymore (UCI not supported)
Going to report back on the battery, previous version of cm11 (other thread) had serious battery drain problems
But definitely a step up, keep up the great work!!
thomas_pieps said:
Can confirm this.
On the software side:
- battery stats is finally working
- on a dirty flash the unlockers from various programs are corrupted
- trebuchet still crashes on boot
- people apps works
- synapse doesn't work anymore (UCI not supported)
Going to report back on the battery, previous version of cm11 (other thread) had serious battery drain problems
But definitely a step up, keep up the great work!!
Click to expand...
Click to collapse
Just finished building a new build:
External sd fixed
microphone fixed
mono speaker issue
just waiting for danny19901 to test it out and I will post the link, or if there is anyone willing to test pm me.
happy to see people working on the T700 again will be giving it a try soon. I'm also a bit tired of TouchWiz
OP updated with new build:
cm-11-20141116-UNOFFICIAL-klimtwifi.zip
fixed:
external sd
stereo sound
microphone
still to be fixed camera preview is a bit skewed .
A big thank you do danny19901 for doing the testing. :good:
Great, feedback on the battery is as followed:
50% battery drain on 2h 26min, problem still there. For the moment I use the skyhigh cm 1.4 kernel
Which kernel do you guys use? And is the battery any better?
I decided to put up or shut up.
Alpha is in the title, but I guess I will call this first version a developer preview edition.
Thanks goes to Hashcode, without whose original work, this would not be possible.
ROM: http://www.mediafire.com/download/zq55o2ec9wbzzh2/Slim-ovation-5.1.alpha.0.1-UNOFFICIAL-20150709-1624.zip
MD5: http://www.mediafire.com/download/k616385vb78cfbv/Slim-ovation-5.1.alpha.0.1-UNOFFICIAL-20150709-1624.zip.md5sum
I haven't had much time to play with it (no zram script, etc). I expect to improve this some with time.
https://github.com/SlimRoms/platform_manifest
I'm sure everyone knows what kernel I used and where to find the latest source...
BUT, this is what you want.
http://www.mediafire.com/download/yuukg3kofubfpap/omap4.tar.gz
I will post complete kernel and device source within a day or so for whoever wants to build this.
XDA:DevDB Information
Slim-ovation-5.1, ROM for the Barnes & Noble Nook HD, HD
Contributors
Jon Lee, Hashcode
ROM OS Version: 5.1.x Lollipop
ROM Kernel: Linux 3.0.x
Based On: AOSP
Version Information
Status: Testing
Current Beta Version: 20150709-1624
Beta Release Date: 2015-07-09
Created 2015-07-10
Last Updated 2015-07-09
system - ext4
data & cache - ext4 or f2fs
Is it Christmas already? Will be testing this ASAP
Setting it up now, so far so good. It seems to have fixed the audio issue with Amaces CM12, where keyboard sounds aren't affected by volume. Will keep updating as I use it.
Getting some graphical glitches when rotating the screen, and a few missing items in the Settings window, but not too bad so far.
There is a frustratingly large number of settings missing, compared to CM12, from status bar options to the power menu. Hopefully, these can be added later on.
Given a little time, I think I can fix the rotation graphics glitches.
(I'm going to try some omapfb/dss kernel boot arguments and try to get rotation out of system/build.prop).
There's lots of other little things to play with.
Noticed it won't retain my wi-fi password through a reboot.
I had read something about a new secure storage container to retain secrets?
Settings... I'm sure that's slimrom's "slimming"...
The graphics side of things held me up for a long time. That's mainly what I'm concerned about right now.
As promised, here's a source dump and another test build.
device_bn
http://www.mediafire.com/download/3a4c321rta43ezm/slimlp_device_bn.tar.gz
hardware_ti_omap4
http://www.mediafire.com/download/1c2py11c95b7p3d/omap4-20150713.tar.gz
kernel
http://www.mediafire.com/download/g2dh13gj93fvun7/kernel-20150713.tar.gz
ROM: http://www.mediafire.com/download/a...on-5.1.alpha.0.1-UNOFFICIAL-20150713-1918.zip
MD5: http://www.mediafire.com/download/9...alpha.0.1-UNOFFICIAL-20150713-1918.zip.md5sum
If anyone wants to build this and be added to the contributor list, let me know....
It shouldn't take too much to polish it up.
I'd love to, but when it comes to baking my own ROM, I'm very much the nubcake. I WILL offer my hardware to be a test subject though. I have a spare on hand that is not a daily driver.
I will go ahead to say that at first glance, it is very smooth, and responsive. I'll give it a couple days, see how it does as if used as normal, and work from there.
I tried to flash this, but it seems to have an endless boot. I waited about 30 minutes and lost patience. Do I need to flash something else first, like extracting the boot.img? At one point, I wiped everything including cache, system, data, internal sd, and had a pretty blank slate. I am using TWRP 2.8.7.0 and 2.8.7.1. Also tried f2fs on cache and data and ext4. I must be missing something.
Was going to ask which device until o read the list you have. M8 s a on CE phone, I love mine with the same ROM! I don't know why it would not boot fornyou though, unless you have system set to f2fs by mistake, as this ROM does not support it on system like @amaces does. Maybe if younused his, and hopped to this one, that little bit was overlooked?
Here's what I got so far: when changing between land scape, and portrait there is some graphical distortion, and a touch of lag which clears up after about a second. There is no advanced reboot option, and when I sure down, it reboots instead. When multitasking, there is a general UI lag which clears up spoon after., and it does not save WiFi information so you have to reenter WiFi information after every boot. So far, aside from slims slimming causing a desire for menu options, and theming, this is all I found.
Is this in continued development?
DarkWolffe said:
Is this in continued development?
Click to expand...
Click to collapse
No, unless someone wants to take over. Basically it was an experiment for me to see if graphics in lollipop could match that of cm10(.2). In short the answer is they can't... (without a ducati upgrade).
The other reasons are twofold. First, the lollipop browser completely sucks (I know, there's alternatives).
Lastly, I don't believe I would ever achieve the level of performance as I have with my yellow kernel 10.2 ROM (which is my daily driver), this again is related to the ducati.
I would like to take another stab at a kitkat ROM and see if I can incorporate some of the stuff I have picked up recently.
I would have updated liquidsmooth, but they have already pulled kitkat source. So I am debating which ROM repo to use (I'm thinking probably Carbon 4.4? Tabletui is important to me...)
Hey Jon, I'm excited to hear you might be building a Kit Kat ROM. Would like to try one that has your improvements such as no screen flicker and still be able to use screen casting. Looking forward to your build.
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.
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.
Hello
For the past couple (weeks) I've been trying to compile Android 10 for tenderloin using the Android 9 sources but it's not going so well. First thing I ran into multiple sepolicy errors and I feel as if I fixed them in inappropriate ways but the errors went away. Other errors regarding camera and audio and such, that are regarding that tenderloin no longer uses the legacy audio format. Made me confused because I used the device sources form Evervolv and DIrty unicorns and if i'm correct they built it exactly the same way they uploaded it. After these errors were wrapped up, I got a error at zipping the rom that it could not zip due to failure of being able to read build.prop. This made me believe that the sources are not correctly formatted. If anyone can help me find a manifest, I can build for all you guys. Please keep tenderloin alive!
Now, I did something and I'm getting plenty of perl errors. Maybe I'm just very unlucky. I'm gonna attempt to reinstall on a fresh drive on my server.
If its anyone's concern, I was building lineage 17.1. I noticed for example, Lineage's "qcom-device" repo was shaped completely differently than Evervolvs qcom-device repo.
This led me to thought that Android 10 is going to be extremely difficult because of all the upstream dev changes that was pushed to Q. If any of you would like, I could probably push out March patches Pie rom because over there I'm mostly safe of complying with the source.
My manifest shape
DirtyUnicorn's device-tree
DirtyUnicorn's device-tree-common
DirtyUnicorn's htc-msm8960-kernel
Evervolv's vendor
And dirty unicorn's atheros wlan driver
I have been changing up the device tree so much, it almost looks ridiculous . From what I heard lots of properties on the device tree haven't been touched for years. Maybe tomorrow I can try Evervolv's Q rom. If you guys can help me build up my manifest, we can push out a fully working Q rom for tenderloin. And it would be just in time when Android 11 comes out. Thank you everyone!
I wish that I could offer any help, but I never tried to compile any Android ROM or for the HP_TP.
To my knowledge the only users that I know that could offer some insight on the process would be:
@flintman
@elginsk8r
Also the LuneOS project could offer some help:
https://pivotce.com/tag/luneos/
If Android Q(10) can not be ported to the HP_TP, then at least P(9) is a good ROM to keep updating that could provide many years of App support.
Theres no reason why exactly it cant,, because lots of roms I hear were built off the original TP sources (From 2011!). It was only around 2016 when guys around here had to change it up so much that they should've been so surprised that it worked. I can try and temporarily maintain P roms until the boys around here push out sources for Q!
djared704 said:
Theres no reason why exactly it cant,, because lots of roms I hear were built off the original TP sources (From 2011!). It was only around 2016 when guys around here had to change it up so much that they should've been so surprised that it worked. I can try and temporarily maintain P roms until the boys around here push out sources for Q!
Click to expand...
Click to collapse
To my limited knowledge is all about Hardware -->> Drivers -->> ( Kernel ).
The reason that Bluetooth and camera does not work on newer Android version is due to the old (proprietary drivers) and the Kernel. That takes more dedication and work than the ROM. The same rules applies to the desktop, older processors does not support certain features and the Operating System will not run. It is possible to disable the features in the kernel so that it does not check the hardware and make it run, but it will be unstable.
Everything could be possible with plenty of time, knowledge and dedication.
HP_TOUCHPAD said:
To my limited knowledge is all about Hardware -->> Drivers -->> ( Kernel ).
The reason that Bluetooth and camera does not work on newer Android version is due to the old (proprietary drivers) and the Kernel. That takes more dedication and work than the ROM. The same rules applies to the desktop, older processors does not support certain features and the Operating System will not run. It is possible to disable the features in the kernel so that it does not check the hardware and make it run, but it will be unstable.
Everything could be possible with plenty of time, knowledge and dedication.
Click to expand...
Click to collapse
When I look at the tenderloin source, the script to gather the camera driver is disabled. Camera isnt a huge deal though because its only 1.3 MP. However we use the MSM 8960 kernel from HTC and that is the one m7,, but the one m7 is a SD 600 device so it loses sense. I was gonna get some help with one of my kernel developer buddies to dev a kernel for android 10 for tenderloin. If you see the one m7 has Lineage 17.1 available and even though it doesnt have same chipset, if im correct both chipsets went off of the same assembly line process. Lineage 17.1 for the one m7 also packages it as a "uimage" which is what we use. I believe this was only a very small select of devices. Yeah about that ive been getting so many complaints during build about "mkimage" which should've been a prebuilt tool in the lineage source. Don't know why they removed it, or if our developers added it in by their selves, etc. Anyways I fixed that error by just "allowing" mkimage in one of the permission files in my environment. But yeah i went as far as the build packaging the ROM and it complaining it cannot read build.prop. Note the build.props are generated by the environment , not the source (even though the device data is gathered by the source, its not what im talking about). I even go to the directory it was complaining about and it was all there. One of my friends suggested a permission error. I changed permissions to 777 (rw to all users) and it would still output that error. By that point I trashed my build meaning I may of done something wrong early on. I will let someone else continue building 10 but I will continue building 9 with latest patches.
It will be extremely impressive if any kernel developer will update the HP Touchpad Kernel or tweak it for future release, well everything will stop once Android becomes 64 only.
I am sure you are very well aware, but I will suggest using this built:
https://forum.xda-developers.com/hp-touchpad/development/rom-evervolv-hp-touchpad-t3923512
I was able to do the following playing around recompiling the Kernel. I recompile almost all the ROM and incorporated the same kernel changes.
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-optimize-android-swap-t3901773
The Ramdisk is also very easy to unpack and repack:
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-novacom-repair-android-t3960435
There is no need to get the original Camera or Bluetooth working, only sound and WiFi.
HP_TOUCHPAD said:
It will be extremely impressive if any kernel developer will update the HP Touchpad Kernel or tweak it for future release, well everything will stop once Android becomes 64 only.
I am sure you are very well aware, but I will suggest using this built:
https://forum.xda-developers.com/hp-touchpad/development/rom-evervolv-hp-touchpad-t3923512
I was able to do the following playing around recompiling the Kernel. I recompile almost all the ROM and incorporated the same kernel changes.
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-optimize-android-swap-t3901773
The Ramdisk is also very easy to unpack and repack:
https://forum.xda-developers.com/hp-touchpad/general/hp-touchpad-novacom-repair-android-t3960435
There is no need to get the original Camera or Bluetooth working, only sound and WiFi.
Click to expand...
Click to collapse
I think I probably stated somewhere, but Evervolvs "device" tree would just spit out hundreds of errors, and I fixed this by switching to Dirty Unicorns device tree. I also tried flintman's device tree and it didn't spit out many errors. Thanks for this though.
djared704 said:
I think I probably stated somewhere, but Evervolvs "device" tree would just spit out hundreds of errors, and I fixed this by switching to Dirty Unicorns device tree. I also tried flintman's device tree and it didn't spit out many errors. Thanks for this though.
Click to expand...
Click to collapse
I have only recompile the Kernel and all of them work, but the correct branch must be use. I can not say about building a ROM, never done it.
But Evervovs Pie by elginsk8r works very well and stable as it uses the same kernel, but the framework is different. I guess elginsk8r will be the only that can guide you on the right direction or flintman.
Have fun learning, it takes a lot of TIME!