Win a copy of Java 9 Revealed this week in the Features new in Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

checking for features in a cross-version compatible way?  RSS feed

 
Lester Burnham
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm working on an app that can make use of telephony features if they're present, but they aren't required, so I want the code to detect the presence or absence of telephony hardware and react accordingly. So I figure that getPackageManager().hasSystemFeature(PackageManager.FEATURE_TELEPHONY) should do the trick. Bummer - PackageManager.FEATURE_TELEPHONY was introduced in 2.1, and my app runs on everything from 1.5 onwards. There's an alternative call PackageManager.hasSystemFeature(String), but that was introduced in 2.0 - still no good.
Now, I know that pre-2.0 Android only runs on devices that have telephony hardware, so I could check for the version, but that doesn't solve the problem of how to compile against the 1.5 libraries and still use the newer feature detection capabilities. And I don't want to compile against the 2.1 libraries for fear of inadvertently using a class/method that doesn't exist in 1.5. What's a developer to do?

A somewhat related question is: What does a manifest entry of <uses-feature android:name="XYZ" android:required="false" /> accomplish? I know what it's supposed to indicate, but what practical difference does it make to declare a feature optional vs. not declaring a feature at all? I've read http://android-developers.blogspot.com/2010/10/five-steps-to-future-hardware-happiness.html, but that doesn't really address this issue.
 
Tim Holloway
Bartender
Posts: 18548
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lester Burnham wrote:
A somewhat related question is: What does a manifest entry of <uses-feature android:name="XYZ" android:required="false" /> accomplish? I know what it's supposed to indicate, but what practical difference does it make to declare a feature optional vs. not declaring a feature at all? I've read http://android-developers.blogspot.com/2010/10/five-steps-to-future-hardware-happiness.html, but that doesn't really address this issue.


How does this sound? I have a shopping list minder program. One of the neat features it has is that if you make a suitable magic gesture, it grabs a GPS fix and selects the shopping list for the store nearest to where you're standing. This is obviously not a make-or-break feature, but I'd like to use if where available.

Since location services are considered sensitive, I have to tell the system that I may make use of them, but conversely I don't want the product to be rejected by the installer if the device in question doesn't have access to this feature.
 
Lester Burnham
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The security side (including warning the user) is handled by having a <uses-permission android:name="android.permission.CALL_PHONE" /> - which is required if I want to place calls. But that is different from a uses-feature. I can see its purpose if required=true, but I'm curious about the required=false case.
 
Lester Burnham
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anybody got any ideas about the first part of the question? (I'm also still curious about the second part, but that's not a real problem.)
 
Lester Burnham
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Answering (sort of) my own question:

#1) There is no good way to do this. The solution is to use an SDK version that supports PackageManager.hasSystemFeature (2.0 and newer) and then to test against a 1.5 device/emulator to make sure no newer features were inadvertently used and not guarded from execution on older systems.

An additional difficulty is that calls to non-existing methods (like hasSystemFeature on 1.5) can't be part of any class that executes in 1.5 - they must be moved to a class that is used only on newer devices. In this respect Android works differently from stock Java (which has no problems with calls to non-existing methods being part of classes that are used on JREs that don't have that method).

#2) The only difference seems to be in how the app is handled in the Android Market (and possibly other app stores). If the feature is optional -but not declared in the manifest- the Market will not show it on devices that don't have the feature, thus preventing its distribution to some devices that could in fact run it.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!