Related
http://www.engadget.com/2009/09/14/htc-hero-firmware-update-peps-up-the-sense-experience-to-somethi/
Good news for HTC Hero early adopters: HTC has a new firmware update out now for the device that considerably speeds up the interface, if the multitude of reports to be found on the internet can be believed. Seeing as this was the number one gripe with the overall excellent UI, we're incredibly glad HTC has gotten work on this, and we'll be spending some more time with the device to return our newly tinted impressions. There's a video after the break demonstrating changes, and most actions seems quite a bit quicker and smoother, all the way down to opening and closing the apps menu, and sliding between home screens.
Click to expand...
Click to collapse
I hope the devs are able to snatch up a copy of that and get it into our already awesome roms! I vote for MyHero 0.1.1 myself
Wow. WRONG SECTION.
Okay, you do realize that it's the KERNEL that provides an increase in speed for the Hero ported builds, right?
Well, if you didn't...now you do. The build number does not matter. As for that OTA update that HTC is delivering, that comes standard with the HTC kernel that XDA had ages ago...and is NO LONGER in use. Most developers are using 2.6.29.6 - not 2.6.27! You do the math and figure out which would be more recent. JAC and CC's latest is based on the 2.83 build. While Drizzy's latest is based on the 2.86 build.
That HTC update is only the 2.73 build packaged in-full.
Reignzone said:
Okay, you do realize that it's the KERNEL that provides an increase in speed for the Hero ported builds, right?
Well, if you didn't...now you do. The build number does not matter. As for that OTA update that HTC is delivering, that comes standard with the HTC kernel that XDA had ages ago...and is NO LONGER in use. Most developers are using 2.6.29.6 - not 2.6.27! You do the math and figure out which would be more recent. JAC and CC's latest is based on the 2.83 build. While Drizzy's latest is based on the 2.86 build.
That HTC update is only the 2.73 build packaged in-full.
Click to expand...
Click to collapse
Hmm... That's not quite correct. That's like saying MS Word is slow because of the Windows kernel. MS Word is most of the problem...
Yes, the devs here have done some great stuff squeezing more speed out of the kernels with swap partitions and BFS - but that is only half the equation. Sense UI is an APP that run on top of the kernel, so it stands to reason that HTC could have optimized the code in Sense UI (and other apps) to improve performance.
-V
Reignzone said:
Okay, you do realize that it's the KERNEL that provides an increase in speed for the Hero ported builds, right?
Well, if you didn't...now you do. The build number does not matter. As for that OTA update that HTC is delivering, that comes standard with the HTC kernel that XDA had ages ago...and is NO LONGER in use. Most developers are using 2.6.29.6 - not 2.6.27! You do the math and figure out which would be more recent. JAC and CC's latest is based on the 2.83 build. While Drizzy's latest is based on the 2.86 build.
That HTC update is only the 2.73 build packaged in-full.
Click to expand...
Click to collapse
Yea, this is really not accurate at all. The patched kernels help with things like compcache, bfs, etc but the app/ui itself is what has been optimized in this release and is SIGNIFICANTLY faster than the 1.73.xxx version, even using the same HTC kernel.
Also, WRONG FORUM!
what i am looking forward to is the sense ui they said will come native to htc magics. we wont need to port the hero one anymore when that comes. hopefully soon, october was the month rumored.
vro25 said:
Hmm... That's not quite correct. That's like saying MS Word is slow because of the Windows kernel. MS Word is most of the problem...
Yes, the devs here have done some great stuff squeezing more speed out of the kernels with swap partitions and BFS - but that is only half the equation. Sense UI is an APP that run on top of the kernel, so it stands to reason that HTC could have optimized the code in Sense UI (and other apps) to improve performance.
-V
Click to expand...
Click to collapse
Hate to correct you here when trying to prove me wrong but;
ROSIE is the APK that runs over SENSE, not the other way around. The userinterface integrates itself with the OS.
And yes, I am more correct than not. Microsoft has nothing to do with Android. That's an entirely different ballpark, regardless of whether or not they are both operating systems. That comparison is irrelevant...considering "BFS" is not packaged with Microsoft kernels. The End.
Again.
hakeem9 said:
Yea, this is really not accurate at all. The patched kernels help with things like compcache, bfs, etc but the app/ui itself is what has been optimized in this release and is SIGNIFICANTLY faster than the 1.73.xxx version, even using the same HTC kernel.
Click to expand...
Click to collapse
The official build is not optimized. It's an official release, therefore it's a feature-rich build. HTC does not cut-down the applications list, widgets, etc. because the company has standards based on increasing speed and reliability whilst not having to sacrifice any adds-on. The optimization you speak of is only relevant HERE...at XDA, because the Hero ported ROM developers OPTIMIZE them by removing applications, widgets, and various other things packaged BY HTC within their official build to increase responsiveness on OUR devices that do not necessarily have the abilities to operate at a caliber comparable to the HTC Hero. (Run-on sentence, I know, I know.)
Reignzone said:
The official build is not optimized. It's an official release, therefore it's a feature-rich build. HTC does not cut-down the applications list, widgets, etc. because the company has standards based on increasing speed and reliability whilst not having to sacrifice any adds-on. The optimization you speak of is only relevant HERE...at XDA, because the Hero ported ROM developers OPTIMIZE them by removing applications, widgets, and various other things packaged BY HTC within their official build to increase responsiveness on OUR devices that do not necessarily have the abilities to operate at a caliber comparable to the HTC Hero. (Run-on sentence, I know, I know.)
Click to expand...
Click to collapse
You obviously do not like being wrong and obviously have no programming experience either. If they have optimised sense ui ofcourse its not just the kernel. When programming there's plenty of different ways you can get the software to produce a result to end user. if they tidy up the code and compact it down ofcourse you can make it more speedy and efficient.
replies
Reignzone said:
Hate to correct you here when trying to prove me wrong but;
ROSIE is the APK that runs over SENSE, not the other way around. The userinterface integrates itself with the OS.
And yes, I am more correct than not. Microsoft has nothing to do with Android. That's an entirely different ballpark, regardless of whether or not they are both operating systems. That comparison is irrelevant...considering "BFS" is not packaged with Microsoft kernels. The End.
Click to expand...
Click to collapse
Ok, seriously, the biggest problem with the Hero rom performance is the shell called touchflo. If you take a hero rom and use the regular home instead of touchflo the performance is night and day better. This is obviously not because of any change in the kernel (since the only change was the home shell). Based on that, I would say that HTC could improve what they collectively call Sense UI very easily by improving the shell portion of the equation.
Since my question was pointed towards the new HTC release and merging it with the current roms, that to me would seem like a DEVELOPMENT question. I also got many great answers on here that all seem like DEVELOPMENT type answers.
Right Forum. Thanks for the replies so far everyone. Hopefully we can determine if HTC released changes to the Sense UI application that the devs already had or if these are new changes (not Kernel).
If Im not wrong most of the Hero builds around here are already based on 2.73, including myhero.
Also, the increase in speed is more than just the kernel. Although a scheduler like BFS can increase the performance, the 1.7x Hero builds are much slower than the 2.73. I remember one of the Hero devs saying that the 2.73 Rosie.apk is way smaller than the 1.7x one.
Anyway, just take any 1.7 Hero build and compare it to a 2.7 build, hopefully both without BFS. I'm sure you will find that Rosie is generally more responsive.
If Im not wrong most of the Hero builds around here are already based on 2.73, including myhero.
Also, the increase in speed is more than just the kernel. Although a scheduler like BFS can increase the performance, the 1.7x Hero builds are much slower than the 2.73. I remember one of the Hero devs saying that the 2.73 Rosie.apk is way smaller than the 1.7x one.
Anyway, just take any 1.7 Hero build and compare it to a 2.7 build, hopefully both without BFS. I'm sure you will find that Rosie is generally more responsive.
Reignzone said:
Hate to correct you here when trying to prove me wrong but;
ROSIE is the APK that runs over SENSE, not the other way around. The userinterface integrates itself with the OS.
And yes, I am more correct than not. Microsoft has nothing to do with Android. That's an entirely different ballpark, regardless of whether or not they are both operating systems. That comparison is irrelevant...considering "BFS" is not packaged with Microsoft kernels. The End.
Click to expand...
Click to collapse
Wow. Where to start...
Yes, you're right - Microsoft has nothing to do with Android - I was stating an example of an App vs. an OS Kernel. You clearly missed what was a fairly obvious comparison. That make me wonder the type of person we're debating with - as it seems it's everyone against, well, you. But go ahead and stick to your guns.
My point was, kernel enhancements being done here are - for the most part - to optimize the build so it runs on inferior hardware (Dream, Magic 32B). BFS is a different beast altogether and a welcome add-on.
HTC managed to speed up Hero without resorting to BFS, this is because most speed improvements in the UI come from improvements in the Rosie.apk - hence the devs here "slimming" it down to use less memory and run better on non-Hero hardware.
Of course, that's not to say that some of the latest Hero builds aren't already using parts of this official Hero build - they all come from official Hero builds (leaked or otherwise).
The point is you are absolutely wrong in your argument that performance gains only come from kernel version increments. So you can either get over it and learn something - or you can keep arguing with everybody. Frankly I've already spent enough time on you and if you don't get it by now you probably never will so there is no point in continuing any further... But I'm sure others will probably want to have some fun at your expense if you still refuse to see the light.
I have a feeling this isn't the first time you've been corrected and I'm positive it won't be your last. As such, you shouldn't be so quick to jump on others.
Do you know the saying, "a little bit of knowledge is dangerous..."
;-)
You know, for a really good example of how it's not the kernel that determines the speed of everything, just think of how your market apps get updated all the time and how some will say *speed improvements*. The app gets updated to utilize the hardware and performance available and in turn improves its own speed better. Now the kernel does determine a great deal, but the apps are just as important with how they're coded. I would say these leaked kernel's are probably better than the new Rosie update, however there may be optimizations in the rosie ui, or other apps, that I'm sure the devs will rip or have already ripped that will continue to make our lives interesting in the coming days!
This forum is freaking amazing and you all are what make the experience here so enjoyable! Thank you all, especially you devs for making this such a great community!
~*Apollo*~
Okay, atomtom had created the "Nothin' but Netfilter" ROM back in August so that us MT3G users could keep the stock T-Mobile ROM but enable netfilter and have the su binary and superuser.apk so that tethering was possible. Well, 1.6 is officially here (at least for the ION) and according to Tmonews.com, the Donut rollout for the G1 started today and barring any problems, tomorrow the MT3G rollout should start. Kudos to T-Mobile/Google/HTC for being quick with the update, everyone was thinking it wouldn't be until late October.
So what I'm thinking is that the MT3G kernel is pretty much going to be exactly the same as the kernel in the ION, and I was wondering if anyone who knows how to build a kernel and has the source code, could simply compile a netfilter-enabled kernel, along with the wlan.ko needed for tethering to work. I'd figure out how to do it myself, but i'm stuck with an iBook G4 PowerPC Mac, so I can't even use the SDK tools (adb), let alone download the source code and compile it.
Now I could be wrong about all this, of course, and recompiling the kernel with netfilter enabled may just involve extracting the IMG file and changing the line of code where netfilter/iptables are disabled, and then putting it all back together, but when it comes to Linux and especially Android, I'm pretty clueless on that. So go ahead and make fun of me for such a lame assumption. But I really want this update to be as painless as possible for me. I don't mind pushing the boot.img, wlan.ko, and su through adb (in a Virtual Machine running XP with USB passthrough enabled) while running CM-recovery, so I'm not looking for a ready-to-go update.zip just yet. Just the pieces I'll need later.
And before anyone points me to the Official Android 1.6 standard and plus ROMs, I'm not looking for the Dev image. The standard doesn't use netfilter, and the plus uses Cyanogen's kernel, which has BFS (a plus) and many other things enabled, like apps2sd (i have no use for that).
Once the update for the myTouch is out I plan on updating the "Nothin' but Netfilter" build.
I did have a test version of 2.5.29-bfs from cyanongen's source running on my phone via fastboot for a couple days but it honestly didn't improve anything. Subjectively I would say it was actually slower. Hopefully this doesn't mean that the official 1.6 build will take a performance hit with the new .29 kernel.
(As an aside I feel your PowerPC pain as I have a Powerbook G4 for daily use. Thing is 5 years old and still works perfectly, but Android development must be done on my Linux "server", which is an old Dell laptop. )
That's great to hear! The updates have started, so any minute now we will have a download link. I can't wait, it was really fast running the Ion ROM last night. So keep me posted, via PM if you want.
bump bump bump
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
chuckhriczko said:
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
Click to expand...
Click to collapse
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Kcarpenter said:
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Click to expand...
Click to collapse
If someone has made a github project please let me know. I havent made a 2.6.29 github project yet. I am currently doing one for 2.6.27.
I created a 2.6.27 repo this morning when the source was released. And I've checked out 2.6.29, just haven't set it up in github.
Really?
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
It's not that simple. For starters we have to copy over the drivers for our phone and make sure they compile correctly. On top of that HTC modified quite a bit of the kernel. Porting it over will happen but it may take some time. Like I said before I am new to the linux kernel deal but I do know it is more difficult than it seems.
I'd say a completely functional port will take roughly 2 weeks time for a hobbyist. I'm not sure though as I'm still new to messing with linux kernels. I'm looking into a port of my own. Debating 2.6.29 or porting the android specific bits to a newer linux kernel. Chances are porting the hero specific stuff to the android 2.6.29 kernel source will be much simpler. It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight. I wish I was a bit more profficient with C programming too. I guess now I have a good reason to do just that.
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
edit: didnt release chuckriczko answered your question..
obelisk79 said:
It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight.
Click to expand...
Click to collapse
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
gu1dry said:
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
Click to expand...
Click to collapse
no kidding... I wasn't expecting to wake up to a new release. Of course I could just run linux on my laptop and call it a day
Yeah, the reason it's better to start with .29 than jump to .32, because a lot of the work has already been done for us in .29. In fact, if you really investigate the kernel source they released, vs the kernel on our phones, you'll notice that HTC has already backported some of the .29 changes in the android-msm-2.6.29 branch into the source they released, which was *not* initially the case in the kernel that they shipped.
What we need to do to get .29 actually working, is the opposite: forward-port the HTC changes for hero/c into the .29 source.
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
maejrep said:
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
Click to expand...
Click to collapse
Great work! As I said before I am new to this linux kernel stuff and don't think I can help but I am cloning the repo so I can take a look anyway.
Any progress with getting it to boot?
Any update on this project?
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
theoottesen said:
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
Click to expand...
Click to collapse
I checked the githup out. still doesn't boot
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
maejrep said:
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
Click to expand...
Click to collapse
So if I understand correctly, the devs that worked on the kernel for the Nexus One got lazy and never tried to see if it compiled on the Sapphire?
If they were developing the kernel for the nexus id hardly call them lazy for not taking the time to check it on other devices.
I made it for fun and it is NOT usable and will not be before we get official source
http://saraev.ca/signed_120810_223045.zip
working:
- data/radio (no incall microphone)
- wifi
not working: everything else
please do not report bugs. I know whats not working but can fix NOTHING for now
Good job. IMO these ports will be unusable for the next few months until cyanogen comes up with a release.
It was like that with eclair and later froyo. History tends to repeat itself.
Woot Woot, Hopefully once we get the source this can become stable. The magic lives on. Not many froyo builds I tried for the 32a werent that easy on battery life. Hopefully this turns out good. Hope the devs will work together to create a stable rom, instead of having their own builds with pros and cons.
If 2.3 ever starts working on 32A + NR, I am jumping ship asap! I miss vanilla android
eyegor said:
Good job. IMO these ports will be unusable for the next few months until cyanogen comes up with a release.
It was like that with eclair and later froyo. History tends to repeat itself.
Click to expand...
Click to collapse
There is no beginning no end. We are never be alone
HTC planning any updates in the future for "oldest" device? :/
eyegor said:
Good job. IMO these ports will be unusable for the next few months until cyanogen comes up with a release.
It was like that with eclair and later froyo. History tends to repeat itself.
Click to expand...
Click to collapse
I would have to agree with you except for I think I read on Cyanogen's twitter page that they will NOT be supporting first gen devices after CM6.1 which I assume meant NO ported 2.3 for us.
Hopefully I am wrong.
where is that quote? can't see it
good job!!!!!!!! hahahahaha
Did anyone1 tried on OR and cm Bcrook kernel???
i want to make a team for dev this rom to work full on magic..contact me..
nice hopefully it will fully work
Download does not work?
Really impressive work Hope to see this fully working.
what changes are needed for this to boot on 32b?
This is all well and good and I'll try it if I get my repaired phone back and can once again have a spare to play with.
However is it reasonable to expect this to ever be usable? We don't seem to be able to get a fully working 2.2 under the new radio so why would 2.3 ever get enough attention or drivers? I used 2.2 for a long time on the old radio but I really needed to use the new radio and have since gone back to 2.1 since it is now my daily driver again.
This will be great fun once I can put the Magic back to dev use.
I tested this on my g1, with a pershoots kernel over top so that it boots. And I was wondering how you got wifi to work? I tried replacing many things, but still get an error starting wifi supplicant daemon on logcat.
Just curious, not like I expect anything to ever become usable haha
studjuice said:
I tested this on my g1, with a pershoots kernel over top so that it boots. And I was wondering how you got wifi to work? I tried replacing many things, but still get an error starting wifi supplicant daemon on logcat.
Just curious, not like I expect anything to ever become usable haha
Click to expand...
Click to collapse
hm did you replace wlan.ko ? you should
also take a look at init.sapphire.rc:
Ive changed wpa_supplicant service a little because wlan_loader is not used as in eclair/froyo roms. my *wpa_supplicant.exec* loads the firmware and then starts *real* wpa_supplicant.
I realy dont have an idea whether firmware & tiwlan.ini are different for trout/sapphire. if they are you can edit wpa_supplicant.exec to load propper firmware files..
EDIT: this will not be usable untill we get gingerbrad sources published by google. then maybe cyanogen will do a build for us. I heard he will not support sapphire/trout anmore and if and *only if* it is true I will try to make a working one. I hope it isn't true and cyanogen will still suport our devices because he can do it better than me for sure
saibot64 said:
where is that quote? can't see it
Click to expand...
Click to collapse
twitter.com/cyanogen/statuses/8805829046177792
twitter.com/cyanogen/statuses/10393734621433856
*bump* any news, updates, anything?
found this
http://phandroid.com/2010/12/15/gingerbread-source-headed-to-aosp-soon-now-the-real-fun-begins/
Hopefully we can get a working build, dont wanna let the magic die.
Porting
Anyone done any work porting this? I'm currently working to compile this for my fender. Hopefully with the new radio. Which I've read doesn't work, so... anyone found a working one? I'm running eclipse to compile but if you'd like to help, let me know what you use and I'll send you what I've got.
I'll keep this post upto date with the last on the status of the build.
I've updated the manifest and it's inline with cm10. https://github.com/TeamICS/manifest_ics_cm/tree/jellybean
Builds are located here.
Nightlies are here or here
If you are not using firerats or don't know what that is make sure you use one of the "_shrunk" nightlies.
Currently the room boots. Lots of things work, here is what doesn't:
Bluetooth (pairing)
HW Acceleration (not likely)
Anything missing from CM10
Known issues are:
Headphone + speaker plays when headphones are in
<--previous-->
IT LIVES!
The build doesn't flash, but it successfully built. You need to use firerats as the system partition is over 173mb by itself. Not sure of optimal settings as it doesn't flash but we're getting closer.
Complete repo diff and repo status is here:
https://gist.github.com/3095432
Things disabled at build:
audioinwrapper from srec
libaac/libFDK
compiler-rt
maybe others.
Please note I haven't cleaned anything so it's quite messy and some stuff isn't pushed up to the repos yet. However it builds and that's a big step. It's off to bed and work tomorrow so I won't get a chance to work on it until the evening/friday.
Very close to a build, libaac is the only blocker, I've reached out to cyanogenmod guys to see if they have any ideas to fix aac, without completely rewritting the asm code. The problem is armv6j doesn't support smmul, clz and others in thumb mode, but armv7 (and the few devices with thumb2 on armv6t2) do. I don't have enough experience with arm asm to figure out how to rework the code to convert from 32 bit operations to 16bit operations. Also valgrind is not supported in armv6 (and can't be) so its disabled.
problems building aac, due to asm code, currently disabled a blocker
problems building srec due to audio issue, disabled
haven't ported camera
So far there is only two show stoppers, first is the audio because its changed again slightly. Shouldn't be too hard to work around. Second is cm team is still porting over all armv6 patches. Building on armv5 get stuck at audio, but armv6 get stuck on some asm code in bionic.[/sstrike] aac. AAC is being a really PITA!
<--Original Post-->
So I'm sure some of you guys are watching the I/O live. For those that aren't it's offical Jellybean will be 4.1. It's got loads of new and nice features. A lot of performance upgrades and the most important thing is the annoucement of the platform development kit. It's got all the low level details and apis need to port hardware to android.
Source code will be released in mid july, which is when the real development starts.
The hardwork everyone did on ICS, jaybob, matt, evervolv team and everyone from the G1, hero and eris forums laid the foundation. The main issue that has always held the heroc back has been the drivers. We have a great .35 kernel but with ICS a lot of the framework, that is hardware <-> software interactions changed. Thats what our audio issue was at first, and the camera. Audio was fixed by porting gingerbread patches and legacy audio support. The camera was tougher but eventually fell to the power of the community! The only two major things left are camcorder and full gpu acceleration.
The PDK will hopefully provide the last little bit we need to get acceleration working fully. It's no magic but from the keynote sounds like it might provide the information we need. Or it might not. Won't know until it lands on the web.
Overall jellybean is a step further from our old heroc's but there is still almost 20k devices officially running cm7! We obviously still have a community here who has yet to upgrade so the new goal is jellybean or bust!
As more information and sources are released I'll update the thread. I plan to port our TeamICS github account to Jellybean as soon as it's released. With luck everything will compile and be in the same boat as ics but only time will tell.
Thank you so much for posting this thread! I would have never knew about this. I'm willing to contribute to Jellybean although I'm with the Evo Shift now. I can make AOSP whenever the first jellybean Rom is released hopefully fixing some things!
count me in, i still have a few months on my heroc left until i upgrade
most of the fixes that happened from eligorom should be able to be applied to jellybean, as its basically the same rom as ics (from early reports)
I really need to add it to a signature when here in the HeroC forums, but:
My HeroC has been inactive on a carrier for the last year +, that being said, I still use the crap out of the device when I can, for a clock/alarm, music, GVoice and GrooveIP phone calls when home...
Basically, I would LOVE to see this thing continue to get updates, I still run CM7 over CM9 or ICS because for me, I see the most performance with CM7. Your talk of the PDK has me excited that I might see equal or better performance out of Jelly Bean on my HeroC!
TYVM, keep us updated
im pretty sure jellybean is going to run equal with ics for us, since hardware acceleration is still not available to us
i've been scouring the web for a solution, but no dice so far. we can turn off hwa, but i see no performance increase from doing so
from what i read, its going to take a module and some tweaks, so its going to take a dev with alot of time and knowledge on their hands to get us up to par with the adreno 200, which may never happen (although i hope it does, the heroc is awesome)
Thanks for sharing! Hard!
Not to sure if it can get 4.1. I'm having troubles getting it on the Evo Shift right now...
whoshotjr2006 said:
im pretty sure jellybean is going to run equal with ics for us, since hardware acceleration is still not available to us
i've been scouring the web for a solution, but no dice so far. we can turn off hwa, but i see no performance increase from doing so
from what i read, its going to take a module and some tweaks, so its going to take a dev with alot of time and knowledge on their hands to get us up to par with the adreno 200, which may never happen (although i hope it does, the heroc is awesome)
Click to expand...
Click to collapse
So will Project Butter have no effect on the Hero? I would think that it would at least have some effect in adding smoothness.
Sent from my SPH-D710 using xda app-developers app
I have to say I'm really exited about this. I ran ICS a few times on my hero with no problems, but I'm still using it as a daily even though I'm sure it would run fine. Ive been thinking about upgrading, but i don't see why. I really don't like any new phones. Their too big, no track ball, and i just simply don't like any of the new phones out right now. So all that being said... JELLYBEAN !!!!!
Source is out!
https://groups.google.com/forum/#!topic/android-building/XBYeD-bhk1o
edit: Not quite yet.
I'll update the TeamICS github with a new manifest for it as soon as it's out. Good news is that I happen to have tomorrow off so looks like I'll get a nice full day of playing around and trying to get it building. As with ICS I suspect most things will be broken, audio, dalvik, etc. So we'll have to port the ICS patches to jb. Once cm updates it's sources to jb, then we can switch back to them as they will have most of the patches in place already.
Shelnutt2 said:
Source is out!
https://groups.google.com/forum/#!topic/android-building/XBYeD-bhk1o
edit: Not quite yet.
I'll update the TeamICS github with a new manifest for it as soon as it's out. Good news is that I happen to have tomorrow off so looks like I'll get a nice full day of playing around and trying to get it building. As with ICS I suspect most things will be broken, audio, dalvik, etc. So we'll have to port the ICS patches to jb. Once cm updates it's sources to jb, then we can switch back to them as they will have most of the patches in place already.
Click to expand...
Click to collapse
I change my mind, i do think the hero can run jb BUT im not to sure about 5.0 or whatever they call it.. i upgraded to the evo shift and love it!! Just letting y'all know because this might be the last upgrade sadly said :/
Sent from my BNTV250 using xda premium
awesome, cant wait to see the first source build
ill help in whatever way i can, i just cant dl source because of my crappy internet connection (but if i can find someone to borrow faster internet from for a few hours ill most definitely dl source and try to contribute back that way)
Lol may take me a while before I can start porting for the hero again..
My current projects for the evo shift:
Motoblur
Porting Sense
4.1
3.0
Thats pretty much it =)
Well the cyanogenmod guys are making quick work of jellybean. Every hour more and more patches are ported over. Good news is we are very close to a build. Here are the current issue and workarounds.
Audio doesn't build, working on porting it over
problems with v6 in dalvik, changed to arm mode and ported ics *.S files
problems building aac, due to asm code, currently disabled
problems building srec due to audio issue, working on porting audio
haven't ported camera
Currently hungry and looking for lunch :fingers-crossed:
Shelnutt2 said:
Well the cyanogenmod guys are making quick work of jellybean. Every hour more and more patches are ported over. Good news is we are very close to a build. Here are the current issue and workarounds.
Audio doesn't build, working on porting it over
problems with v6 in dalvik, changed to arm mode and ported ics *.S files
problems building aac, due to asm code, currently disabled
problems building srec due to audio issue, working on porting audio
haven't ported camera
Currently hungry and looking for lunch :fingers-crossed:
Click to expand...
Click to collapse
So excited. My Hero has a sweet tooth.
Ha yeah to be honest the hero is getting more development on ics then my evo shift because y'all have aokp.. I need help with someone getting it to work on my evo shift.. We just had a ICS Kernel released so that better get some devs working .. Even though we lost A LOT to the evo 4g lte sadly said..
megaghostgamer said:
Ha yeah to be honest the hero is getting more development on ics then my evo shift because y'all have aokp.. I need help with someone getting it to work on my evo shift.. We just had a ICS Kernel released so that better get some devs working .. Even though we lost A LOT to the evo 4g lte sadly said..
Click to expand...
Click to collapse
I dont know about AOKP. Sure it was ported, but what work has there been done on it since? Honestly ICS ran super smooth for me on my Hero, especially coupled with V6SuperCharger. I was using LauncherPro on ICS to add to the smoothness, but the V6SuperCharger allows for smooth use of Apex.
yeah, it wasnt aokp that accelerated our cause, aokp has only been around for a few weeks for us so far. it was jaybob's ics aosp rom that really kicked things into gear. that and stritfajt with the camera fix, and the guys over at hero gsm for all the different tweaks and fixes, and mongoosehelix over at eris that kicked butt with evervolv for us. im sure im missing some people, but it doesnt make them any less important to the cause.
and last but not least all the testers and rom flashers that gave excellent feedback
i look forward to seeing jb run like ics
So the reason it's unflashable was because it's over the 170mb limit of the phone. Even though I'm using firerats there still seems to be a hard limit of the recovery and fastboot. The solution is to use a newer recovery, anything cwm 3.x or higher works. The dev phone I'm using had 2.5 cwm and that was the issue. Now it flashes fine. Only problem is for some reason sh didn't build, so now I'm looking to see why it didn't build.
we can cut out some cruft, like live wallpapers, and ringtones/notification sounds. live wallpapers dont work well on heroc anyway.
the sh error is boggling me too, supposedly its mksh symlinked as sh, which should have worked as thats how it is in ics roms.
im on the job lol
edit: yeah something is definitely rotton with those permissions, i checked them against an ics rom and everything checks out, but we still get the permissions error. i'm wondering if its the update binary possibly? ill do some checking and let you know one way or the other