Immediately after reading the summary, I suspected this would just use "getLastKnownLocation" and correlate that with the foreground app. From searching through TFA, that is indeed the case. Technically, not very interesting at all.
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:
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
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.
Link to Original Source
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
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.