New Faster HTC Sense UI out today! - myTouch 3G, Magic Android Development

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*~

Related

Developers of ROMs

Would it not be easier to get together and create a single ROM? If JF releases a version now, there will be what? 3? 4?
So now all themers need to create 3 or 4 ports. Also, I have noticed that a lot of these different ROMs come pre-themed. Isn't this a bit redundant?
Personally I would like a plain-jane ROM without anything added (with the exception of root). Then you can add the options you like as we have in the past rather than have them spoon fed to us whether we like them or not.
Not really. if you are familiar with how rom cooking went with teh other htc phones, each has their own style. Once we get past the "beta" mode of these roms and they are more official, the cookers will be able to theme and do that stuff on their own. You would then pick roms based on features/themes/addons that you like instead of just going with the newest one that is out like we are now.
Agreed! (This text is just to pass 10 char limit)
Darkrift said:
Not really. if you are familiar with how rom cooking went with teh other htc phones, each has their own style.
Click to expand...
Click to collapse
Agreed. That was half the reason I loved recooking my old Apache every week.
but arnt all these builds just different attempts at getting a working 1.5 build?
Freedomcaller said:
but arnt all these builds just different attempts at getting a working 1.5 build?
Click to expand...
Click to collapse
Not any longer. The official 1.5 has been released and therefore should just simply be giving people root and adding other options.
well no, the official hasnt been released till tmo sends it as an OTA. they will add their own "style" (junk apps, and some good stuff if we are lucky) to it and then we will have official builds. Once that happens, there will just need to be root/themes/modifications. each cook will add his own ideas into his roms and will have his own followers. There will continue to be branches off of each style as we have seen with JF > lucidrem, haykuro > TheDude etc.
I remember when JF made his first rom and I started hoping this would happen. It did not seem like it would based on what was required, but we are fast approaching a rom kitchen like environment in Android where any custom build you can dream will be available. Lets see the iphone do that!
Good point DarkRift....
I went ahead and tested out Haykuro's version and while it's pretty stable, hate the fact that half of my apps no longer work. For this reason, I'm probably going back to JF1.43 until the devs have time to get the software working on 1.5.
momentarylapseofreason said:
Personally I would like a plain-jane ROM without anything added (with the exception of root). Then you can add the options you like as we have in the past rather than have them spoon fed to us whether we like them or not.
Click to expand...
Click to collapse
100% agree ...
We developers have to support 3, 4 or more different roms (different app2sd-mods not included) - that generates an unbelievable workload!
So, why not having one single base (a plain-jane rom) and all firmware-"modders" could publish one single "update.zip" (which can be applied to this basic rom) to make (specified) changes (like I've done with my kernel-update for ADP1.5 - http://forum.xda-developers.com/showpost.php?p=3699701&postcount=157)
harry_m said:
100% agree ...
We developers have to support 3, 4 or more different roms (different app2sd-mods not included) - that generates an unbelievable workload!
So, why not having one single base (a plain-jane rom) and all firmware-"modders" could publish one single "update.zip" (which can be applied to this basic rom) to make (specified) changes (like I've done with my kernel-update for ADP1.5 - http://forum.xda-developers.com/showpost.php?p=3699701&postcount=157)
Click to expand...
Click to collapse
100% Disagree ....
In my past experience with a few htc wm phones, I've seen that competition between the rom "cooks" is exactly what drives them to create the next greatest rom! If they all teamed up then there wouldn't be any roms to compete against and they might lose their desire to keep improving.
And as to the extra workload for devs.... unless you are themeing, there is no extra work required? I am developing for android and the only extra workload I have is making sure my stuff works with both 1.1 and 1.5... the specific rom makes no difference. Edit: I see you are the dev of wifi tether... in which case I'm obviously completely wrong, and I agree it must be a pain in the ass(in your scenario) to make your stuff work in every rom.
This whole conversation is moot anyways, because it will never happen. Even if the current "cooks" all teamed up and worked on one rom, new people would come along who want to make their OWN rom that's different, and the cycle would continue.
The growth of new Dev's are pretty exciting for me. I love to see that we have options, everyday I have something to look forward to with all these new builds, and I hope more Dev's jump on in with new and fresh ideas. Hey you never know some one can jump in XDA with a genius mind and make our UI look like the Ophone. Now wouldn't that excite you knowing you can jump to that rom instead of being stuck on 1?
Darkrift said:
well no, the official hasnt been released till tmo sends it as an OTA.
Click to expand...
Click to collapse
Incorrect. HTC has released 1.5 as an update for ADP (Dev) phones. So it *is* officially out there for Dev phones, just not an "official" TMo release for TMo branded G1s, which personally I don't particularly care about anyway (
) as I'd always take a manufacturer rom over a carrier one. I'd expect a TMo 1.5 to be practically the same as the HTC one, with additional bloatware!
Regards,
Dave
I love having all of these roms to choose from. I'm just having trouble deciding whether to give up the pdf reader, HTC VK and camera, for the ADP1.5H with multitouch. I'm thinking that sooner or later, I will be able to have all of those things in one rom though.
I am still on Haykuro's HTC build, and my phone is waaaay more exciting than the fruit phone!
The only thing that I can see wrong with this phone now, is that HTC didn't include more internal memory from the beginning. Even with the apps to sd fixes, there are still problems which crop up with those.
Azlum said:
100% Disagree ....
In my past experience with a few htc wm phones, I've seen that competition between the rom "cooks" is exactly what drives them to create the next greatest rom! If they all teamed up then there wouldn't be any roms to compete against and they might lose their desire to keep improving.
And as to the extra workload for devs.... unless you are themeing, there is no extra work required? I am developing for android and the only extra workload I have is making sure my stuff works with both 1.1 and 1.5... the specific rom makes no difference. Edit: I see you are the dev of wifi tether... in which case I'm obviously completely wrong, and I agree it must be a pain in the ass(in your scenario) to make your stuff work in every rom.
This whole conversation is moot anyways, because it will never happen. Even if the current "cooks" all teamed up and worked on one rom, new people would come along who want to make their OWN rom that's different, and the cycle would continue.
Click to expand...
Click to collapse
Quality over Quantity. If they all hooked up together and made on EPIC 1.5 ROM that was plain jane but 110% stable, i would love them for it. But in the end, im waiting for JF's build. Im sure thats what he is doing.
As has been stated by people such as "Big in Japan" though....
Big In Japan said:
Android 1.5 presents more than a few problems for developers. According to Alexander Muse, applications currently running on Android won’t necessarily be compatible with Cupcake 1.5; that means a mad rush to download the new firmware and rebuild their software. Compounding the problem is the fact that the Android Market won’t allow more than one version of an app, which means developers aren’t able to simply create a new, 1.5-friendly update and leave the existing version in place for those without Cupcake. Instead, Big in Japan face creating a new build that’s also backward compatible with earlier versions of Android, something they conservatively estimate should normally take around two to three weeks of development.
Click to expand...
Click to collapse
So basically, if there are ROMs that affect the software, devs will need to "choose" which ROM to use their software on. Although this is a little extreme and MOST of the time this won't be an issue, what if ROM cooking goes that far? Will you be willing to deal without applications that you use to have something else?
Just something to keep in mind.
momentarylapseofreason said:
So basically, if there are ROMs that affect the software, devs will need to "choose" which ROM to use their software on. Although this is a little extreme and MOST of the time this won't be an issue, what if ROM cooking goes that far? Will you be willing to deal without applications that you use to have something else?
Click to expand...
Click to collapse
If the developers were using private APIs during the development of their application, then the fact they are broken on Cupcake is likely to be their own fault for using an API which is not necessarily static and therefore liable to change. If they only used public APIs, then it is Googles fault for changing those APIs, or the behaviour of those APIs.
This is one of the "problems" with Android being open source - you can't realistically hide the private APIs from developers since they can see them being used in the source code, and thus may be tempted to use them when in reality they should be restricting themselves to just the public APIs to ensure forwards and backwards compatibility.
Regards,
Dave
I have to agree with everyone who wants to keep things in one.
This does NOT mean that different people can't add particular modifications to what is available, it just means distributing these things as smaller components.
Start with the stock ADP1.5 image. If you want multitouch, apply the update.zip that provides multitouch (and nothing else). If you want tethering, apply the update.zip that provides the kernel with netfilter. If you want a skin (or whatever you want to call it), apply the update.zip that provides it. There is no point in bundling everything together in full system images since all this does is it makes the downloads huge and creates incompatibilities.
For example, I have always used the stock ADP firmware. I have looked at JF's full go and found that while nice, it adds things that I don't want and leaves out things that I do want, which means that it would end up being equal work to adjust those builds into something that I want as it would end up being to modify the stock image. The deciding factor is that I know exactly how my changes work against the stock image and I don't necessarily know what changes JF has made to his.
Actually since most builds are only file-based (i.e. changing some files in /system), could we make a program that (with root, of course) download the difference and apply them? Like an android market for firmware builds or say an apt for android.
Then user get the freedom to choose what they want and can go back to previous versions easily when things go wrong.
To be safe, it could just use symbolic links to apply updates, so restoring will be easier and gives the internal flash a longer life.

Android Source 2.1 released! Now we just need the kernel

Looks like 2.1 was just released! Woot!
Looks like the changes are just being put into the git as well.
Now we are just left waiting for the kernel source drop so we can take advantage of the nifty 3d acceleration stuff.
dchadwick said:
Looks like 2.1 was just released! Woot!
Looks like the changes are just being put into the git as well.
Now we are just left waiting for the kernel source drop so we can take advantage of the nifty 3d acceleration stuff.
Click to expand...
Click to collapse
hmmm I didn't think about this only sounding exciting to me.
dchadwick said:
hmmm I didn't think about this only sounding exciting to me.
Click to expand...
Click to collapse
You are certainly not the only one. Once we get the kernel source will we finally begin to see a healthy amount of ROMs?
I really miss my G1 simply because of the sheer amount of options I had.
illogic6 said:
You are certainly not the only one. Once we get the kernel source will we finally begin to see a healthy amount of ROMs?
I really miss my G1 simply because of the sheer amount of options I had.
Click to expand...
Click to collapse
I miss my G1 too and if the Nexus Wasn't only compatable with T-Mobiles 3g network it would be tempting with the kernel in the Android Source tree and Cynanogen building roms for it.
illogic6 said:
You are certainly not the only one. Once we get the kernel source will we finally begin to see a healthy amount of ROMs?
I really miss my G1 simply because of the sheer amount of options I had.
Click to expand...
Click to collapse
We won't get kernel source compatible with 2.1 until after HTC releases a 2.1 ROM for the Hero, if even then (since HTC thinks they are immune to the GPL). Some bits from the 1.5 kernel source will be useful for uprev'd Android releases, but it will not bring the full feature set.
cmccracken said:
We won't get kernel source compatible with 2.1 until after HTC releases a 2.1 ROM for the Hero, if even then (since HTC thinks they are immune to the GPL). Some bits from the 1.5 kernel source will be useful for uprev'd Android releases, but it will not bring the full feature set.
Click to expand...
Click to collapse
Nah, I think your exactly right. Any kernel release at this point would be helpful.
cmccracken said:
We won't get kernel source compatible with 2.1 until after HTC releases a 2.1 ROM for the Hero, if even then (since HTC thinks they are immune to the GPL). Some bits from the 1.5 kernel source will be useful for uprev'd Android releases, but it will not bring the full feature set.
Click to expand...
Click to collapse
Given the kernel source I am fairly sure we could reverse the rest in a few days, the only thing keeping us back now is the lack of a frame of reference on exactly what they did to make CDMA work on GSM code.
Nanan00 said:
Given the kernel source I am fairly sure we could reverse the rest in a few days, the only thing keeping us back now is the lack of a frame of reference on exactly what they did to make CDMA work on GSM code.
Click to expand...
Click to collapse
There isn't much difference between the gsm kernel and cdma kernel with regards to radio functions. The kernel's job here is to present devices after boot, so that libhtc_ril.so can communicate to the hardware (/dev/qmi# and /dev/smd#). If you look at the code in gsm kernel, there is very little there, all the hard stuff is in the black box libhtc_ril.so. The shared library is called through the system_server process, which ends up being called by the framework, which is called by the phone app (or some other app) to make calls, send sms, etc. Notice that all it really took to get the leaked 2.1 working for basic phone functions was a config change in build.prop, telling the RIL to expect/use CDMA instead of gsm/umts.
The above can be said for other areas where we have difficulties, camera, sensors, lights, etc. All the kernel does is present devices or memory areas that user space things can manipulate. This allows HTC (and other phone makers, like Motorola or Ericsson) to keep their "important" code away from the GPL'ed kernel. A side effect is that when changes are made in Android where it expects stuff in /dev that are not present in the .27 CDMA kernel. This is why sensors and other stuff doesn't "just work", the 2.x code expects things that are not present in the only kernel we have.
Finally, Android framework is for the most part Apache licensed, hence why HTC and other phone makers are not required to release their changes to the Android system. This is why I had to reverse engineer the changes HTC made to send MMS on Sprint, for example. They had no obligation to publish those changes.

Android on HTC Fuze (Raphael 110) - Crashes and Questions

**Let me begin by saying that, as a newcomer to the forum, I apologize of this has been posted in the wrong place. I considered posting it in various HTC Fuze specific or Android subforums, but decided on this one as it is "(Android) Software...General". If there's a problem, please notify me and move this thread accordingly. I have no intention of creating problems.**
I've been doing a great deal of experimenting with Android on my Fuze, and (after trying XDAndroid 2.0.1) am trying to get 1.6 (Donut) working.
I've been using the (1.6) build on connect-utb.com. My phone is an HTC Fuze, or a Raphael 110. Apparently, it (the build) was last made/modified on 11/22/09, and (quoting from the download/version description):
"This Android package is based on the Current phhusson/leobaillard's release from 22.11.2009."
The problem I'm having is that, among other things, 1.6 seems to be VERY unstable.
A program (google maps/voice/android keyboard/marketplace/etc...) seems to crash every minute. I've become rather exasperated with it, and, after multiple manual restarts and re-installations, I've come to the oasis of mobile phone knowledge asking for assistance.
I'm confused (regarding 1.6), as this is supposedly the more stable build. I shied away from XDAndroid 2.0.1 due to the small bits of UI lag I was experiencing. 1.6 attracted me due to the claim that it's much faster (as well as having a couple more features working).
Can somebody give me some advice in regards to whether I might be doing something wrong? I'm sure I'm using the correct startup.txt, and don't quite know what the problem could be.
Granted, if somebody also has ways of optimizing XDAndroid 2.0.1, or providing an optimized build, I'd welcome that alternative.
In short, I'm looking for an Android build that will run very fast, and with exceptional stability, on a Raphael 110.
Thank you in advance.
Get the latest builds from here: http://forum.xda-developers.com/showthread.php?t=601751
Thank you for pointing me in that direction, JR_de, but, as I understand it, that thread pertains solely to Android 2.0.1 Eclair.
When I used that version, I found the graphics and response times (overall system speed) were somewhat laggy. Is that normal (for my phone)? Is there a way to optimize it?
I know that the HTC Fuze (Raphael) has a 528Mhz processor, as well as 288Mbs of RAM, which is on par with the HTC Magic - another Android phone.
Can you please provide some insight as to whether I could either 1)optimize Eclair or 2) download a stable 1.6?
Thanks again.
.
xyrovice said:
Thank you for pointing me in that direction, JR_de, but, as I understand it, that thread pertains solely to Android 2.0.1 Eclair.
When I used that version, I found the graphics and response times (overall system speed) were somewhat laggy. Is that normal (for my phone)? Is there a way to optimize it?
I know that the HTC Fuze (Raphael) has a 528Mhz processor, as well as 288Mbs of RAM, which is on par with the HTC Magic - another Android phone.
Can you please provide some insight as to whether I could either 1)optimize Eclair or 2) download a stable 1.6?
Thanks again.
Click to expand...
Click to collapse
try agian when its update almost everytime its improved speed wise
some have said that the febuary 22 build is faster
jul644 said:
try agian when its update almost everytime its improved speed wise
some have said that the febuary 22 build is faster
Click to expand...
Click to collapse
Would that also include every build thereafter, or just the one from February 22nd?? I downloaded and am using the March 1st build in the hopes that, as it's the most up to date, it will be the 'best'.
Also, I saw something about enabling 3D in Windows Mobile (before launching Haret, I assume). It said you could do this by launching TouchFlo3D.
I booted back into WinMo, launched TF3D, and am now going to see if it's any faster.
Thank you both for your help so far.
You might have more luck posting your questions on the XDAndroid forum. I too would definitely recommend using the later Eclair versions, I remember a massive performance leap around two months ago when that version number shot up. The Eclair builds will obviously be updated more regularly too.
The graphics lag is completely normal for your Fuze. The reason isn't a hardware problem, it's because the drivers for the graphics chip and just about everyting else in your WM phone need rewriting for Android, and they haven't been optimised yet, hence them not running as smoothly as on phones whose drivers have been written specifically for Android by HTC themselves.
My Touch Pro would require a soft reset every ~5 minutes with the XDAndroid 1.6 builds, but I could probably use it for 24 hours now on Eclair without it crashing.
If you're still unsure, why not just give Eclair a go? You can always switch back if you find it slower. As for your search for a build "that will run very fast, and with exceptional stability, on a Raphael 110", I'm afraid that the development just hasn't got there yet, especially for the stability. Relative to Windows, it's still miles off for that.
ben_duder said:
You might have more luck posting your questions on the XDAndroid forum. I too would definitely recommend using the later Eclair versions, I remember a massive performance leap around two months ago when that version number shot up. The Eclair builds will obviously be updated more regularly too.
The graphics lag is completely normal for your Fuze. The reason isn't a hardware problem, it's because the drivers for the graphics chip and just about everyting else in your WM phone need rewriting for Android, and they haven't been optimised yet, hence them not running as smoothly as on phones whose drivers have been written specifically for Android by HTC themselves.
My Touch Pro would require a soft reset every ~5 minutes with the XDAndroid 1.6 builds, but I could probably use it for 24 hours now on Eclair without it crashing.
If you're still unsure, why not just give Eclair a go? You can always switch back if you find it slower. As for your search for a build "that will run very fast, and with exceptional stability, on a Raphael 110", I'm afraid that the development just hasn't got there yet, especially for the stability. Relative to Windows, it's still miles off for that.
Click to expand...
Click to collapse
Thanks for taking the time to write this.
Since my last post, I have indeed given Eclair a second chance, and find it performing a bit better than I remember. Granted, I'm using the 'standard' home screen, not the Home++ one (if that makes any difference).
Also, thanks for clarifying that it's the graphics drivers that are hindering performance. That gives me hope, seeing as it's (more or less) a software issue that can, and hopefully will be, fixed.
While I would love to see the OS become faster one my phone, right now my biggest issue lies in battery life. Past that, it's camera capability, and then GPS. I'm also fiddling with a 3g/data issue, but I'm sure I'll work that out. I have never used bluetooth for the years that I've owned a cell phone, so I'm not too worried about that.
Honestly, though, I've been using Eclair for the past few days with very few reboots. I've never has any major crashes (usually only one when I boot into android and it says the latin keyboard process has crashed), and thus haven't had to reboot out of "necessity."
In short, I have given it a second chance, and am very thankful for doing so.
I wouldn't worry too much about battery life, GPS and the camera as they're the most commonly asked about things on the thread. The developers are well aware of how many users want these working, and I'm sure that if the project continues to be updated, these things (particuarly battery life) will be prioritised.
I asked svetius to open a board for Raphael Android Development, and he has very kindly done so. In the future, you'll probably get more replies here.
This is very, very much appreciated.
Thanks for your time, as well as the link (and your efforts in regards to the creation of that board).
does anyone have a good startup.txt file for their raphael
i need one because my raph has android preformance issues.
thanks

[Q] Differences - Prime and Revolver

What is the difference between the 2 ROMS?
When I do a search all I see are comments like "I'm using X and it's great!"
If there's a list of ROMS with notes about what makes one so great over the other that would be appreciative.
I would like to know this as well.
robojerk said:
What is the difference between the 2 ROMS?
When I do a search all I see are comments like "I'm using X and it's great!"
If there's a list of ROMS with notes about what makes one so great over the other that would be appreciative.
Click to expand...
Click to collapse
I think an even better question is "What is the difference between STOCK, Revolver and Prime?"
Revolver 2.5's changelog contains "Improved battery life". Compared to what? Stock 3.2 (8.6.5.9)? Prior Stock 3.2? Prime? Revolver 2.1?
Similarly, PRIME 1.8.2 changelog shows "Choice of Touchpad Circles or Mouse Arrow" and "Lots of bugs fixed (Rotate, Compass, Wifi disconnects)", etc. Are these not in the STOCK 8.6.5.9 as well? (yes, they are)
Disclosure: I've run all versions and don't see much difference between any of them, but I'm currently on PRIME 1.8.4
jhanford,
Good point. That's what I do not understand about these "custom" roms. Seems like they offer the same functions/features as the stock rom so I do not know what exactly is the advantage of using them.
Install them and test them yourself, the proof of wether or not they are better can only be judged by your own user experience and not by what others proclaim.
I noticed a significant performance improvement after flashing Revolver compared to stock.
My browser also no longer randomly locks up and quits when going to sites with flash advertisements. YMMV, of course.
There's not really much difference between the three of them since the source code isn't released and not a lot can be changes. The latter two "custom" roms just have a few tweaks included that make it slightly faster and they usually include special kernel modules such as tunneling, governors, and sound improvements/fixes.
I've ran all three and the difference is minimal as of the current firmware since a lot of stuff is now fixed. Before 3.2 Prime and Clemsyn/Revolver were a lot more useful since IMO they were a lot faster than the official version of 3.1.
I am currently on latest version of Prime but very tempted to give Revoler a try. The only thing stopping is that I do not want to waste the countless hours that I put in to create the "Hubs"
I don't think you'll see significant customizations until Ice Cream Sandwich and the next generation of tablets come out. If you look at the overall history of custom ROMs on Android, they've basically fallen into two camps:
1. Taking something from a newer device that's not officially available for given older device and porting it. That can be new versions of the OS itself, or it could be vendor customizations like newer versions of Sense in the HTC world. Right now, all Honeycomb tablets are getting fast updates to the latest version. As for vendor customizations, there aren't heavy customizations to begin with. Vendors are mostly competing on hardware design right now, throwing in a few widgets and apps that may or may not be useful. But usually customization ports stay within a brand (i.e., an older HTC Sense device gets a newer HTC Sense version). That can be for both technical and legal reasons (even within vendors it might be a legal gray area, but it's generally tolerated). But we're still in the first generation of Honeycomb tablets for all vendors, so even the small customizations that vendors are doing are already on the devices in question.
2. Building a customized ROM from the OS source, aka Cyanogen. Since Honeycomb isn't open source, no dice there. ICS is supposed to return to an open source license.
I don't mean to trivialize what the authors of the custom ROMs that do exist have accomplished. I haven't even tried them yet. There even may be significant improvements they have been able to do within the limits of what they have. But overall, it's going to be nothing like what exists on the phone side, where vendors are improving their custom skins from one generation to the next, there are 3+ major generations to work with, and the source is available. Tablets will get there in a generation or two.
Also remembr that the custom roms are deodexed. The hulu flash mod only plays well with the deodexed roms. But really there isnt much differences bc there is no source so that limits the dev capabilities for now
Sent from my Samsung Epic
ajamils said:
I am currently on latest version of Prime but very tempted to give Revoler a try. The only thing stopping is that I do not want to waste the countless hours that I put in to create the "Hubs"
Click to expand...
Click to collapse
What hubs do you speak of?
Rackers said:
What hubs do you speak of?
Click to expand...
Click to collapse
Check the thread here.
Back to topic: I took the plunge and installed latest Revolver. So far, I have not found any difference between Revolver and Prime or maybe I just haven't tested it enough yet.
Have you noticed any difference in battery life between the two?
Rackers said:
Have you noticed any difference in battery life between the two?
Click to expand...
Click to collapse
Not really. Then again, I haven't used it much since I flashed revolver.

what is the different between kernel 2.6 and 3.0

as the title, on ics rom. what is the different between kernel 2.6 and 3.0?
who can tell me?
its the kernel of linux in general lol
they stopped at 2.6.something now they are on 3.0
see http://www.phoronix.com/scan.php?page=news_item&px=OTUwMg
Yay! Let the bikeshed painting discussions about version numbering begin (or at least re-start).
I decided to just bite the bullet, and call the next version 3.0. It will get released close enough to the 20-year mark, which is excuse enough for me, although honestly, the real reason is just that I can no longer comfortably count as high as 40.
The whole renumbering was discussed at last years Kernel Summit, and there was a plan to take it up this year too. But let's face it - what's the point of being in charge if you can't pick the bike shed color without holding a referendum on it? So I'm just going all alpha-male, and just renumbering it. You'll like it.
Now, my alpha-maleness sadly does not actually extend to all the scripts and Makefile rules, so the kernel is fighting back, and is calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it into submission, and get scripts etc cleaned up, and the final release should be just "3.0". The -stable team can use the third number for their versioning.
So what are the big changes?
NOTHING. Absolutely nothing. Sure, we have the usual two thirds driver changes, and a lot of random fixes, but the point is that 3.0 is *just* about renumbering, we are very much *not* doing a KDE-4 or a Gnome-3 here. No breakage, no special scary new features, nothing at all like that. We've been doing time-based releases for many years now, this is in no way about features. If you want an excuse for the renumbering, you really should look at the time-based one ("20 years") instead.
So no ABI changes, no API changes, no magical new features - just steady plodding progress. In addition to the driver changes (and the bulk really is driver updates), we've had some nice VFS cleanups, various VM fixes, some nice initial ARM consolidation (yay!) and in general this is supposed to be a fairly normal release cycle. The merge window was a few days shorter than usual, but if that ends up meaning a smaller release and a nice stable 3.0 release, that is all
good. There's absolutely no reason to aim for the traditional ".0" problems that so many projects have.
In fact, I think that in addition to the shorter merge window, I'm also considering make this one of my "Linus is being a difficult ^&^hole" releases, where I really want to be pretty strict about what I pull during the stabilization window. Part of that is that I'm going to be travelling next week with a slow atom laptop, so you had better convince me I *really* want to pull from you, because that thing really is not the most impressive piece of hardware ever built. It does the "git" workflow quite well, but let's just say that compiling the kernel is not quite the user experience I've gotten used to.
So be nice to me, and send me only really important fixes. And let's make sure we really make the next release not just an all new shiny number, but a good kernel too.
Ok?
Go forth and test,
Linus
Click to expand...
Click to collapse
just for commemoration
same question.why brainmaster's ics version's kernal is also 2.6x as Gingersnap,but official ics is 3.0.
how about future's OTA for NS?
Singnal said:
same question.why brainmaster's ics version's kernal is also 2.6x as Gingersnap,but official ics is 3.0.
how about future's OTA for NS?
Click to expand...
Click to collapse
Because its probably a moded rom to look like its ics.
if i'm not mistaken, ics is based on the latest linux kernal - which is 3.0 (or 3.2 by now not sure )
the biggest differents are?
Have you read anything that I just posted yet? >_<
Read what i posted earlier.. and if you want follow the link.
Read under:
So what are the big changes? in my previous post!
Brainmaster's ROM isn't pretend ICS, it's the real thing. The new kernel 3.whatever won't be available until the sources are released, and there's not a huge gulf between those kernel versions anyway, it's more cosmetic
Sent from my SNES

Categories

Resources