This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

checking for features in a cross-version compatible way?

 
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
Saloon Keeper
Posts: 18364
56
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic