"i don't know why you think this is anything to do with dalvik (or libcore). neither touches /dev/random. java.util.Random is just a PRNG seeded from the clock. java.util.SecureRandom uses /dev/urandom.
"what version of Android are you reporting this against? i think there was a bug once upon a time. <checks> oh, yeah, <= gingerbread was broken. > gingerbread should be fine."
I hate to say it, but this kind of bad analysis is just endemic in the Android modding world. There's no technical leadership at the top (the AOSP people are, for the most part, silent except occasionally in bug reports like this), so people just throw whatever hack they want onto forums filled with even-less-clueful folks and things go viral.
If you tried this on a "real" Linux project you'd be laughed at. Where's the test showing latency improvement? Hell, there isn't even any identifaction of any code at all that reads from /dev/random (and of course it appears there is none).
It seems a little unfair, but frankly I blame Google for this mess. They refuse to run AOSP as a "project", which leaves the AOSP-derived projects a big soup of developers with no clear meritocracy. Some bits (Cyanogenmod) are really quite good. But the stuff on XDA is probably 60% useless junk.
Android master HEAD is always proprietary and always has been. Android master HEAD also fails Andy Rubin's own definition of open: https://twitter.com/Arubin/status/27808662429, since that website is out of date.
Only a few people inside Google are allowed to see it. Their colleagues aren't allowed to sit in the same cafeteria as the Android developers, much less see the source code, until it's already done.
If it was actually Open Source, XDA developers would actually have real, original development, and features like lock screen widgets, officially added in JB 4.2 in 2012, would have been completed by the community in 2009.
Only old, already released versions of Android are Open Source. This makes it useless for real developers - who would want to fix something that might already be a non-issue as of six months ago?
As a result, the only 'community development' in Android is people who know how to tweak settings files and make ROMs with particular apps and settings built in.
All of this is true. But it's not the choice between two extremes. Google doesn't have to wall off community development in order to develop new features in secret. There's no reason they couldn't curate an AOSP project where submissions like this one (although obviously not this particular one!) could be made in a way that was truly useful to the community. It would cost money and time, and maybe they don't have that. But it's something that other FOSS players do, so it's not an impossibility.
Well, if they work on version n+1 internally and secretly it's highly unlikely a patch for version n will have any value.
In order for patches to be relevant, they should be on the HEAD of the project where most developers are working, not the old, released, finished, version.
Cyanogenmod doesn't have access to the current android source. The current test release, 10.1 is based on Android 4.2, there is no version based on the actual current android source code as that is not available to anyone who isn't a Google employee on the Android team.
And? I mean, ok, we get it, the most recently committed code is not open yet, probably because Google would prefer its flagship phones not be spoiled. So what? My phone runs an OS whose code is on github, and I install new versions when I choose to do so, from nightly builds.
And all the drawbacks I cited in the original post, ie, nobody outside the Android team bothers contributing anything, and the project has less developers and less features than it would if it were truly open.
Why would new phones be 'spoiled' if their source code was released?
> nobody outside the Android team bothers contributing anything
Do you have any figures to back this claim? Somewhere above or below a guy said he did send a patch.
> less developers and less features than it would if it were truly open
Very unlikely. Were it fully open (say, the Linux-way), it would not be pushed forward so steadily by Google, it would not have so many high-end apps (many written by Google), it would not have such a big piece of the market, it would not be the solution of choice for manufacturers, etc.
I also wish Android to be more open, and I hope we will see soon emerge a "Landroid" that will be to Android what Linux is to Unix, and probably Cyanogenmod is paving its path, but this is no reason to spit in the soup: Android is a giant step forward and without it we would be all sandwiched in a MS-Apple cross-fight.
> Why would new phones be 'spoiled' if their source code was released?
Suppose the most recent feature developed by Google on Android reveals that their next phone will have two-faced screens, wouldn't you think Google might prefer to decide when and how this new phone will be announced? As a result, we have a slightly lagging opening of the source code. It is sad, but better than nothing.
It is definitely incorrect to say "nobody outside the Android team bothers contributing anything": you can check the Android AOSP patch review website to see otherwise. However, I think it is a fair assessment to say that doing so is incredibly discouraging; while I don't have "numbers" to back it up, I definitely have tons of anecdotes on this.
On my own side, I can say this: I actually have code right now in Android; however, there is probably no chance that I will ever bother submitting another patch again.
What, in my experience, happens is that you submit a patch, and one person looks at it, thinks it is great, and gives it a +1. However, he can't merge it until someone agrees. Only, there isn't enough involvement on Google's end to get two people to agree. It isn't like someone else disagrees: you just don't get two peoples' opinions on the patch.
That is a patch that I submitted in January of 2009. Apparently, in May of 2010, a second person agreed, and the patch was merged. Yes: 16 months later. (There were three other patches I submitted in November of 2008 that were merged in August of 2009, but that was a "much more reasonable" 9 month gap, so... yeah ;P.)
With this patch, that same second guy had "disagreed"; well,
he wanted justification for why I wanted the feature. Two months later, the patch died, as I had long moved on. Now, had that question come, I dunno, a year earlier? (So, a mere 4 months after I submitted it), maybe I'd have remembered whether or not it was required for my use case. ;P
This patch wasn't even mine, but somehow I ended up in the system as "maybe he'll be second reviewer this time!" (and no, I have no clue how or why or what the rules are).
Only, this was the most depressing of all: when I reviewed the patch, I determined that the original code actually had a buffer overflow in it... this was an important patch.
The patch, of course, had already been in the system for a while: it was submitted in April, but it wasn't until nearly two months later that I got poked to review it. But, I don't think I actually could be "second reviewer", so there just ended up being a bunch of +1s from random people until yet another month went by; it finally got merged.
Another half of the problem is the same thing people here are complaining about: that AOSP is really just "an occasionally merged external branch" to "the real code".
The result is that when you are working on a patch, you actually can't know whether you are working on code that even exists anymore in the upstream branch. Maybe the code exists, but doesn't have the bug anymore; or maybe it does, but the implementation is sufficiently different that your code no longer merges against it.
What this means is that even if someone reviewed your patch instantly, it already might not apply anymore, and if it doesn't it isn't like they can even ask you to fix it.
It used to be that Google was promising that they'd merge the internal and AOSP branches, so they'd be working in public on nearly the same codebase (closer to Chromium). However, that promise at some point dissolved so greatly that they simply closed the source for something like eight months, not even attempting to merge it.
Why? As far as I can tell (and I've stared at this a lot), it was to hobble Amazon slightly, who had just announced that they were working on a tablet based on Android. Not just "an Android tablet", but "we are going to use all of that valuable work you did, but not pay you anything for it because we don't need your first-party Google apps".
The code didn't become open again until Amazon started shipping their tablets to users. At which point, the story with the open source codebase changed a lot. Now, the promise is more "we will make certain our preferred partners get access to the codebase quickly", but otherwise the code doesn't get dropped until the product ships.
Due to this, when we received our Android 4.0 test devices at Google I/O, and I soon there-after found a bug in libdl (broken shared object initializers), I was largely screwed. I seriously wasted a week (successfully!) figuring out what caused the bug and reverse-engineering what they changed using a disassembler, so I could file a bug.
When I managed to get the bug filed to the mailing list was about when the code finally dropped, so maybe that week was just wasted, but maybe I needed that time to find it anyway. Of course, Android 4.0 shipped with that bug. The issue was fixed in Android 4.0.1, and "luckily" almost no one upgraded to Android 4.0 until Android 4.0.2, but... frowny. :(
I don't think the complaint is overstated. The issue is the usefulness of community patches and contributions. Opening only released code makes those kinds of community involvement mostly impractical.
It isn't as if there isn't a model for community contributed patches for Google products: The Chromium projects take community patches and have a code review workflow for them. I don't know how effective this is, or how many end up in Chrome and ChromeOS. But it's not as if opening up more is not do-able.
> If it was actually Open Source, XDA developers would actuall have real, original development, and features like lock screen widgets, officially added in JB 4.2 this year, would have been completed by the community in 2009.
I agree in general that if AOSP was an actual open source project things would be better but I don't think XDA would be any different. It's been full of end users for years now and most of them are easily fooled by stuff like this. CyanogenMod is developed in the open and they do have quite a few contributors, but it's not terribly ground breaking (although some of their features do get reimplemented in AOSP eventually). The fact is that the Android project is really a gigantic codebase and it takes a lot of time to get started (and even on a really fast machine, 20-40 minutes to build), and a lot of the work CyanogenMod developers do is porting to hardware that's unsupported by AOSP, not feature development.
> If you tried this on a "real" Linux project you'd be laughed at.
Not really- the Ubuntu forums are an identical cesspool. There are just too many users for developers to interact with, so they hide in forums like IRC and mailing lists that drive off most of their non-technical users.
Not my point at all. If AOSP worked like, say, the kernel (or KDE, or gcc, or any other big project) this "fix" would have been submitted to and vetted by a functioning group of experts who would have immediately said "Dude, no." and it would have died silently.
No such thing exists with AOSP. Google does their development internally. External patch submissions (if acknowledged at all) end up appearing in a usable release only months after the fact.
So the poor excited hacker here (who, let's be clear, really didn't do anything wrong other than, well, being wrong) had nowhere to post a fix somewhere where it would be useful to people. So s/he threw it up on XDA with all the other junk, and we're now having this discussion.
Do "real" open source projects issue releases after every patch?
I've recently submitted a small patch to Android and it showed up in the repository immediately. While there is some development done in secret, not everything is. You can git blame and email the developers and they will probably talk to you.
(My experience is perhaps different because I have a @google.com email address, but the developers are actually nice people that do value open source, as far as I can tell.)
> this "fix" would have been submitted to and vetted by a functioning group of experts who would have immediately said "Dude, no." and it would have died silently.
Maybe. Or maybe it would have been like all those "Turn off your Windows paging file" for XP and Vista websites.
Or all those "RAM Booster" softwares.
Users get sucked into a bunch of hokum, and having a clueful person tell them it's nonsense often does nothing to stop the nonsense.
Except there is merit to running without swap in some circumstances, and I wouldn't be surprised if projects like compcache bear some resemblance to some "compress your RAM" product out there.
I accept that on HN most people know what swap is, and when it's okay (or beneficial) to turn it off, and how to do it, and who would notice the difference, and how big to set it if you do have it.
But most people hearing this "Windows performance enhancing tweak" are not that knowledgable about their OS.
Maybe I'm more forgiving of the cargo cult tweakers than I should be, because that was one of the steps on the path to where I am now. Maybe my total understanding of virtual memory and other concepts would be more theoretically pure if I'd just ignored computers until learning the theory in school, but I think that, maybe, my hard-won experience makes me a more "empathetic" developer.
I've also had real issues with windows using far too much ram for disk cache and swapping out in-use program data; a 'ram-cleaner' will at least help in this situation.
My eventual duct tape was running cacheset once a minute to cut cache down to .5GB. Thankfully once I upgraded to windows 7 it stopped being a problem.
I was following this last night because it's hilarious. Last I checked, there were three likely causes for the "performance boost" (or some combination thereof):
1) You have to restart the phone to activate the patch. Many users might not have restarted in ages, and this alone would cause a good performance gain.
2) The patch is keeping the CPU from idling by constantly writing to /dev/random. This gives you better performance at the detriment of battery life.
I'm also running this. I haven't noticed much of an improvement. The original poster says he spent hours debugging it, but hasn't posted a single shred of evidence on the process or the result.
Yeah, users' reports of its effectiveness seem to vary wildly.
My suspicion is that it depends heavily on the CPU governor [1] a device uses. Some will see that process running once a second, and keep the CPU at or near max frequency 100% of the time. Others will back down more quickly and you won't see much of a benefit, and still others were probably running at max frequency even before the change, so it wouldn't have much of an effect on them either.
I installed the patch and my CPU frequencies looks like the same, they are not scaling to max all the time. That said it is hard to notice any significant improvement after installing it.
A later comment says it affects versions through JB:
Users are reporting this issue up through Jelly Bean / 4.2 - my specific information is against 4.2. I don't believe this issue was solved in gingerbread.
There are in-kernel consumers of entropy (such as for aslr) that wouldn't show up as /dev/random opens. Reading urandom will deplete the available entropy, but won't block - however, anything relying on actual entropy availability will then block until entropy is repopulated. So if entropy_avail is ever hitting 0, there's some vague plausibility that you could have some slowdowns. But honestly, it doesn't seem likely.
It appears to be wrong that there's anything that reads /dev/random, yes. It is still correct that there are reports of latency reductions across the board. Whether or not they are real or placebo, or if they are real but have other causes (such as reboots) is another matter.
But it's too easy to just dismiss this. I tried it on one of my tablets too, and din't reboot, and subjectively it feels substantially snappier - previously the UI would often freeze up long enough for me to get ANR dialogues, and the recommended solution for that tablet model is a full factory reset when it start being persistently slow.
That does not mean that I'm sure the effect is real. Nor does it mean that it has to have anything to do with /dev/random.
https://code.google.com/p/android/issues/detail?id=42265
A comment by Elliott Hughes on the bug:
"i don't know why you think this is anything to do with dalvik (or libcore). neither touches /dev/random. java.util.Random is just a PRNG seeded from the clock. java.util.SecureRandom uses /dev/urandom.
"what version of Android are you reporting this against? i think there was a bug once upon a time. <checks> oh, yeah, <= gingerbread was broken. > gingerbread should be fine."