Slashdot Mirror

Android studio (http://developer.android.com/sdk/installing/studio.html) is your friend. I am a hard core vs user (hey, it pays the bills) and was tasked with whipping up a proof of concept android application. Android Studio made it every bit as easy as using vs. And on the plus side I get to work with Java again (call me odd but I kinda like that language).

Some people also do (in a sense) use C when they use Dalvik. The NDK is really useful for tight loops for things like physics.

You have basically two choices: Program to a older API, and ignore all new features, or, Program to a newer API, and ignore all older phones.

There is a 3rd choice that is usually ignored in these discussions: support the feature if it's present on the device, but do not require it. Continue running the app without the functionality if it is not available on the device. The term is graceful degradation.

http://developer.android.com/guide/topics/manifest/uses-feature-element.html#required

In reality no-body thinks like that. They say "what features does my app need?" and if that means they have to target 4.0 the do, otherwise it's 2.2. You don't even have to think about it, the IDE keeps track of what you are using and tells you. You can easily conditionally support newer API levels as well.

Also your numbers are wall off, the majority of users are on 4.x now: http://developer.android.com/about/dashboards/index.html

This is the resource I viewed. It seems that notifications will now allow users to interact with the process spawning the notification in a predefined manner. For example picking up a call, or some other action an app can perform. I believe this is more similar to android notifications in jellybean. I don't know for sure though... I don't use smartphones because I find them too emasculating.

Practically speaking, for me using my chromebook, when I get a call on google voice, the notification will allow me to pick up the call from the notification bubble itself by clicking a button. At present when I get a notification about an incoming call, the only action I can perform is to dismiss the notification, or switch focus to the process responsible for sending the notification. Also you can pile notifications together into a list for the cases in which that is useful, and then it adds some options for using images as well. There are also settings for notification priority and persistence as well as a "notification center" that allows users to manage their notifications.

  apparently though some functionality is being removed along with this. Its not something I know anything about personally though.

Digital signatures in android are mostly self signed (you can use a notarized certificate but it has to be issued as valid for 20 years to be on the play store, so good luck). They are for use in verifying updates automatically by the system for installed packages with the same name and for packages requesting to run with shared code or data as another package (upgrade key packages or feature modules for instance).

If you want to verify the source you check the hash or only download from a trusted location. I'm not saying that I agree with the way android is using signatures... it could have been much better... but your signatures in android are not at all the same as a signature for a windows app. Also of note, android has no way of displaying the signature that signed an apk.

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

I'm still waiting to see a Linux distro that works and is advertised as "Android for Desktop".

If you see it, you won't see it for long*. ;-)

* Though admittedly longer if you use Bing ;-)

Google released the NDK (Native Development Kit) not long after Android was introduced because they finally clued in that Java simply isn't fast enough on slower processors to do gaming.

From their website

you should understand that the NDK will not benefit most apps.
....
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on.

I guess you could say that the gaming would be under "physics simulation", but how intense are Android games anyway?

That's the standard way of writing an app, but you can also write native-code apps, and therefore you can also use alternative frameworks (like Qt).

Unfortunately, the days of a cheap, unlimited Microsoft development stack are coming to an end.

Fortunately, other cheap/free unlimited stacks are readily available:

Android

Java

Linux Mint

So long Microsoft, don't let the door hit you in your parity bits on the way out.

Android locks the user into a firmware jail, so that he can't interfere with the platform DRM. Android devices that support "rooting" will clear the phone storage before giving the user root access, and applications providing DRM-exclusive content (I don't know about Netflix, but I know that the Sky app behaves this way) will refuse to run on a "rooted" device.

No, on a tablet.

My pet peeve is when one of my kids borrows my tablet and it comes back cluttered with all his/her stuff.

http://developer.android.com/about/versions/android-4.2.html "Multiple Users

Android now allows multiple user spaces on shareable devices such as tablets. Each user on a device has his or her own set of accounts, apps, system settings, files, and any other user-associated data.

As an app developer, there’s nothing different you need to do in order for your app to work properly with multiple users on a single device. Regardless of how many users may exist on a device, the data your app saves for a given user is kept separate from the data your app saves for other users. The system keeps track of which user data belongs to the user process in which your app is running and provides your app access to only that user’s data and does not allow access to other users’ data."

Although you can get similar functionality from running any number of Apps/Third Party Roms :). My pet peeve is people too last to Google :).

That, and more significantly the iPad / iPhone difference has caused me far more headaches than Android's zoo of screen sizes.

Android was designed from the ground up for arbitrary screen dimensions. iOS wasn't. iOS couldn't even deal with it effectively until iOS 6.0.

Google thinks you are doing it wrong. http://developer.android.com/guide/practices/screens_support.html

With android you just use the compatibility library and you get all the newest features.. even on a phone several years old. https://developer.android.com/tools/extras/support-library.html

All you have to do is static link the latest OS to your app - the miracle of Google.

To be honest, targeting different Android versions isn't that hard thanks to the support library.

I don't really understand the problem of targetting software versions when you have the support library, as for hardware, targeting on making your application run decently on the lowest common denominator is generally sufficient. Faster phones are just going to be... Faster.

The other advantage with Android is the support library, it lets you use newer APIs on older systems. I don't believe this is available on iOS.

Or you could just use the support library and get all the benefits of newer APIs on older versions.

I don't understand how using the support library is holding them back, can you explain this further?

Can you explain to me why developers using the support library is not a solution to this problem?

Because each iteration makes a number of things easier, some substantially easier.

How is the support library not easy?

You are about to see a huge wave of iOS application updates with iOS7, incorporating lots of advanced system features. As Android updates lag in adoption it becomes harder and harder to maintain parity with iOS versions of applications that are just plain simpler to write and have more powerful features.

And why can't this be achieved with the support library?

Why as an application developer would not not make use of updated OS features that shaves tens or hundreds of hours of coding time, when you know that 80-90% of the target market will be able to run it?

As an application developer, why would you shun the support library that brings new functionality from new versions to older platforms?

Facts - 3.2 is the only 3.x line considered in the Android dashboard. The "UI Shift" of Honeycomb was an outlier, with some components of pre 3.x and 3.x making it into 4.x. 4.x is Jelly Bean. 0.1% of the market is on 3.2 and almost 60% are on some variant of 4.x. 60% (rounded even) is much less than roughly 90% on iOS.

60% of Android is *greater than* 90% of iOS, not less.

RAAAARRGGHHH again FACTS 4.x is NOT 75% of the market. It's almost 60%. Sorry, I just keep having to point this out...

Facts - 3.2 is the only 3.x line considered in the Android dashboard. The "UI Shift" of Honeycomb was an outlier, with some components of pre 3.x and 3.x making it into 4.x. 4.x is Jelly Bean. 0.1% of the market is on 3.2 and almost 60% are on some variant of 4.x. 60% (rounded even) is much less than roughly 90% on iOS.

I keep seeing "75%" and "Android 4.x" - please, see THIS -

4.0.3 - 4.0.4
    - Ice Cream Sandwich
    - API: 15
    - Install base: 25.6%

4.1.x
    - Jelly Bean
    - API: 16
    - Install base: 29.0%

4.2.x
    - API: 17
    - Install base: 4.0%

3 API versions across who knows how many minor versions, 25.6+29+4 = 58.6%

58.6 != 75

With android you just use the compatibility library and you get all the newest features.. even on a phone several years old. https://developer.android.com/tools/extras/support-library.html

This is an objective of the Serval Project. Our Serval Mesh software for android currently provides secure voice / chat / file distribution over local networks. But since Wi-Fi has such lousy range, we're also planning to build and sell small Wi-Fi routers with 915MHz ISM band radios for long range / low bandwidth links.

While we're focused on local communications in places where the infrastructure is down / never existed / can't be trusted, with the addition of a Distributed Hash Table, we could provide services over the internet.

Just as an example here, the Galaxy S has Android 2.3 at best, assuming the carrier authorised it; that means that none of the APIs outlined here are included, and apps which use those APIs (or which expect changes in behavior in existing APIs) may not operate properly. Given that most Android handsets are still on 2.x, develoeprs have wisely stepped carefully in implementing the 4.x APIs of course, but it will be an issue in future. (Current releases of many apps misbehave when running on the original iPhone for this reason.)

> Find the better power sources, then let ME decide what the hell to do with that
> power.

Well, yeah, there's this:

http://source.android.com/

You could start with cyanogenmod, see what they're up to.

I don't know about you, but I can only use the USB port to charge my Android phone. Also, when I connect my Android phone to my computer I generally get access to the data contents of the phone (documents, music, pictures, etc.). It seems pretty trivial to devise a "charger" that steals or destroys data on any phone that connects to it.

Data is the real treasure and thus is also the real threat of damage, but AFAIK you can also use the Android Debug Bridge to install programs to connected phones.

"Lower-cost" was a criterion. Just compile natively with the Android NDK in C/C++ or any compatible language.

Android is a great open ecosystem, why not just develop an defacto FOSS Android skin and package repository?

There is a FOSS android skin ... AOSP (which happens to be the "Best" android). Unfortunatly, it doesn't officially support a lot of devices.
http://source.android.com/

There is also a FOSS repository ... F-Droid. It has some useful software, but not much. Seems to me it's a lot of little toy apps.
http://f-droid.org/

The IMEI permission is the same as the permission to tell whether the user is on a call. On Android, if an application is playing audio, it's polite to pause the application when the phone rings. There's supposed to be another way to duck out of the way of a phone call, called audio focus, and I'm not sure why more other applications don't use it.

Go here: http://www.android.com/about/jelly-bean/
The page clearly says that Photo Sphere is a feature of Android 4.2 Jelly Bean.

[Some game] logs into Steam prior to launch no matter what I do. Again, I bought retail rather than via Steam. I haven't tested trying to run either in a disconnected state

After you log in to Steam, it downloads the receipts for the games that you've "licensed" and caches them for at least a few weeks. Then whenever you run Steam in offline mode, Steam uses the cached receipts to validate games' licenses. There were some pretty nasty defects in offline mode when Half-Life 2 introduced Steam in 2004, but those have been mostly worked out over the better part of a decade. The ServerManagedPolicy in the Google Play Licensing service works similarly.

Nobody uses WebOS

And so many people use Firefox OS, right?

Android is mostly free, but only on a technicality.
Google develops it behind closed doors and dumps its code every version, but ther's no possibility to report a bug, submit a patch, or participate in its development.

Ever hear of AOSP? File your bug reports here. It's not "technically" free, it is free.

Firefox OS will be slighly freeer than Android though, since they'll rely heavily on the Android kernel and drivers

It can't be more free than completely free.

"Rooting" means exploiting a security flaw to get root privileges in a device that is designed to prevent users from doing that (e.g. the iPhone or the Android phones sold by some US network operators).

Bootloader unlocking and root access was available and well documented on the first Android device designed by Google (the Nexus One), simply by running the command "fastboot oem unlock".

The same command worked on the second Android phone by Google, the Nexus S, and all subsequent devices, including tablets: Galaxy Nexus, Nexus 4, Nexus 7 and Nexus 10. Unsurprisingly it also works on Glass.

It's just a well know feature of all the devices created by Google. Details: https://plus.google.com/112413860260589530492/posts/jYHhKHYwUJ2.

Google's documentation on how to "root" your Android devices: http://source.android.com/source/building-devices.html.

Is there really a technical reason why it's not possible for them to dig in deeper into an android device assuming the user gives permission (as per the article)?

Yes.

In addition to the standard Linux security model, Android has an Application Sandbox which assigns a unique user ID (UID) to each app when it is run. The apps run as that UID, and can only interact with other apps through secure inter-app process communications.

http://source.android.com/tech/security/

There have been several well known (some even presented at Black Hat) ways of breaking out of the Android sandbox, and Linux privilege escalation exploits, to completely compromise an Android phone. The biggest problem with Android security though is that even Google has been good at adding security features and fixing vulnerabilities, most of the user base is on older vulnerable versions, with added "functionality" from handset makers and operators undermining security further.

why are all permissions granted permanently to apps? Bad design.

Because Android security is designed to protect the community of users rather than each user individually. The last paragraph below explains the philosophy, but it's much the same as many other FOSS systems - not all users can audit or edit source code, but not all need to.

How Users Understand Third-Party Applications

Android strives to make it clear to users when they are interacting with third-party applications and inform the user of the capabilities those applications have. Prior to installation of any application, the user is shown a clear message about the different permissions the application is requesting. After install, the user is not prompted again to confirm any permissions.

There are many reasons to show permissions immediately prior to installation time. This is when user is actively reviewing information about the application, developer, and functionality to determine whether it matches their needs and expectations. It is also important that they have not yet established a mental or financial commitment to the app, and can easily compare the application to other alternative applications.

Some other platforms use a different approach to user notification, requesting permission at the start of each session or while applications are in use. The vision of Android is to have users switching seamlessly between applications at will. Providing confirmations each time would slow down the user and prevent Android from delivering a great user experience. Having the user review permissions at install time gives the user the option to not install the application if they feel uncomfortable.

Also, many user interface studies have shown that over-prompting the user causes the user to start saying "OK" to any dialog that is shown. One of Android's security goals is to effectively convey important security information to the user, which cannot be done using dialogs that the user will be trained to ignore. By presenting the important information once, and only when it is important, the user is more likely to think about what they are agreeing to.

Some platforms choose not to show any information at all about application functionality. That approach prevents users from easily understanding and discussing application capabilities. While it is not possible for all users to always make fully informed decisions, the Android permissions model makes information about applications easily accessible to a wide range of users. For example, unexpected permissions requests can prompt more sophisticated users to ask critical questions about application functionality and share their concerns in places such as Google Play where they are visible to all users.

http://source.android.com/tech/security/

Is there really a technical reason why it's not possible for them to dig in deeper into an android device assuming the user gives permission (as per the article)?

Yes.

In addition to the standard Linux security model, Android has an Application Sandbox which assigns a unique user ID (UID) to each app when it is run. The apps run as that UID, and can only interact with other apps through secure inter-app process communications.

http://source.android.com/tech/security/

Or is there a pool of third party company ready to give away software bits for that?

Yes. As explained in Google's article, each Android ad network distributes its library as a JAR file to include in a project.

Or is there a system-wide API provided by Google?

AdMob, a Google company, is one of the Android ad networks.

You can even do the event handling without touching Java:

http://developer.android.com/reference/android/app/NativeActivity.html

Correction: I'm not sure media players even need it either as of API 8:

http://developer.android.com/training/managing-audio/audio-focus.html

if the two companies have colluded on the matter the console space may get very unpleasant

Unpleasant for Sony and Microsoft, pleasant for Nintendo and Valve. Wii U plays Wii U disc games without connecting, and Steam has an offline mode that doesn't need to connect more than once every few weeks to renew licenses.The License Verification Library on Google Play can be set to operate like Steam, where the license is cached for several days. It also has a strict mode that operates without caching, but Google warns in multiple places that this mode will cause an application not to work on airplanes. The Ouya receipt system isn't entirely clear as to whether receipts are cached.

if the two companies have colluded on the matter the console space may get very unpleasant

Unpleasant for Sony and Microsoft, pleasant for Nintendo and Valve. Wii U plays Wii U disc games without connecting, and Steam has an offline mode that doesn't need to connect more than once every few weeks to renew licenses.The License Verification Library on Google Play can be set to operate like Steam, where the license is cached for several days. It also has a strict mode that operates without caching, but Google warns in multiple places that this mode will cause an application not to work on airplanes. The Ouya receipt system isn't entirely clear as to whether receipts are cached.

It's not because we want it to be difficult. It's that we want it to be useful. If you keep on bumping up your feature count, you will eventually get to a point where what you have done is create a bad programming language (all programming languages are bad programming languages, but it goes double for GUI-based ones).

Programming is more or less the ultimate tool for telling a computer what to do. It is also more or less directly opposed to simplicity. Linux is optimized for utility. You can use it to create a simple interface to the computer, at which point we generally stop calling it Linux, but you cannot simultaneously optimize in two opposite directions. You cannot build a computer appliance using the tools contained within that appliance.

Designing interfaces is all about managing complexity. Most linux distributions opt for more complexity/utility rather than less. There is some complexity for complexity's sake, and some complexity for historical reasons, but utility is the driving force. And Linux users will get very upset at anything that detracts from that utility, as seen in (among other flamewars) the Wayland vs X11 debates.

The Linux kernel and the operating system, naturally.

Well here you mentioned the Security Manager, which is in Java.lang.System, is that what you mean when you say 'system'? Or were you suggesting something else?

I know on the Android Security page it lists 'System and Kernel Level Security' but I'm wondering if you just read that and that's why you're suggesting they moved the security out to the kernel and system, which is just general OS security, or whether you're suggesting they've changed the Java security model in some non-standard way and they're using general OS security mechanisms to interact with it?

And that makes it more secure by controlling native code as well as bytecode, and by narrowing the cross section of control.

It doesn't have to be in the kernel to be native code so suggesting moving it into the kernel for that reason doesn't make sense.

Android phones have come with biometric authentication and have since October, 2011... http://www.android.com/about/ice-cream-sandwich/

However, there is no easy way to the OS to tell the app politely "hey, may you please give back as much memory as you can because something else needs it?".

Activity.onLowMemory()

Since Android API version 1. You're welcome.

In addition to the system-level stuff, Android's SDK also provides a callback that apps should implement for exactly that reason.

http://developer.android.com/reference/android/app/Activity.html#onLowMemory()

The system calls it when it needs to reclaim some memory and apps are supposed to discard whatever they can in order to return memory to the system.