Sense UI is slow on first-generation Android phones, and all the attempts to make it fast only result in a flaky, weird experience.
The framework and everything else is closed-source, what do you expect?
All we can do is extract the APKs and modify images and maybe tweak the AndroidManifest.xml or other xml files. Even if we can extract the bytecode (if that's what it's called for the DalvikVM), it still isn't as open as an AOSP build.
The only reason I flashed Rosie/Sense UI ROMs were to get a nice homescreen (which was slow) with nice widgets and a browser with Flash (that was slow and incompatible but still useful for simple stuff).
I would have fun with the ROM for a while, but when I needed to be productive, like Google something quickly or add a note in AK Notepad, it was painfully slow.
Android 2.2 Froyo is amazing. It has many features, the most important IMO being a reliable JIT compiler for the DalvikVM, and Flash 10.1 coming to the browser OFFICIALLY!
When the source for Android 2.2 is released and Cyanogen makes a release for the G1/Dream, I'm stuck on that until I get a super Android phone with a full QWERTY like the G1
Sense is also UGLY.
As for this flash thing... its not going to work on your phone. Compiled for a different CPU.
Nothing lost there though, flash is terrible trash that the world would be MUCH better off withOUT.
lbcoder said:
Sense is also UGLY.
As for this flash thing... its not going to work on your phone. Compiled for a different CPU.
Nothing lost there though, flash is terrible trash that the world would be MUCH better off withOUT.
Click to expand...
Click to collapse
Did Flash murder you in a previous life?
It seems 50% of your posts here are about how Flash is the end of civilization?
Flash is a dreadful battery/CPU hog, and I suspect the 'net, as Apple claim, would be better off without it.
That said, given the propensity of web designers to use nonstandard, bloated, un-necessary flash widgets that break navigation everywhere in their pages, making them utterly useless to those with old machines, accessibility needs/disabilities, etc I guess it's probably better to have it than not. Flash 10.1 under FroYo is only marginally quirky on my Desire. Getting there!
Sense, OTOH, I miss... LauncherPro just isn't as pretty. But I think on older hardware like the G1, I'd agree with the OP. It's not necessary to get the most out of Android and if it's causing slowdowns, it's a bit counter-intuitive to the actual purpose of a mobile phone.
Azurael said:
That said, given the propensity of web designers to use nonstandard, bloated, un-necessary flash widgets that break navigation everywhere in their pages, making them utterly useless to those with old machines, accessibility needs/disabilities, etc I guess it's probably better to have it than not. Flash 10.1 under FroYo is only marginally quirky on my Desire. Getting there!
Click to expand...
Click to collapse
How about just not visiting those websites? Most even halfway marginal websites will provide "if (no flash) then show these links instead", of the rest, you can certainly get the information somewhere else, or failing that, you probably don't want it anyway (the developer is obviously retarded...)
The big important thing to note is that the web is changing. There is MUCH MUCH MUCH less flash around than there was 10 years ago. In fact, I can't think of a single site that actually still *requires* it (except maybe a few sites hosting videos of retards doing stupid crap). I can think of a few that have flash ads -- in these cases, NOT having flash dramatically improves your experience.
Different architectures
I remember a while back that there was a bug in Sense on the Hero where the package name (com.google.maps) would be displayed instead of the actual application name (Maps).
HTC acknowledged the problem and fixed it, but that's the problem with Sense; if it were open-source, someone (probably on xda) would release a tiny patch to fix the problem. Like if Google made the same mistake in the default Launcher, it would be fixed by the devs online quickly.
And now about Flash: What!? Wasn't it built for ARM? Or do the N1 and other superphones use a slightly different architecture? This is weird...
Another problem is that there are netbooks and all sorts of smartphones with Android.
Most netbooks will have x86 processors (Intel, AMD) and though most smartphones are expected to use ARM, some might use a different architecture like MIPS, or even x86 in the future.
Normal Android applications that are made with Java are fine, but how about all the apps with native binaries built with the Android NDK?
What Google should do is implement a way to compile the same program to all popular architectures, and keep the different binaries in the APK.
Apple did something similar in Mac OS X when they switched from PowerPC to Intel... application files in Mac OS X are basically a package that holds basic information, icons, and the binaries, which make this file format similar to Android APKs, except that when someone compiles their program for OS X, both PowerPC and Intel binaries are compiled and stored in the application.
If Google does this for Android, there will be no problem with different architectures (like with Flash not being able to run on the G1)
PSP_Hacker said:
I remember a while back that there was a bug in Sense on the Hero where the package name (com.google.maps) would be displayed instead of the actual application name (Maps).
HTC acknowledged the problem and fixed it, but that's the problem with Sense; if it were open-source, someone (probably on xda) would release a tiny patch to fix the problem. Like if Google made the same mistake in the default Launcher, it would be fixed by the devs online quickly.
And now about Flash: What!? Wasn't it built for ARM? Or do the N1 and other superphones use a slightly different architecture? This is weird...
Click to expand...
Click to collapse
Just like i686 binaries won't run on an i486 CPU, ARM7 binaries won't run on an ARM5 CPU. There are architectural changes that break compatibility of new binaries on old hardware.
Another problem is that there are netbooks and all sorts of smartphones with Android.
Most netbooks will have x86 processors (Intel, AMD) and though most smartphones are expected to use ARM, some might use a different architecture like MIPS, or even x86 in the future.
Normal Android applications that are made with Java are fine, but how about all the apps with native binaries built with the Android NDK?
Click to expand...
Click to collapse
Not all native applications are built with the NDK. Flash is a big example -- it has a lot of HAND WRITTEN ASSEMBLY CODE. There is NO automatic way to generate hand written assembly code. Each additional platform you support MUST have its own manually written code.
What Google should do is implement a way to compile the same program to all popular architectures, and keep the different binaries in the APK.
Click to expand...
Click to collapse
http://developer.android.com/sdk/ndk/index.html
Might not be a bad idea to read up on the ndk.
The applicable line is "You can also build for both architectures at the same time and have everything stored in the final .apk". Seems that they already thought of this
*** but it isn't applicable to flash since flash is partially hand-written. They could easily include the various binaries within a single APK file, but that won't happen unless they actually build the arm5 binary, which is extremely unlikely.
If Google does this for Android, there will be no problem with different architectures (like with Flash not being able to run on the G1)
Click to expand...
Click to collapse
For reasons mentioned above, this doesn't help.
Related
Last night Google announced the Google Chrome open source OS.
This OS will be available for small ARM based devices up to full scale desktop/laptop x86 based devices. Google aims to create a nearly instant on OS with a high reliabilty and the ability to use the applications for Chrome in any (HTML5 Compatible?) browser on any other platform.
ANY WAY... ARM compatibility is nice
http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html
Possible for it to run on the xperia?
dadeadman said:
Possible for it to run on the xperia?
Click to expand...
Click to collapse
Nobody knows. For now, it's just an initial announcement with no further details. We'll have to wait for them to release before we see, but it's basically just another window shell on top of a Linux kernel.
Which is fine with me. If google can release an OS that can be flexible enough for ARM to x86, and it WORKS, I'll be happy. I'd love to see a proper Linux ROM on our HTC devices.. it's a shame to be limited to a haret 'side boot' instead of a native ROM
l3it3r said:
Which is fine with me. If google can release an OS that can be flexible enough for ARM to x86, and it WORKS, I'll be happy. I'd love to see a proper Linux ROM on our HTC devices.. it's a shame to be limited to a haret 'side boot' instead of a native ROM
Click to expand...
Click to collapse
Considering WM devices have a REALLY bad habit of booting quite differently from maker to maker, I wouldn't be holding your breath for anything other than a haret based solution for quite some time...
Why do some prefer code-sourcery (and oddly enough use much older versions of it) and some use gcc found in the android ndk.
I personally use v4.4.0 found in the ndk (versus v4.4.3) because 4.4.3 produces modules that won't load, giving an error I cannot remember.
I'm guessing there is an advantage to using xyz over abc.. optimizations comes to mind.. but I cannot really grasp how a given CCompiler would produce a better performing kernel over another.. maybe I'm right, maybe I'm wrong.. I'm definately uncertain (heh, irony) so I'd like to know what's up.
This:
http://www.engadget.com/2011/06/24/zinio-brings-tegra-hardware-acceleration-to-honeycomb-tablets/
... should be done to all Android components ... !! Especially the launcher and web browser.
I don't ask much, and I am a good boy and promised to be a good boy always
I can't imagine Honeycomb could be that bad that it isn't already doing that. Dunno though.
I have been doing some reading on this topic after seeing that article. The base 3.1 OS ALREADY has hardware accel for all features that implement surfacing, i.e. almost all animations on the base android U.I, and base applications like the browser. I dont know what causes some of them to be a little sluggish sometimes, I think its mostly due to its infancy and also manufacturers not knowing **** about optimization. As for apps, its up to the developers to 1: implement OPENGL surfaces correctly, and 2: enable the hardwareAccel flag in their manifest files, to allow for tegra GPU accel.
caboos3 said:
I have been doing some reading on this topic after seeing that article. The base 3.1 OS ALREADY has hardware accel for all features that implement surfacing, i.e. almost all animations on the base android U.I, and base applications like the browser. I dont know what causes some of them to be a little sluggish sometimes, I think its mostly due to its infancy and also manufacturers not knowing **** about optimization. As for apps, its up to the developers to 1: implement OPENGL surfaces correctly, and 2: enable the hardwareAccel flag in their manifest files, to allow for tegra GPU accel.
Click to expand...
Click to collapse
Its kind of a mess.
Its implemented but not across the UI and simply not well done where it is implemented.
That looked more like a Xoom vs GST video to me, and GST was winning
Alright everyone, time for the important question that no one wants to ask.
Since we have devs already working on ICS, we all know our hardware is a little bit dated which means it's likely we will have to remove some of the cooler features in the roms so, what do you think we might have to sacrifice to get a taste of that nice green-blue goodness?
ICS will run fine on our phone. AOSP does not take the latest hardware to run. It just has to be optimized to run on our phones. Google says our phones are to old cause they do not want to take the time to make it work on older phones.
Manufacturer bloat will have to be stripped or slimmed out an ICS/sense port will either lag horribly or sense will have to be seriously stripped or be ported back to an older less resource hungry version like 1.0/2.1 as all new ICS/sense roms will have 3.5+ which is already laggy on our hardware with out heavy mods. So don't expect to be running a full blown Ics/sense 3.5 port from a newer phone like the edge or radar. If and this is a BIG IF we are graced with one last official update on the OG don't expect sense to be upgraded they didn't upgrade it for gb, and if it does get a sense upgrade it won't be above 2.1 and it may have some of the major features removed or slimmed, such as the social integration may be downgraded and not have as many features available as it does now. Think of it like a race car if its big and heavy like a muscle car its gotta have a lot of HP to go fast if its small and heavy its gotta be stripped of all non essentials to go fast like taking all the seats but the drivers seat out and replacing as much metal with plastics and composites as possible.
Sent from my -EViLizED-EVO-
dabbill said:
ICS will run fine on our phone. AOSP does not take the latest hardware to run. It just has to be optimized to run on our phones. Google says our phones are to old cause they do not want to take the time to make it work on older phones.
Click to expand...
Click to collapse
I still have my G1 (wife is using it), and I use an EVO 4G. Any chance ICS will run on the G1?
dabbill said:
ICS will run fine on our phone. AOSP does not take the latest hardware to run. It just has to be optimized to run on our phones. Google says our phones are to old cause they do not want to take the time to make it work on older phones.
Click to expand...
Click to collapse
from what i understand, ICS heavily utilizes the GPU in regards to rendering images/3D, and our GPU is going to bottleneck ICS to the point where it is laggy. someone correct me if i'm wrong.
I loaded the SDK dumb ICS rom on the evo4g going through the menus and swiping the screens ran just fine. So i would have to say once all the drivers get loaded and the rom tweaked it will be the same as running GB.
dabbill said:
ICS will run fine on our phone. AOSP does not take the latest hardware to run. It just has to be optimized to run on our phones. Google says our phones are to old cause they do not want to take the time to make it work on older phones.
Click to expand...
Click to collapse
Google has nothing to do with releasing OS updates for our phones. That is 100% up the the phone manufacturers, so don't blame google.
-EViL-KoNCEPTz- said:
Manufacturer bloat will have to be stripped or slimmed out an ICS/sense port will either lag horribly or sense will have to be seriously stripped or be ported back to an older less resource hungry version like 1.0/2.1 as all new ICS/sense roms will have 3.5+ which is already laggy on our hardware with out heavy mods. So don't expect to be running a full blown Ics/sense 3.5 port from a newer phone like the edge or radar. If and this is a BIG IF we are graced with one last official update on the OG don't expect sense to be upgraded they didn't upgrade it for gb, and if it does get a sense upgrade it won't be above 2.1 and it may have some of the major features removed or slimmed, such as the social integration may be downgraded and not have as many features available as it does now. Think of it like a race car if its big and heavy like a muscle car its gotta have a lot of HP to go fast if its small and heavy its gotta be stripped of all non essentials to go fast like taking all the seats but the drivers seat out and replacing as much metal with plastics and composites as possible.
Sent from my -EViLizED-EVO-
Click to expand...
Click to collapse
The evo design is only a single core running 1.2, I would say there's a fair chance we can get a pretty good sense port from it.
nothing will need to be stripped. ASOP roms are tiny compared to Sense. Google already said that if your phone can run GB, It can run ICS. The only reason we won't get a official update is because HTC has moved on to newer phones and supporting us makes no money.
cnstarz said:
from what i understand, ICS heavily utilizes the GPU in regards to rendering images/3D, and our GPU is going to bottleneck ICS to the point where it is laggy. someone correct me if i'm wrong.
Click to expand...
Click to collapse
Here to happily correct you.
Actually, rather than ICS "heavily utilizing the GPU to bottleneck the EVO", it's the reverse. Android 1.0 - 2.3.7 all currently use software acceleration. This means the CPU has to pull double duty: It has to run the OS in the background, and render everything you see in the OS.
(Games and other applications, of course, use the GPU if designed to do so.)
The departure now is that ICS uses the GPU to leverage all of the UI, taking that strain off of the GPU. The result should actually be that the EVO runs better than ever, with a slicker, smoother UI to result, and better performance from the OS in general.
Also, all of that business about having to strip-out components for the EVO is nonsense. The EVO has a 1GB ROM; it has more than enough room for ICS in it's entirety, and all the horsepower necessary to make it run really well.
It seems like in theory the og evolution should get a little better battery life too since the workload will be split instead of all dependant on the CPU. The clockspeeds should have less full throttle time than previous versions right?
Sent from my PC36100 using xda premium
dills2214 said:
Google has nothing to do with releasing OS updates for our phones. That is 100% up the the phone manufacturers, so don't blame google.
Click to expand...
Click to collapse
I wasnt blaming google. I just ment google is not going to take the time and optimize AOSP for every phone out there. Its up to phone manufacture and other devs to do that.
dills2214 said:
Google has nothing to do with releasing OS updates for our phones. That is 100% up the the phone manufacturers, so don't blame google.
Click to expand...
Click to collapse
Not true for Nexus devices, and I think dabbill was referring to their statement about the Nexus One being too old for an ICS update.
If Wikipedia is accurate, the N1 only has 512MB of storage, while the Evo has 1GB of storage. On the Evo at least that 1GB is split between system, data, and cache partitions. If the N1's 512MB number is accurate and similarly is a total amount for all three partitions, than their statement would make sense for the N1. Our 1GB total should be enough. CM7 only uses 40% of the system partition on the Evo.
Ichigo said:
So, as you all know Android kitkat 4.4 came out recently. Along with it was ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience. ART stands for Android Runtime, and executes apps different than Dalvik. ART uses AOT to execute apps, which is pre-compiling bytecode into machine language when apps are first installed, turning them into truly native apps. ART still is still experimental currently, but let's discuss our opinions.
I know that when programming games for android, if it uses heavy 3D translations, you'll to use the NDK, coding in C or C++, allowing the app to run natively, and helps maintain frame rate and speed. Because the ART has apps running natively now, will it possibly help maintain framerate and speed better on lower-end devices? I know java is much slower slower than c++, but will running the java coded app natively help at all?
Anyways, share your opinions, ideas, or questions.
Click to expand...
Click to collapse
I don't know much about ART, but from what I heard this sounds awesome . I think that it is just crazy not to precompile the code into machine language, sure there is longer install times, but hey, the apps should run much faster.
The thing is that currently it is quite hard to try it out, even on KitKat (which I don't have yet). Would love to make a comparison between the two
Here are some benchmarks by Android Police: http://www.androidpolice.com/2013/1...ormance-wont-blow-away-today-will-get-better/
I hope that they will improve that method. If they do, it will be amazing.
Apps could much faster.
I do, however, like Java. One of the reasons why I prefer Android to Ubuntu Touch (which uses C++).
nikwen said:
Here are some benchmarks by Android Police: http://www.androidpolice.com/2013/1...ormance-wont-blow-away-today-will-get-better/
I hope that they will improve that method. If they do, it will be amazing.
Apps could much faster.
I do, however, like Java. One of the reasons why I prefer Android to Ubuntu Touch (which uses C++).
Click to expand...
Click to collapse
When KitKat comes to Nexus 4 I'll do some before/after benchmarking on MagicKeyboard (since it is fairly predictable and CPU intensive) - sounds quite promising.
PicomatStudios said:
When KitKat comes to Nexus 4 I'll do some before/after benchmarking on MagicKeyboard (since it is fairly predictable and CPU intensive) - sounds quite promising.
Click to expand...
Click to collapse
Kitkat is here on our Nexus 4s.
nikwen said:
Kitkat is here on our Nexus 4s.
Click to expand...
Click to collapse
Aw, yeah... I try to make a rule that wherever possible I use 'standard' build on our test devices, that way I can be sure I'm seeing what our users see
Depending how long it takes I might have a look !
PicomatStudios said:
Aw, yeah... I try to make a rule that wherever possible I use 'standard' build on our test devices, that way I can be sure I'm seeing what our users see
Depending how long it takes I might have a look !
Click to expand...
Click to collapse
Now the official ones are finally here.
nikwen said:
Now the official ones are finally here.
Click to expand...
Click to collapse
OK got it finally.
In a not particularly scientific test I tried typing the sentence
'The quick brown fox jumped over the lazy dog.'
into Magic Keyboard 2 (as many other apps as possible stopped, internet off, etc)
After each key press the app runs quite a large number of comparisons/calculations/bitshifts in a loop, in order to score the most likely word (CPU intensive work)
I only ran the test 3 times but there does seem to be an improvement with ART
Average prediction time for each configuration is:
Android 4.3:
20ms
Android 4.4 / Davlik:
19ms
Android 4.4 / ART:
15ms
From previous tests I know that the prediction times are fairly consistent.
Obviously the above is some way short of proof but early signs are good.
i am on android 4.4.4 with art runtime i haven't noticed any performance enactment and also not a single app cashing
Sent from my XT1022 using XDA Free mobile app