Slashdot Mirror

Apple and Microsoft control their own update process on all platforms; Google does not. It's the individual carriers who are getting in the way of Android updates.

Google set it up this way. According to the Google Play dashboard, 61% of people are v4.3 or lower. you know that 90% of them will never update. And the google play store only collects phones that visit the service, imagine the tens of millions "grandma's phone" people who use an android because that is the default cheap phone without making use of the play store. Sounds like a basket of fail to me.

https://developer.android.com/...

I'm not certain, but I think there is, CTS you need that and comply with ACD (Android Compatibility Definition) to be even considered for a license to ship the Google apps.

Android 4.3 is on 6.5% of android devices.

Android 4.3 is on 6.5% of devices, not 60%.

The apps either didn't exist or were featureless, including Microsoft's own ones. Needless to say, I was happy to go back to Android

Then you'll be pleased to discover that Lollipop's new Material Design aesthetic also aims to eliminate all visual features. And just so you don't miss out, most of the Google apps in KitKat have also been updated with Material Design.

Joking aside Lollipop went from 0% to 0.1% in two months. iOS 8 went from 0% to 56% in two months (released in September; at 56% in November). As of now, the latest iOS 8 has 68% share, the previous iOS 7 has 29%, and older releases have about 4%.

According to Google, 46% are using two-generations-old Jelly Bean and 15% are using versions at least three generations old.

I think there are more reasons for Android users not upgrading than "they got busy over Christmas".

I appreciate the notifications on the lock screen (I can delete email from the lock screen, I like that). Battery life seems a bit better.

While available previously via a manual option (in Kitkat, that's what my phone started with), the ART Ahead-Of-Time compilation does improve application performance, but it also means the OS update took about 2 hours to complete as it had to optimize everything app on the phone.

http://source.android.com/devi...

On the negative, Hangouts doesn't make it clear when an incoming message was sent to multiple parties. This was a problem before, and is probably due to SMS messaging standards (total guess, I've never investigated).

Otherwise it seems pretty seamless, my Nexus 5 (purchased independent of carrier, I use T-Mobile) picked it up automatically. Interestingly, my wife's phone (same model, carrier, and account) has not.

But I have longed for a good portable player I could use with flac which is what I have my music ripped to on my living room BIG system (tube amps, klipschorn speakers, etc).

Android has supported FLAC since 3.1 : http://developer.android.com/g...
So nearly any android phone or media player will do it. Samsung Galaxy Player was a decent iPod-touch-like device.

In addition, the Sandisk players (I don't know if it's all of them, but at least the Sansa Clip) support Flac, and they can be found very cheap.

Archos was one of the first with a really polished player that also supported Flac, and kept making a HDD based one for quite a long time. Sadly, I think Archos backed out of the media player arena (probably because people kept saying "I have longed for XYZ", and then not buying it when they made it).

This Sony thing has a little more than normal onboard memory. Otherwise, it's nothing special AFAICT.

Minor correction -- no version of IE (or Safari if we want to be technical) on Windows XP supports SNI. IE7 on Vista supports SNI, but not on XP. Also, Android 2.x is still pretty relevant given that it currently represents 9.6% of active Android users. The original Kindle Fire did not support SNI, though I believe with the second generation it did support SNI. Anyone with a pre-BB10 Blackberry also does not have SNI support.

Trust me, I would love to go SNI-based for SSL, but support wise we're just not there yet.

It'd be nice if apps had a base set of privs then expanded sets that could be allowed on install or later by request to the system/user.

That's already possible in current Android. Offer one app in Google Play Store that needs a small set of permissions, then offer other apps in Google Play Store that act as content providers for the main app. For example, there might be a "Swype" keyboard app that needs only the input method permission, a "Swype auf Deutsch" app that adds a German dictionary, a "Swype Local" app that adds nearby businesses to the dictionary (which requires the location permission), and a "Swype Knows Your Name" app that adds your contacts to the dictionary (which requires the read contacts permission). If they're all digitally signed by the same publisher (such as Nuance), they can share data structures intimately as if they were one app.

Also it'd be nice if the privileges were a lot more restricted, like "Use Ad Service to show you ads" instead of "Use Internet"

The example you give is not possible unless you want all ad-supported apps in Google Play Store to move to a single monopoly ad provider. If you whitelist communication with one hostname, that host could act as a proxy to access any other host.

In my understanding of the Android docs and this blog, yes it can have one, Google Wallet use the harware secure element on supported devices. Recent Android releases added APIs too, for applications to emulate cards without access to the secure element, pure CPU based implementations, less secure but still an option.

Yes, annoyingly, OSX doesn't support MTP. You'll have to use something like Android File Transfer.

I became interested in wearables when I read Google's creative vision for the Android Wear platform:

https://developer.android.com/...

Prior to reading that, I also didn't see much point in them. However, if Google can deliver the system they describe, I am absolutely on board. It's a short read, worth it if you want to know why people are into the Android Wear idea IMHO.

From what I've read about Apple's device, their approach seems less focused.

[Emulation slowdown due to the developer's refusal to recompile an ARM NDK app for x86] is mostly an issue with games, since they're the apps that push the performance boundaries enough that it makes sense to write native code.

I thought the Android NDK wasn't intended for performance as much as for sharing the model (application logic and data access) code with versions of the application made for other platforms. You don't want to have to write in C++ once and then rewrite it line-by-line by hand in Java for two reasons: hand translation is more likely to introduce bugs, and it doesn't pick up on changes made to the original version (the Don't Repeat Yourself principle).

Also have to give them credit for the bit at the very start where they proudly reiterated their very new widget and Intents features.

You know, cutting edge stuff that no one's ever seen in a smart phone before.

Also have to give them credit for the bit at the very start where they proudly reiterated their very new widget and Intents features.

You know, cutting edge stuff that no one's ever seen in a smart phone before.

The biggest question I have is the part about Google incorporating hardware-based security since Google controls the software, not the hardware. Are they now dictating that for Android to run a specific hardware protection setup must exist on the devices?

Not a specific hardware protection setup, no. Android defines an abstract API to hardware-backed crypto services, called keymaster, which device makers have to implement. They can implement it in whatever way they like, though AFAIK all of them currently use ARM TrustZone. And not all of them do implement it. If you'd like to find out if your device does go to Settings, then Security, then scroll down to the section on "Credential Storage" and see if it says "Storage type" is "Hardware-backed".

The documentation for the current version of the hardware crypto API is at https://source.android.com/dev...

Android doesn't sandbox apps.

Er.... Yes it does. Absolutely it does, it's right there in the docs.

http://source.android.com/devi...

Each app gets a separate Linux user, so it's data is separate and inaccessible to other apps.

Well Kitkat is apparently making good inroads as it went from 13.6% in June to 24.5% in early September, and versions earlier than JB are down to 21%. This move by Google to cut off the bottom feeders that want to push old models without any hope of them ever being updated can only help these numbers. Personally I think they should cut off any manufacturer that doesn't agree to at least security updates for 2 years (typical length of contract in many parts of the world).

Although I am well-versed in C, I have thus-far avoided C++, C# and Java, and have only briefly dabbled in Obj-C. Now that there are two possibilities for doing iOS Development, which would you suggest that I learn, at least at first? And is Swift even far-enough along to use as the basis for an entire app's development? My goal is the fastest and easiest way to market for this project; not to start a career as a mobile developer.

This portends badly. You don't know enough about any of the languages currently in use on any platform, and your goal is "the fastest and easiest way to market?" The obvious solution is to give the job to someone else who knows what they're doing.

So, since that's not what's happening here (and any sane - and most insane - business would go that route), this is a case of "I've got a cool idea for a mobile app but I don't know anything about the platforms or how to code in the languages behind them, and I don't want to give any details about what its' performance and resource requirements are because someone might steal the idea." This is further borne out here:

If/when I decide to port my iOS App to Android (and/or Windows Phone), would either of the above be an easier port; or are, for example, Dalvick and the Android APIs different enough from Swift/Obj-C and CocoaTouch that any 'port' is essentially a re-write?

Why not just download the dev kits for Android and iOS and ask yourself if you can even understand the development documentation, the APIs, etc? The problem right now is yo don't even know enough to ask the right questions: you don't want to commit to something (objc vs swift) this early in your learning curve and then find out you made the wrong choice because you didn't take a month to pick up some basics.

It's worth noting that the Android API already provides methods and identifiers specifically for handling mice and styluses. see http://developer.android.com/r... and http://developer.android.com/r...

It's worth noting that the Android API already provides methods and identifiers specifically for handling mice and styluses. see http://developer.android.com/r... and http://developer.android.com/r...

Even after the 'Xbox One' disaster, they're going with One?

Did they forget that Android is already versioned using incrementing numbers, and that they're now way beyond 1?

I guess they'll loosen Microsoft's hold on the "One" name, but really, this is just stupid.

Incorrect. Many android apps have arm binaries.

https://developer.android.com/...

Many do not, to be fair, but most games do at the very least.

I see a lot of "I can already do the same things on my phone" posts, but that doesn't close the book on smartwatches for me.

A phone can do everything a tablet can do. A laptop can do everything that a phone or tablet can do. A desktop can do everything a laptop can do. Go back to the start of microcomputers and there is the "the office mainframe can do everything a PC can do" argument.

All of the above platforms succeeded because they helped people do mostly the same things (or a subset of overlapping things) but added some advantage in portability, cost, ease of use, etc.

Google's official vision for Android Wear is interesting because it clearly explains where Google thinks the advantage for watches will be: timely notification of important information *without* interrupting what you are doing. If you're not understanding why you'd want to own a smartwatch, it is worth reading:

https://developer.android.com/...

I wouldn't say the current crop of hardware and software delivers this vision all that well, but if this is the goal then I will remain interested. Apple's strategy seem less focused and more of just "hey, it's yet another thing like an ipod or an iphone or an ipad, but tiny". Maybe that isn't accurate, I haven't spent as much time reading about their platform yet, just a first impression.

graphical operating systems need fairly strict ui design conventions. period. they need to be breakable, but encouraged very strongly to the point of where breaking them for no reason makes your app seen as a peice of junk. this is apple's only real advantage in locking out outside apps, being able to blacklist ugly things.

You mean something like this?

Internal memory and internal SD card are two separate things in Android. Internal SD card is simply a part of the internal NAND that the OS treats like a normal SD card. Many phones don't support external SD cards but have moderate amounts of storage, so they compromise.

I'm not sure I follow.

Many phones don't support external SD cards, but officially their apis still need to support external storage with internal SD memory anyway, otherwise they won't pass the Compatibility Test Suite.

The problem is that the internal SD card and external SD card are treated differently.

Android apps by default work off the internal SD card. It's actually a separate partition that's mounted at the same place as old phones used for external SD cards. You can't change the default to use an external card. You can't recover space from that internal partition.*

Here's the kicker. Now external SD cards are mounted somewhere else. (/mnt/extSD) The thing is that many apps don't work with the external SD card. Especially after the latest android release. With android KitKat apps with the, misnamed, external storage permission can read and write anywhere on the internal card. The problem is that now they can read anywhere on the external card, but can only write to a directory on it which is something like "/mnt/extSD/data/app.name" There are a few exceptions for system apps like the camera, but regular apps have to use this weird naming scheme.

It's actually a good security feature, but the fact they don't apply it to the internal SD card just seems to be Google deliberately moving people away from phones with an external SD card. Not cool.

*Without rooting, and knowing exactly what you're doing at least. No way a non expert is doing this.

Internal memory and internal SD card are two separate things in Android. Internal SD card is simply a part of the internal NAND that the OS treats like a normal SD card. Many phones don't support external SD cards but have moderate amounts of storage, so they compromise.

I'm not sure I follow.

Many phones don't support external SD cards, but officially their apis still need to support external storage with internal SD memory anyway, otherwise they won't pass the Compatibility Test Suite.

According to the android documentation it is full-disk encryption based on dm-crypt.

In new cars which are going to come with some sort of standardized infotainment system and which (unlike mine) are all going to have fully-digital clusters soon if not immediately, it will cost basically nothing to add that functionality to the cluster for at least the driver. You can literally use usb webcams with android today, although I don't know how well having multiple cameras actually works ("Since API level 9, the camera framework supports multiple cameras.") It therefore seems like something which would be easy to retrofit into cars in which the cluster does not fulfill major functions for the car. In some vehicles it acts as a gateway for various modules. On the other hand, the W126 Mercedes' cluster (300SD, etc) is really just a gauge-and-light package and it's all-electric, so an interface could be whipped up with the google io board, or arduino or what have you, in relatively short order. If my car had memory seats, I might give it a go myself.

Android is available for x86 these days and you can use hardware acceleration (CPU and GPU). Just set it up and get near-native performance. Or if you have an Android phone just `adb install -r blah.apk` what more can you want?

One that works on most CPUs.

Android is available for x86 these days and you can use hardware acceleration (CPU and GPU). Just set it up and get near-native performance. Or if you have an Android phone just `adb install -r blah.apk` what more can you want?

Do you seriously want to have apps that seem to hang for 2-5 seconds every time a button is pushed just because it needs to save its state before it enters a new one? Most phone apps do not do anything where they need to have their state saved from one moment to the next. The only times you want to have an app continuously saving a file is if it's editing a local document of some kind. If you do happen to have an app that needs to keep persistent data from instance to instance, that's what the OnPause() or OnStop() methods are for. Then this data can be loaded back in when the app regains foreground by using the onResume() method, or regains visibility by using the onRestart() method.

Seriously, read up on the Activity Life Cycle so you can begin to understand what you're talking about.

My post was about what happens when the Phone App takes over. In my development experience, when the phone App takes over, the apps don't always get to perform the OnPause() or even the OnStop() methods before they go straight to OnDestroy(). Having the app actively listening for the phone call event (which occurs about 2 seconds before the phone system activates the phone Application) will give your app an extra bit of time to get the app state saved and properly stopped before the memory manager starts performing an aggressive cleanup to make room for the phone App (this is especially true on low end phones that don't have a substantial amount of application memory to work with).

That may just be Google's goal with ART (a new Android runtime). Details are scarce but it seems that ART compiles to machine code at install time for better power/performance and especially better start times than Dalvik. It's still experimental but if Android starts to support two flavors of ARM, x86, and MIPS, this type of runtime could be the future.

Google is your friend, but I'll save you a little time. Some info from Google and Intel.

kit kat distribution is 8.5% and those numbers are published by Google https://developer.android.com/... As an android developer, I can say that targetting 4.0.3 and higher isn't too big of a deal, regardless of how a user feels about the version they are on. Many new features developed are thrown into the support libraries that end up packaged with the app, and its a rarity to come across something needed from a higher api that's not backported. As an android user, my primary phone is stuck on 4.3 (galaxy nexus) and it really doesn't matter.

Google has ZERO quality control process

What is the Android Compatibility Test Suite if not a "quality control process"?

You obviously do not understand Google "Android" certification process. To be called "Android", officially, you must be certified by Google and have the Play store (and other apps) installed.

From http://source.android.com/faqs...

Google Play is a service operated by Google. Achieving compatibility is a prerequisite for obtaining access to the Google Play software and branding. Device manufacturers should contact Google to obtain access to Google Play.

Other companies have other "stores" (Amazon Kindle is Android, Nook is Android) and do not necessarily use Google Play. And of course you could side load all your apps from your list of "trusted" sites like Nickolai's Android Marketplace if you want. These phones are not "rooted" but are likely to be very easy to root. And I'm sure there will be an ASOP branch you can have, without Google Play services in short order. But chances are, you're already putting Google Play on your ASOP Roms anyways, so ... what is your point again? Oh right, "privacy" ....

If you really want to play a game that's not available for your phone's OS, you can always get an iPad or Android tablet. No new phone needed.

But if it's inherently multiplayer, or if it uses always-connected DRM (such as LVL StrictPolicy), you're likely to need to upgrade your existing smartphone's plan to a plan that includes tethering.

Is integrating with ODK IAP really harder than integrating with Google Play in-app billing?

All 1.2% of them BTW.

The biggest part of this story is that it is now easier to make a trojanized version of a legit app. But it has been possible from day one.

Android apps are written in Java, and Java bytecodes can be decompiled into something remarkably similar to the original source code. Then the source code can be edited and complied back to an app. Hey presto, you have a hacked up version of the app.

http://stackoverflow.com/questions/12370326/decompile-an-apk-modify-it-and-then-recompile-it

But -- and this is important -- the person using this attack has no way to sign the malware with the same signing key as the upstream source of the original, legit app. This means that it is much harder to trick someone into running the malware.

So, if you get an app from the Google Play store, and later someone tries to overwrite your app with a new build that is malware-infected, Android will refuse to install the new app, because the signing key isn't identical.

http://developer.android.com/tools/publishing/app-signing.html

So, if a user gets an email with an attached "free" version of an app that normally costs money, and that user has not previously installed the legit version of the app, and that user sideloads the malware version, then that user will have malware on his/her Android device.

So, as usual, it's easy to protect yourself: get apps from the Google Play store, and don't sideload apps unless you are certain they are clean.

For that matter, if you are browsing the Google Play store and you see an app that has only been up for a day, and claims to be a miraculously free version of a payware app... just say no.

Dude. Have you ever bothered watching the charts on dashboard? The oldest version that is still in common use is Gingerbread which is Android 2.3. In fact it is getting displaced by Android 4.x.

"WebView.addJavascriptInterface requires explicit annotations on methods for them to be accessible from Javascript"

Google appears to have treated this as an API issue. I.e., "the API up to 4.1 was insecure. We now will require method annotations going forward for the JS to execute them." I could care less if backporting this change to earlier versions broke a bunch of apps. It's an easy enough change for those apps to go and insert the explicit annotations. I think Google has made a conscious choice here to not cause apps to break in the name of security, so that their platform can appear to be "more stable".

2.3? Your statistics are very out of date, 2.3 now only accounts for 20% of users, with 4.0 - 4.2 making up 68% of Android users.

Android is open source. Its also linux.

Hint: That link isnt a press release, its the source code.

" AOSP is the proprietary part"

No, AOSP is the free and open part. Android Open Source Project - https://source.android.com/

The Google cloud services are the proprietary part (Gmail, Hangouts, G+, etc). AOSP is a fine mobile operating system without any cloud services. Many third party ROMs for Android devices are pure AOSP. You can also put different cloud services in place of the Google services and distribute that to your hearts content, i.e. the Amazon Kindle.

I agree that Windows Phone is a very nice operating system. I tried an htc 8x for a few months and found it very capable in the basics. Email, phone calls, MMS were really quite good. For some people it may be a better choice than Android, though Android improves so fast that it's hard to be confident there. WP is absolutely not "crap" and honestly if we are comparing only the OS itself it is in league with any other modern mobile OS.

There are two serious problems with WP, IMHO. First we all know that the selection of apps is just awful. This is a chicken and egg problem, something Microsoft has had more success than most in solving before, so perhaps that can be corrected. However, the more serious problem is Microsoft's current strategy to create some sort of universal environment (I think a universal environment could actually work, but so far they are just doing it wrong) For example, you mentioned Win 9 providing unified apps that run on a desktop and a phone. This sounds like a perfect recipe for apps that *suck massively* on both the phone and the desktop. I can't see that helping either platform. Same with the desktop vs Metro issues in Win 8... I like Metro on my surface pro but it's worse than useless on my traditional desktop. There may be a way to have one OS to rule them all, but I'm not sure MS is going to figure it out.

Is this the phone that shall not be named? The only phones i know of are jolla and mozilla os.

Wait, you meant openmoko? I like what they're trying to accomplish, but ...pass.

You're right. There isn't a Linux based phone with any kind of install base whatsoever.

*cough cough*

I guess linux isn't open becasue I can put Windows kernel code in it.

Indeed, but would you then try to claim that the Windows code is open source, because you put it on an open platform? Also, are you only allowed to put your Windows kernel on a specific distro?

Android base (AOSP) is open. Android with Google is not. Simple, really.

Tada

You can feel free to load that on any device you want. All that is needed is an electronics platform to put it on and the vendors to provide you with any drivers for the sensors or the specs to write the driver in question. You see that's exactly what you get when you load custom ROMs. Some guy grabs the AOSP and strips the drivers out of the phone's firmware (or reverse engineers it), and bam, the latest Android 4.4 on your shitty old abandoned phone.

This is as free as putting Linux on a computer. Now which part of the moon do I get? The one with the rabbit?