I have a few years old Samsung TV and it plays near anything over DLNA (stream over TCP/IP from your PC), though you have to do some searching to find the right DLNA server and setup. Serviio works best for me. Buffering at movie start may be one or two seconds but certainly not more if you're on a wired (!) connection. Over Wi-Fi it's crap, of course.

Last year I connected Samsung Blu-Ray player which supported even more formats and worked even better (faster). Now, DLNA is about as shitty a protocol as possible (really, if you get down to the tech nitty gritty, "frackin' terrible" would be a compliment) so not everything always works and codec support has some limits, but some brands (including Samsung) support some non-standard stuff like additional codecs and even SRT subtitle support. Ultimately, I hacked my BR player with "SamyGO" which allows you to use network shares directly instead of DLNA which made it even better.

I've used laptops for this purpose and have even built HTPCs, but if you take a little care about what you download, by far most things will play on a DLNA setup on modern TVs and BR players (support differs per brand). My PC is usually turned on in my office room, I download my shows and movies (usually x264 720p or 1080p in mkv format with optional srt) and play them back in the living room without any additional gadgets at all.

Then again, maybe none of your TV room playback devices support DLNA or your computer isn't always-on, both will ruin this setup :)

I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:

http://it.slashdot.org/comments.pl?sid=3950207&cid=44220885

I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.

Even if it was $300, it would still be more than 6 times as expensive... the dollars come in here to show it is an absolute budget device, and as somebody else stated, how much effort went into the device.

These budget sticks usually have very slow RAM and flash (storage), with constant I/O stalling going on. This is a major part in the constant jerking and freezing. Especially noticeable the first few minutes after boot, but you'll pretty much notice it all over the place.

There's often kernel issues as well, as these budget OEMs often don't put in the time, effort and money to fix issues and/or optimize it. That's not a generic Android problem, it's an end-product problem.

The point is, what you're seeing is representative for the MK808B, not for Android. These things differ greatly per-device and their components. As such, "sluggish, jerky, freezing, ungainly and wonky" may not (or may) apply to other devices. There are many Android devices out there with lower specs than the MK808B that have much smoother performance ...

I'm not saying Android isn't slower, more jerky, more sluggish, etc than iOS would be on identical hardware, that might well be so - it just doesn't make sense to reach that conclusion based on your experience with the MK808B vs your iPhone4, as the specs aren't the same, and the numbers you are looking at do not represent fluidity - you've left out some major components to that equation.

At 1 AM, "please, nooooooo" is all you're going to get out of me. But I do make my living developing for my Android ... :)

I think it's awesome that you're using a highly customized $47 Android device to base your opinion about Android on, comparing it's performance and use to $600 iOS devices. Guess what - they aren't equals. This says a lot less about Android than it says about your reasoning capabilities.

I dabble in Android security myself, I just want to point out that every single app I have encountered that Trend Micro flagged has been a false positive warning about an exploit that isn't actually present. The cause of this appears to be that those apps include files or snippets of code also used by some well known exploits, but by themselves are not harmful. Rookie mistake.

Note that if you search well, you will find various security folk slamming Trend Micro all over the place. As such, I wouldn't put too much faith in whatever Trend Micro has published, they don't exactly appear up to speed on matters.

After some further investigation, it seems all these exploits are fixed in the latest 4.2 leaked firmware for the SGS3, so ... they're actually fixed, just maybe not rolled out yet.

The Exynos memory bug (often referred to as ExynosAbuse exploit) was released publicly and fixed rather quickly. This seems to be the way for Samsung - responsible disclosure just doesn't work with them. This has been proven time and again.

See comment subject. Doesn't come with Windows 8. Guaranteed.

So, what you're saying is, you agree with my first point, but to put my comment into perspective, you're going to state exactly my second point ?

As is always the case with /., if the subject is a question, the answer is no.

Unless you let enough time pass, then the answer to this case is most certainly yes. Nobody knows how much time that would be, though.

I may have completely misunderstood what this is about, but you can actually build the SDK from the Android source available through repo/git. You do not need to agree to any license terms beforehand to do this. Does this not work around the entire issue that TFA is complaining about ?

If not, kindly elaborate.

Who said anything about rushing ? That specific problem has been known for a long time, and most affected devices have received several updates since then. The fix is literally a one-liner in the kernel source, disabling "secure erase". When a user "resets to factory settings" (e.g. wipe all user data) the device performs an erase command. Somewhere in Android 3.x or 4.0 Google changed the default behavior from normal erase to a secure erase. The eMMC chips Samsung used were never properly tested for this, and due to a bug in the firmware of said eMMC chips, the flash memory would be corrupted during a secure erase, rendering the device completely unusable.

It's pretty much a jackpot affair, you hit the factory reset button, x% chance you end up with a full brick. Custom firmware users were much more likely to run into this because often a custom firmware would perform a factory reset upon installation - and a normal user would rarely use this function. But you did not need to run any custom software for this - it can happen on a fully original device without any modifications or even apps installed.

A few months ago, Samsung finally issued a fix - but this fix disabled secure erase being triggered by the format command itself, instead of disabling secure erase in the actual kernel. As a result, custom firmware users would still brick left and right, due to using Google-private update binaries that did not have this call disabled. They put a band-aid on the issue instead of actually fixing it (a one-liner to disable "secure erase" at kernel level (because it never actually works correctly) and revert to "normal erase" always).

Now, I have discussed these issues in person with high-level Samsung engineers, and in their opinion, how they fixed it is correct - even though an exploit like the one presented in this article allows a malicious attacker to hard-brick your device at will, thanks to this eMMC bug. Incidentally, that is exactly what I myself, as well as a number of other developers from the enthusiast community, have kept telling Samsung: with the current solution, all you need is an exploit and a viral app, and you could well end up with millions of hard-bricks.

Note that Samsung does usually warranty on a full hard-brick, so it doesn't have to be a real problem for the end-user, but if this got out of hand, it could easily cost Samsung millions and millions of dollars in repair costs. Just because it hasn't happened yet and it really is not that likely it will occur, it is certainly possible.

This is not a hardware design flaw. Whatever makes you think that ? The reason it affects so many Exynos4 devices is because the exploitable code is present in the main code they base most Exynos4 Android firmwares on. It's certainly fixable by Samsung.