Slashdot Mirror
The Android Lag Fix That Really Wasn't
jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."
Fist Ports!
that is all.
I wasn't aware you could add code to the next release of Android? Where is the current nightly build?
Since modern android on modern harwadre don't lag I don't really give a rats as of what it was that made it work..
If the problem is that they can't generate "random" number fast enough, maybe they could just return 42 when the entropy pool is empty.
Have you read my blog lately?
This is why "vortex" generators for carburetors are still sold http://www.vorteccyclone.com/ , Magnets for your fuel lines to "align the molecules" http://en.wikipedia.org/wiki/Fuel_saving_device are still sold, and oddly shaped bicycle cranks http://z-torque.com/ are still sold. Its really no surprise that it happens in the software world too. Really, its been happening for a long time. Regcure, anyone?
Nobodies Prefect
Tidbits for Techs Technology Blog
but sent using Android, so...
The butter project was about latency with user interaction. The issues talks about /dev/random, which is totally unrelated.
At least as a project leader, Linus tells people off when they go all hair-on-fire about some wingnut idea.
Apparently, the placebo effect also works to cure percieved computer ailments...
The problem is that xda is full of this kind of crap. Kernels which disable fsync (libEAT-MY-DATA, anyone?), exotic I/O schedulers and CPU governors, overclocking processors and other hacks... Very often, they do not have any measurable effect, or even cause new problems, such as freezes, hangs, sleep of death,...
Slow phones are slow, fast ones are fast, and occasionally things stick on Android, but no more than on comparably priced hardware using "the other" platform. You know, the platform whose fanbois try to smear Android by placing stories about supposed fixes for supposed problems on Android.
Is http://www.downloadmoreram.com/
Remember these are the guys who cant even understand what their laptop AV software is reporting.
There are a lot of comments on the bug report page. Clearly this is not a dalvik bug since dalvik does not use the /dev/random. But the other commentatros are still unsure that there might not be some issue in how randomness is generated in android from user input, which might induce lag.
Right now, some folks still investigate.
Because you can't fix stupid.
Ok, it only works if you've got a cybernetic dolphin who can use SQUIDs to read you brain, but you could still become a very technical boy...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
To fix the lag in Android just remove Java.
Seriously, all Java software is laggy and awful.
>> "didn't actually speed Android up."
If you actually read the bug mentioned in the summary - most devs are arguing that explanations about why the fixes work don't make sense in terms of Dalvik (java) that the android bug was filed against - not that it doesn't improve latency or that it doesn't work or there isn't a lower level issue. One developer https://code.google.com/p/android/issues/detail?id=42265#c162 (sorry I don't know enough about android to know if he is part of the core team or not) - is doing testing to measure results of a patch from the mainline linux kernel https://patchwork.kernel.org/patch/1745611/ plus some re-arranging of the android code to see if he has found a lower level solution.
This looks like a real bug to me. /dev/random instead of /dev/urandom, which of course causes them to be unnecessarily slow.
The problem is that many apps use
A "hack" was to make /dev/random behave like /dev/urandom, but it's not clean, which is why it's not done in the official version.
Having slogged through the linked discussion, there is no conclusion either way whether this effect is real or not. There are several theories on mechanisms that could cause an increase in responsiveness, but no conclusion. The most plausible seems to be that when the entropy pool is near empty, each input event causes a context switch as it is used to refill the entropy pool. Slower input handling obviously leads to poor responsiveness.
The summary seems to just be random android-bashing.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
Bad crypto can cause you no end of trouble. There are people out there who know what they're doing who've written PRNG systems in the general direction that you're talking about, but understand what to do and not do in the designs. Some of it's pretty subtle, like only bringing in new entropy in big chunks rather than trickling it in, and knowing what crypto algorithms work well for applications like this and what don't. And some of it's tuning.
Go read the "/dev/urandom" Wikipedia page. If you need Yarrow, use it.
The general speculation is that something in Android is using /dev/random when it would probably be ok with /dev/urandom, but nobody's sure quite what. Google Maps was mentioned; maybe it's using https to fetch map segments or something?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Android's problem has four letters: Java.
Reading that bug report makes me incredibly glad that I've only worked on open source developer tools, if the comments on that bug report are typical I imagine Google must have high turn-over of developers on the project.
I think confirmation bias can easily kick in in a situation where the problem is intermittent or hard to discern.
If the platform only sometimes lags, it is easy to take the non-lagging episodes when the system is functioning well as confirmation of the nonexistent fix, and write off the lagging episodes as remaining issues that are not yet addressed.
If the system had had consistently bad response to every event, then a non-fix would not be accepted so easily.
Apparently the OP didn't read the thread he alleges disproves the performance increase. There is actually a very lively discussion going on about it, and while there's a general agreement that it's not as simple as the /dev/random pool getting depleted, there is some evidence that it is related to locking in the UI (see comment 162).
Typical uneducated dumbdroid. Don't even know what he/she is using.
http://finance.yahoo.com/news/southwest-orders-more-mileage-stretching-222419202.html
There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.
ONE: KILL-VS-SWAP
Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.
One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.
That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.
Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).
TWO: DISDAIN FOR 2D GPU ACCELERATION
Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.
Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.
THREE: ANDROID'S MEMORY-MANAGEMENT SUCKS
Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.
I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.
No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash aroun
...can't provide interactivity as smooth as the original iPhone, you have a problem.
Denial isn't going to fix this, but I expect many denial responses.
Never noticed it myself. Runs smooth as butter.
Android does save Activity state, it's lifecycle 101. Just look at the onCreate method signature. What do you think "savedInstanceState" means?
@Override
public void onCreate(Bundle savedInstanceState)
Lag is in the time it takes between a user pressing a UI widget and the time it takes the OS (or app) to react to it.
For example, in Android when you scroll the lag is very visible. Your finger is half way into the screen by the time Android reacts. That issue is not that highly visible in ANY other mobile OS.
I have a G2. Not rooted or anything. Most of the time it's fine. Every so often, when I touch keypad buttons during a call, Nothiing Happens. A few seconds later, any and all buttons I've hit will play back very very fast.
It really is quite noticeable.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Have not seen this problem, but I have a problem with external mouse not scrolling. It's a registered bug in the database, closed, with a patch - but I have no idea what that means or when/if Samsung will roll that out - ha!
I think therefore I can't be ~TTNH
Uses AES. You can perturb it by writing "entropy" to the device to reseed it, but obvious it never runs out like the Linux /dev/random.
...I find IOS far more infuriating to use as it forces me back to the home screen every time I want to use another application where as Android has rapid task switching...
Does it really take that long? My Android phone lacks the dedicated task-switch-menu button so I have to hold the home button for 1 second to bring up recent apps. Even clocking in at a mere 1 second, it's still slower than double-taping the home button on an iOS device. Even if your Android device has the dedicated button, I think complaining about such trivialities is just that--complaining about trivialities.