I want to implement a program that uses HCE, but my device has Android 4.3 and does not support HCE. Is it possible to deploy a HCE app to devices with API versions < 19?
No, that's not possible. The Android system before version 4.4 (API level less than 19) does not include the software stack that is necessary to perform HCE.
That's the point of having different API versions (levels). Each API level adds (and sometimes removes) functionality that is available to your apps. Specifically with API levels on ANdroid a higher level typically means more (with the exception of depreciation/removal) functionality. As HCE was introduced in API level 19, devices having a lower API level do not support that functionality.
Sometimes, however, there is functionality that is backported to lower API levels by means of Support Libraries. This is typically done to provide a consisted look and feel for apps across a broad range of platform verions and is mainly done for grahical user interface components. However, support for HCE requires modifications deep inside the Android system (NFC system service, NFC low-level library) that cannot be achieved by simply adding a support library to an app.
Related
I am a bit confused on the difference between Android 4.4 Kitkat, and Android 4.4W. I know the "w" version is for my Moto 360, I have been developing for some time now.
But, I can't seem to find any good resource on what 4.4W actually is compared to the regular 4.4.
After the 5.0.1 rollout to wear devices I am even more confused. Were the 4.4W just a temporary thing? Do Android 5.0.1 (API level 21) consolidate the OS on wearables and hendhelds?
The Android API levels are explained here . If you scroll down to 'What is API Level?' this will detail the versions of API that are available for your app to target (I think Android wear needs to target 4.3 and above).
4.4w is as you say a wearable API level that was release prior to 5.0 (Lollipop) as an update of the API to include the Android Wear API's. These Android Wear API's are now part of the 5.0 release.
The Android wear watches moved from 4.4w to 5.0 to reflect these changes at the end of last year.
Hope this helps.
Android 5.0.1 Lollipop
A few bugfixes, including resolving issues with video playback and password failures handling
Android 4.4W extends support for Wearables.
Initial release of Android Wear platform for smartwatches
UI updates for Google Maps navigation and alarms
Offline music playback
GPS support
Android 4.4 Kitkat
Refreshed interface with white elements instead of blue
Clock no longer shows bold hours; all digits are thin. The H, M, and S markings for the stopwatch and timer have been removed, leaving just the numbers.
Ability for applications to trigger translucency in the navigation and status bars
Ability for applications to use "immersive mode" to keep the navigation and status bars hidden while maintaining user interaction
Action overflow menu buttons are always visible, even on devices with a "Menu" key, which was officially deprecated by Android 4.0.
Optimizations for performance on devices with lower specifications, including zRAM support and "low RAM" device API
Wireless printing capability
NFC host card emulation, enabling a device to replace smart cards
WebViews now based on Chromium engine (feature parity with Chrome for Android 30)
Expanded functionality for notification listener services
Public API for developing and managing text messaging clients
New framework for UI transitions
Storage Access Framework, an API allowing apps to retrieve files in a consistent manner. As part of the framework, a new system file picker allows users to access files from various sources (including those exposed by apps, such as online storage services).
Sensor batching, step detector and counter APIs
Settings application now makes it possible to select default text messaging and home (launcher) application
Audio tunneling, audio monitoring and loudness enhancer
Built-in screen recording feature (primarily for developers, as usage of ADB is required)
Native infrared blaster API
Expanded accessibility APIs and system-level closed captioning settings
Android Runtime (ART) introduced as a new experimental application runtime environment, not enabled by default, as a replacement for the Dalvik virtual machine
Bluetooth Message Access Profile (MAP) support
Disabled access to battery statistics by third-party applications
Settings application no longer uses a multi-pane layout on devices with larger screens
Wi-Fi and mobile data activity (TX/RX) indicators are moved to quick settings
Browser text wrap is disabled.
I am wondering what exactly API level means. I couldn't seem to find an answer by searching on Google.
Could anyone please explain what the term API level means?
This actually sums it up pretty nicely.
API Levels generally mean that as a programmer, you can communicate with the devices' built in functions and functionality. As the API level increases, functionality adds up (although some of it can get deprecated).
Choosing an API level for an application development should take at least two thing into account:
Current distribution - How many devices can actually support my application, if it was developed for API level 9, it cannot run on API level 8 and below, then "only" around 60% of devices can run it (true to the date this post was made).
Choosing a lower API level may support more devices but gain less functionality for your app. you may also work harder to achieve features you could've easily gained if you chose higher API level.
Android API levels can be divided to five main groups (not scientific, but what the heck):
Android 1.5 - 2.3 (Cupcake to Gingerbread) - (API levels 3-10) - Android made specifically for smartphones.
Android 3.0 - 3.2 (Honeycomb) (API levels 11-13) - Android made for tablets.
Android 4.0 - 4.4 (KitKat) - (API levels 14-19) - A big merge with tons of additional functionality, totally revamped Android version, for both phone and tablets.
Android 5.0 - 5.1 (Lollipop) - (API levels 21-22) - Material Design introduced.
Android 6.0 - 6.… (Marshmallow) - (API levels 23-…) - Runtime Permissions,Apache HTTP Client Removed
API level is basically the Android version. Instead of using the Android version name (eg 2.0, 2.3, 3.0, etc) an integer number is used. This number is increased with each version. Android 1.6 is API Level 4, Android 2.0 is API Level 5, Android 2.0.1 is API Level 6, and so on.
An API is ready-made source code library.
In Java for example APIs are a set of related classes and interfaces that come in packages. This picture illustrates the libraries included in the Java Standard Edition API. Packages are denoted by their color.
The API is the android platform that make up the core language that
you will use when developing, and as you get the API version higher
the SDK tools should also be updated (which are the tools for
developing and debugging).
You should also take into account the market and how many devices
will support my selected API and choose the lowest API target
possible for your app to adapt more devices.
Should I use the latest 4.0 or 2.3? My phone has android 2.3.5 and it's a HTC Desire HD.
Does the runtime matter or will the applications work still?
First you should choose what device versions you'd like to target: http://developer.android.com/resources/dashboard/platform-versions.html
Based on those numbers it makes sense to currently support Android 2.1 and higher.
Also you should read about <uses-sdk> directive:
android:minSdkVersion and maxSdkVersion define the version range to which your app will be available. If device has Android version out of this range then app will not be visible for it.
targetSdkVersion is the vesrion that you are targeting and that you actually tested against. This attribute triggers Android's compatibility behavior: for instance targeting 2.3 will not show the new look on 4.0 devices.
I think this url will be helpful :
http://developer.android.com/resources/dashboard/platform-versions.html
All versions of android are backward compatible which means that an application designed to work with 2.0's api will work on 4.0 so it basically comes down to whats your target customers. there's still a vast majority that uses 2.x (unfortunately) so it is probably smart to develop for 2.1 and up..
but anyway this is a pretty common question and i'm sure google will produce a lot of useful information in the subject.
Is it possible to achieve the same effect of any hardware independent functionality from the higher API levels in Android OS using the lowest or one of the lowest levels by default?
The compatibility library allows older API levels to have access to some newer platform functionality.
My Android application uses minSdkVersion=3 and targetSdkVersion=8. I used 8 because that is the highest level of API the application was tested on; however, it was written for level 3 and does not use any features beyond that level (except one for level 4 using reflection). Could using targetSdkVersion=8 be causing:
the Android Market to filter the application for some devices? My intention is for the application to be available for ALL devices >= level 3 with NO filtering.
problems in the application since targetSdkVersion=8 will, according to google: "disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications".
No. targetSdkVersion:8 just tells the system that you support SDK 8 features, like installing to SD card. minSdkVersion is what will filter the app and hide it for users with a lower SDK.