Slashdot Mirror

It's certainly a problem for those who still need to use Java 1.4 or Java 5 (which are out of security support now, but are still widely mandated in the industry).

Including, surprisingly, Android.

OpenJDK 1.6 works with Android, but if you want to use the official one they recommend, you have to use 1.5 (Java 5) because of some oddball parser issues in official Oracle JDK 1.6.

So one's choices are ot use the unsupported OpenJDK 1.6 with Android, or the unsupported (but Android-supported) JDK 1.5. Bleh.

I hope Android 3.0 fixes this. This is an issue on Ubuntu 10.04 and onwards, as JDK 1.5 is no longer in the repository and you have to do some hacks to get 9.x JDK 1.5 in...

http://source.android.com/source/download.html

For enterprise IT users, the environment with iOS 4 and Android 2.2 (which most of the Android devices in use today aren't running) isn't appreciably different.

Not to pick nits on your Android 2.2 usage claim, but as of the last installed base breakdown 2.2 is on 33.4% of all devices, per:

http://developer.android.com/resources/dashboard/platform-versions.html

You're correct in that isn't "most." However I know many people who have iPhone 3G or even 3GS models who can't or won't upgrade to iOS 4. Do you know of any equivalent source to see installed iOS versions? I'm curious to know if iOS 4 is really running on "most" i* devices.

Both were late to the game with things like strong password enforcement, remote wipe/lock, VPN etc. Both are now in roughly the same place in terms of business support.

The difference being Android could have those added by people other than Google.

Found the list online, and I admit that it's quite a bit larger than I thought - e.g. I didn't expect to see java.sql there.

Except they never tried to pass it off as Java. It's Dalvik. It just happens to share Java's grammar.

Google's What is Android? pages mentions Java several times. A notable quote includes:

All applications are written using the Java programming language.

It's not like that is passing mention either. It's repeated several times throughout the site. From the Application Fundamentals:

Android applications are written in the Java programming language. The compiled Java code -- along with any data and resource files required by the application ...

Except they never tried to pass it off as Java. It's Dalvik. It just happens to share Java's grammar.

Google's What is Android? pages mentions Java several times. A notable quote includes:

All applications are written using the Java programming language.

It's not like that is passing mention either. It's repeated several times throughout the site. From the Application Fundamentals:

Android applications are written in the Java programming language. The compiled Java code -- along with any data and resource files required by the application ...

i hate to break it to you but ios (obj-c) and android (java) don't endorse user apps in c++ either.

Objective-C in a Cocoa program for iOS or Mac OS X can be linked to C++ code (source). The Android SDK has an extension called NDK allowing use of C++ along with Java.

You have to specify which phones your stuff runs on...

It's a little easier than you make it out to be:
http://developer.android.com/guide/topics/manifest/manifest-intro.html

Specifically,
http://developer.android.com/guide/topics/manifest/uses-feature-element.html

You have to specify which phones your stuff runs on...

It's a little easier than you make it out to be:
http://developer.android.com/guide/topics/manifest/manifest-intro.html

Specifically,
http://developer.android.com/guide/topics/manifest/uses-feature-element.html

The point made repeatedly throughout TFA:

Once again, I call bullshit . I'm an adult.

...

I'm an adult.

...

Really? But I'm an adult.

So point your browser to Android's development tools and program to your heart's content. No one is forcing Apple stuff on you.

How does the AOSP relate to the Android Compatibility Program?

The Android Open-Source Project maintains the Android software, and develops new versions. Since it's open-source, this software can be used for any purpose, including to ship devices that are not compatible with other devices based on the same source.

The function of the Android Compatibility Program is to define a baseline implementation of Android that is compatible with third-party apps written by developers. Devices that are "Android compatible" may participate in the Android ecosystem, including Android Market; devices that don't meet the compatibility requirements exist outside that ecosystem.

In other words, the Android Compatibility Program is how we separate "Android compatible devices" from devices that merely run derivatives of the source code. We welcome all uses of the Android source code, but only Android compatible devices -- as defined and tested by the Android Compatibility Program -- may participate in the Android ecosystem.

Sorry, but I beg to differ. To get access to IMEI etc. you need READ_PHONE_STATE permission. To WRITE to SD card you need WRITE_EXTERNAL_STORAGE. OTOH it is true that any app can read SD card content without any additional permissions.

Sorry, but I beg to differ. To get access to IMEI etc. you need READ_PHONE_STATE permission. To WRITE to SD card you need WRITE_EXTERNAL_STORAGE. OTOH it is true that any app can read SD card content without any additional permissions.

Yet, the application must have requested WRITE_EXTERNAL_STORAGE in its Manifest.xml. If Market didn't tell you about it, that's a Market issue.

All applications can READ from the external storage, which is considered public. Private data, OTOH, is required to be stored on the internal storage. This is secifically mentioned in the Developer Guide. If an app is storing private data on the external storage, then you need to tell the author that he or she is stupid. You can, of course, always remove files from the public storage by connecting mounting the SD card on a PC.

As I said in the last Android article, all apps have access to your sdcard, and to your identity (esn/imei/meid/phone number)

The Android Developer reference says otherwise:

A basic Android application has no permissions associated with it, meaning it can not do anything that would adversely impact the user experience or any data on the device. To make use of protected features of the device, you must include in your AndroidManifest.xml one or more tags declaring the permissions that your application needs.

Let's also not forget that there's no way to "return" an app or even to politely ask for your money back. If the app doesn't work, you're screwed.

According to Androd Market, you can return the app for a refund within 24 hours:

http://market.android.com/support/bin/answer.py?hl=en&answer=134336

Does this not work for you?

(I'm just parroting the link given a few posts above -- I haven't tried this myself)

You can return Apps for a refund (within 24 hours) which is quite a good idea.

http://market.android.com/support/bin/answer.py?hl=en&answer=134336

If 100% native apps written in C/C++ (or even Go) were possible, I'd already be developing for android

http://developer.android.com/sdk/ndk/index.html#overview

Just about the only thing you will need to use the DalvikJava for is integration with the app system. Which you want.

There are only 9 countries in the world where you can actually buy apps on android market OR develop an application and actually sell it!
Which means the app store really has no competition in 100+ countries for games and quality applictions. Google doesn't really seem to care about most of the world.

Austria
France
Germany
Italy
Japan
Netherlands
Spain
United Kingdom
United States

http://market.android.com/support/bin/answer.py?hl=en&answer=143779

Last I checked, the official docs online from Google were for like 1.0-1.5 and we're on 2.2. In short, horribly out of date (usable in some cases, but out of date).

Are you looking in the right place?

The proper place is here and it's always been updated the moment a new version of android is released. You can even filter by release and it'll even automatically hide/fade the relevant parts that aren't supported by the API level.

Android 2.2 was released in May 2010 just after the launch of the HTC Desire in the UK. It took HTC until July to customise Android 2.2 for the HTC Desire, and we are told that T-Mobile UK will finish their layer of tinkering later this month (September). That's over four months to apply branding and load customised apps. With Android 3.0 promised in Q4 (from October), it look's like we'll be a whole version behind. Again.

I think that's the hard part.

Think about developing a handheld game that needs to work on all screen sizes (iPhone, iPad, Android, Simbian, etc etc....). There have been efforts to minimize these problems.

Then think about the UI for a web page or game. There have been some pretty successful results, while they are anything but simple.

Now think about adding a 3rd dimension to all those problems. It's not as easy as saying "just make it realistic". There is a reason why lives are spent on UI. It's not an easy task and it just got a 3rd Dimension.

Oh and was it just me or did anyone think it was just a 3D FPS (Like Tribes, Q3, you know.... All FPS?) and not a 3D Displayed FPS.

And with APG and k9mail on Android this is simple to use on a mobile phone. I bet the UAE (and the USA) government would have a fit if everyone sent emails with 4096 bit encryption.

All applications are written using the Java programming language.

That is completely unambiguously indicating that it's Java. So, if it doesn't include all the libraries that Oracle says are a part of Java, then they're definitely infringing on at very least Oracle's trademark.

http://developer.android.com/guide/topics/fundamentals.html

The only difference here is that Sun sued over calling something "Java" that wasn't exactly Java. Oracle is doing something a bit deeper in that they are saying that Google can't fork the language even if they call it something different.

I think I've missed something - last I saw, Google isn't calling it something different? If they were, I can't see how this would be a problem. But when I look at the Android Fundamentals page, this is the first thing I see (emphasis added):

Android applications are written in the Java programming language. The compiled Java code — along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an .apk suffix. T

So where do you see that they're not calling it Java?

Battery life, it has to be much longer than a laptop.

Since many laptops these days are getting battery life of 6-8 hours (around the same amount of time the iPad is getting), what kind of battery life are you hoping for?

Software support, if the screen resolution is greater than any other device then some software may not work or will appear small.

Screen size support has been addressed and pretty much fixed since Android 1.6 came out, so it shouldn't be a problem.

Price, if it's not much cheaper than the iPad then that's a failure.

How would it be a failure? Its running newer, faster parts and it seems like the screen might be a higher resolution. Better, newer parts will raise the price making it possibly match the iPad. And if people feel its a better unit, or even an "upgraded" version of the iPad for the same price, then they will buy it.

The actual OS is important, but given it's Android it's unlikely to present a problem.

And that its Android 2.2 should help too.

Take a look at the Android namespace hierarchy. Note all of those java.* things? Looks a lot like they are claiming that it's Java to me. I don't see any java.* classes in .NET, for example.

Thankfully, they've got a backup plan (sort of):-
http://developer.android.com/sdk/ndk/index.html

The fact that the de facto standard syntax for writing code that gets compiled into dalvik bytecode happens to be java, does not mean an android phone has any java on it.

Allow me to draw your attention to

Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.

on Google's What is Android? page (emphasis added by me).

Native code is also a possibility.

This feature is really part of the upgrade to the bluetooth stack me thinks. Up until now, there was no way to do voice dialing with Android phones.

No this feature always came with android 2.2 but most reviews didn't cover it for some reason.

http://developer.android.com/sdk/android-2.2-highlights.html

I am taking hurdles that are already there and making the user remove them when it makes sense, instead of making them sign a paper saying they are OK with hurdles located somewhere distant being removed because they are an eyesore. You are never PLACING hurdles in front of anything. Instead you should only ever be selectively removing system access controls when and where it makes sense.

I see what you're saying, but that methodology has the serious limitation in that it annoys the user. Furthermore, the security derived from your implementation is directly proportional to how many times you annoy the user - namely, the threshold that you set. At an extreme (pop-ups every time an SMS gets sent) it is very much more secure than the current implementations, since the user will immediately notice unsolicited SMS messages. However, anything short of that adds basically nothing, as all the malware has to do is ride out the threshold. And, unfortunately (speaking to user behavior), whatever the threshold is, if it's not very low, the users will likely get frustrated with the interruptions and automate through it (e.g., Internet Explore + ActiveX installation popups, or UAC).

It's sad, because a handful of power users could definitely take advantage of the system, but I am of the general opinion that those power users are not typically the ones that need protection from malware.

Yes they do. And they are impossible to judge. As I said in response to another post somewhere, you are asked to choose before you have even used an app. Well how do you know it's request to SMS is unreasonable? I cannot think of a single application type I could not see some potential in sharing information from via SMS. And the same is true for many users - in a media player they would be like "cool, I can SMS movies I like to friends".

...

We can disagree but it's very dangerous for Android to continue doing this - there will be many more, and many worse exploits. That's why I'm so fired up about this because I see it as a huge looming threat and I don't want to repeat the mistakes Microsoft made for any mobile OS moving forward.

Android has a generally good security model but it's undermined almost wholly by the presentation of user interaction for adjusting app controls.

I can only speak to Android, but I think I can say something particularly useful in this context. Specifically, on an Android platform, an application that wants to send text messages will likely do so not by requesting permissions to send SMS messages, but rather by soliciting Android's assistance via Intents. In this manner, if my application has text or media that it wants to send to someone else, it simply wraps it in an Intent describing the nature of it and passes it to Android, which proceeds to connect it to the appropriate service, oftentimes with user interaction.

Using Intents, applications can send data using services like Internet or SMS without, themselves, needing to request permissions to directly access the SMS system. Through Intents and IntentFilters, a type of ad-hoc network-of-trust is established: if I start only with non-malicious services, and never install apps that can send SMS messages, then malicious SMS messages cannot be sent; any app that wants to send SMS messages has to go through a trusted path, which (in a reasonable installation) involves things like pre-populating text fields and presenting the user with a "Send SMS" dialog.

As such, your theoretical SMS-sending media player should exist without needing to request a single permission. It'll work wonderfully and automatically integrate with the software on the phone to send media updates via SMS, Facebook, GMail, and any other paths that are present on your phone. Any application that requests "Send SMS" capabilities is a huge red flag; it wants to send SMS messages outside of the scope of the existing infrastructure. Unless I have a good reason to allow this (e.g., Google Voice), it's an automatic "no", no confusion necessary.

I'll open with a disclaimer: most of my smartphone experience and awareness is centered around Android phones. That said, this article is yet another with a standard theme: "Remember, you stupid public, that smartphones are still computers". This is another in the a set of articles about people who write phone applications requesting a smorgasbord of permissions, receiving them from the user, and using them maliciously. Put simply, this is another in the formulaic series:

Mystique of Computers * Fear of Malware * Novelty of Phones = Profit

Chris Wysopal, co-founder and technology head at security firm Veracode, which helped the BBC with its project, said smartphones were now at the point the PC was in 1999.

No offense, but Chris Wysopal is an idiot. Modern smartphones run every application in a sandboxed per-application environment with fine-grained permission controls that are, to some degree, opaque to the user. These applications, by a well-defined default, must exist in a central repository managed by a powerful authority and receive realtime user reviews. This is nothing like PCs in 1999 (remember, that was Windows 98). Then again, he's certainly quite biased, as his company makes a living certifying applications.

All of the information-stealing elements of the spyware program were legitimate functions turned to a nefarious use.

Yes, of course they were. BBC didn't actually do anything innovative, like find an exploitation or break out of the sandbox. They just abused the OS's granted privileges to the fullest extent. Is this actually a problem? Given any set of privileges and any degree of fine-grained control, you can still abuse whatever you're given to the fullest extent.

At least one fundamental thing failed here: the user installed a phone game that requested privileges such as:

• SEND_SMS: Allows an application to send SMS messages.
• INTERNET: Allows applications to open network sockets.
• READ_CONTACTS: Allows an application to read the user's contacts data.
• READ_OWNER_DATA: Allows an application to read the owner's data.
• ... to name a few

As the owner and user of the device, it is ultimately your responsibility to determine what software you install on your phone. If you are downloading a single-player game that asks for these kinds of permissions, you had damned well better check out the source of that game. If it's not a company that you are comfortable trusting and you still install it, then you are (frankly) stupid. BBC does, of course, presume that its users are stupid.

But that's the problem ... no amount of protection will allow stupid people have free access to a computer and remain protected. You have to strip away something from one of these factors ... either whittle down free access or reduce the base of stupid users. Better design models only serve to decrease the thresholds required for either.

Is there an inherent issue with those kinds of permissions being available and grantable? Sure, there is! Applications, especially closed-source ones, are effectively black boxes. The permissions that I am presented with at installation-time are, in fact, my only real insight as to what the application is capable of doing. Arguing for a finer grain of control is pointless, though. Regardless of what permissions are grantable, you will never circumvent the fundamental problem that stupid users will blindly install applications. Presenting them with more information will not change that fact.

It is the job of the OS vendor (Apple, Google, RIM, etc.) to declare a set of permissions that reasonably mitigates the dangers of overly-gener

No. Each Android app runs as a separate Linux userid. Even if you give the app filesystem access, it can't write to files that belong to other apps, let alone rewrite the apps themselves.

That would all be fine and dandy if there were no SD cards formatted with FAT32 with no filesystem security, and things like "move apps to SD card" features on top of that. These are simply bad choices for security.

Is it possible for an app to request access to the filesystem, then modify another existing app with a payload that makes it do all the dirty work?

No. Each Android app runs as a separate Linux userid. Even if you give the app filesystem access, it can't write to files that belong to other apps, let alone rewrite the apps themselves.

The correct term is Android Market

However, Google also says that Android code should use four-space indents.

> huge dependency on Google for future development

Yeah, if only they released the source:
http://source.android.com/source/index.html

or if people other than Google released the hardware:
http://en.wikipedia.org/wiki/List_of_Android_devices

or if Android didn't use such unpopular, old fashioned technologies as Java, C++, Linux, XML etc etc.

Never heard of MeeGo, so I just googled for it. It appears to be something Nokia is doing - presumably because they're shit scared that Android/iPhone has just rendered them unnecessary. Who's going to want some shitty proprietary OS now? Intel are no fools - they're porting Android to x86. Perhaps Nokia are better off partnering with Apple?

It doesn't sound to me like the cached responses expire. Where did you get that information from?

Right here.

If there ever was a problem with the DRM then it could never be fixed unless users reinstalled their apps. This method is more secure. The cached response from last run seems like the best solution possible.

In either case, local libraries and apps using those libraries would need to be updated - I'm not sure what else you mean. Besides, "secure" what? DRM is not there for anyone's "security."

http://www.android.com/ -- you learn Java, the projects are small in scope, and you can demo your stuff easily to friends, and it is only getting hotter. :-)

Really? Can't break out of the VM, period?

If the application uses this little toolchain to provide a native code .so, you're able to break right on out of the VM, possibly never to return. It's not very hard at all- and there's a host of possible exploits to apply once you're in that space, all depending on how locked down the user account actually is on your Android device.

Let's all face a real fact here. Security has little to do with technology in and of itself. There's an aspect of it within the design of something, but in the end it's people that provide security as well. You would fail at securing something outright- you lay entirely too much faith in things like a VM to protect your system design.

As for "developer's option" whether or not to cache, let's be honest... at least half the developers publishing commercial apps don't have the slightest clue in HELL how to implement a secure caching scheme, and they aren't going to purchase a proprietary one that demands more money up front than they're likely to earn from the app's sale. So, anybody care to guess what's going to happen? Most apps in Market are going to end up checking the server every goddamn time, because the alternatives are too hard/expensive for most Android publishers to deal with.

First of all, the devs don't have to implement very much else than an API call ("LicenseChecker.checkAccess()") and supplying code for the two callbacks "allow()" and "dontAllow()". See http://developer.android.com/guide/publishing/licensing.html (yeah, they call it a "licensing service" rather than DRM, no real surprise).

Second, it's very easy for devs to choose the best (from our point of view) option: you use an instance of either "ServerManagedPolicy" (uses cache fallback) or "StrictPolicy" (insists on connection).

they shouldn't be using Android anyway because it's not an open platform.

So, a couple of Chinese companies with obscure products have not released their sources and that makes Android as a whole "closed?" Android is open source last time I checked. As in you can get the source, change it, compile it, get it to work with your own hardware, and redistribute it. In fact, those obscure companies and products are a testament to that.

The fact that some are trying to lock down their bootloaders, not disclose drivers, or trying to lock down root access, etc. does not make the underlying operating system closed in any way.

Android supports something called live wallpaper. This is how animated wall papers or dynamic wall papers are achieved. It basically runs an app and provides functionality for changing the wallpaper.

I've made a live wallpaper myself and of course it doesn't just display a single jpeg. But for an app to request all of those permissions, users should be skeptical when installing the app. Unfortunately I don't think many users really read those messages or understand what they're getting into.

This is sort of like the early days of MS-DOS, back when everyone trusted everything they downloaded.

Although Android apps do run in a security "sandbox" whereby they can't access the user space of other apps (see http://developer.android.com/guide/topics/security/security.html for more information), they can and do access the general configuration information of the phone such as personal data, phone calls, and SIM information, and some apps obviously need to use the phone's dialup or networking capabilities.

At install time, the user is shown a list of resources the app will access, but since most apps need at least some resources on the device to be useful, we are all in the habit of just clicking past this screen and installing, and then hoping the app is not malevolent in some way.

I think there needs to be some sort of sandbox where apps can reside prior to full release into the wild. Probably, most users won't understand how to use such a feature, but knowledgeable users would make use of it, and ultimately it would help promulgate security concepts into the general consciousness. Power users who write reviews and prominent blog pieces on Android will be able to help guide the masses to safer use of apps.

The android developers site has an excellent list of supported media formats. http://developer.android.com/guide/appendix/media-formats.html The iphone 4 specifications http://www.apple.com/iphone/specs.html claims that the iPhone 4 supports AAC-LC and h.264 which android supports as well. So looks like you have an easy match for high quality as well.

I won't go to Android at this point because there are too many models with different features and different OSes out there.

In June two Android OSes made up for 75% of the Android devices.

Right now four versions of the OS are making up the bulk of the phones

http://developer.android.com/resources/dashboard/platform-versions.html

With an iPhone I know what I'm getting in a model
http://en.wikipedia.org/wiki/IPhone_4

With Android I have to figure out the phone and what OS it's running to decide what I want
http://en.wikipedia.org/wiki/Android_(operating_system)#Update_history

http://en.wikipedia.org/wiki/List_of_Android_devices#Smartphones

This is something a lot of people get confused. ("If it's open, why do you have to root it?")

What it is, is the AOSP (Android Open Source Project) is completely open. The source code to the Android tree is right here. You can do whatever you want with your own build of Android, nobody is stopping you. When it comes to phones, this is where the "openness" ends, other than the manufacturers having to contribute changes back to the source (which they do). However, the build of Android you buy on your phone certainly does not have to be open. The telcos usually want the bootloaders locked so you can't run an "unapproved" build of Android, and the provided builds of Android may include this crap, or even go as far as AT&T does and disable loading applications from anywhere but the Marketplace.

If you want to avoid the sort of problem like this shovelware/bloatware, make sure to get a phone running stock Android, like the Droid or the Nexus One (for example) that hasn't had the OS itself modified by the manufacturer (like with HTC Sense or Motoblur) or by the carrier (like with the EVO).

macs4all, Posting as AC because I've reached my daily posting limit... >:(

o long as you're aware of the facts, and didn't have to read a massively long agreement before being aware of it.

People are acting like this is the first "massively long" EULA. Guess what? THEY'RE ALL MASSIVELY LONG! But, it really IS your responsibility to READ them. Having said that, I don't, you don't, and not one person in ten-thousand reads them. They all suck. I'm sure Android has a massively-long EULA too, just as chock-full of confusing terms and conditions as every other EULA.

It's unfortunately what EVERYONE's legal department insists on. And you know why? Because otherwise, people will sue, and sue, and sue (and if there really IS no disclosure), win...

Everything can't be in the first paragraph; so what? If you don't like it, don't click "I Agree." Simple as that.

BTW, here's some Android Devs. bitching to high heaven about what Google's Android EULA gives Google the power to datamine. I don't see one single Apple-Hater bitching about that in the comments to this article.

BTW, I can't even FIND a copy of the Android EULA for USERS (not devs) on Google, but the Android Developer Distribution Agreement is EVERY BIT as long and involved as Apple's EULA in question.
 
 

Before you say it - how often does GPS search for a cellular network? On a schedule? Or just when it losing signal... as in when you move location?

So, you are SPECULATING on a FALLBACK mechanism being used for nefarious purposes?

You do realize, don't you, that there is already a protocol for "tower-handoffs" that works MUCH better than using GPS, because GPS doesn't take into account things like the instantaneous traffic load on any particular tower (and towers pretty well overlap coverage in most urban and suburban areas, that's why you can drive around all over and (usually) not drop a call).

Isn't it getting a bit hot under that tinfoil hat? (Or maybe that's just the mind-control waves being beamed into your head by the Gummint)...

It is sad, that's for sure, but at the same time it's unfair to blame Android for this debacle. Android is the OS, and it's not Google's fault that Motorola is so blatantly circumventing the spirit of the OS..

Google could use GPL3.

To submit code you have to waive copyright/patent claims. http://source.android.com/source/cla-individual.html I can't see them switching the license. It would really be a dick move, but it would be just desserts for the telecoms.