I just came to know to restrict my app only to be downloaded on Phones but not on Tablets I have to enforce the telephony feature into my Manifest file by adding
<uses-feature android:required="true" android:name="android.hardware.telephony"></uses-feature>
Now my questions does the tablets support telephony, Can I make regular calls from tablets. I just came across some posts which says it is possible. If yes the how to restrict the app to get downloaded only on phones not tablets. I am bit confused. Could anybody have the genuine answer for this.
I also read the following post on Android FAQs
What kinds of devices can be Android
compatible?
The Android software can
be ported to a lot of different kinds
of devices, including some on which
third-party apps won't run properly.
The Android Compatibility Definition
Document (CDD) spells out the specific
device configurations that will be
considered compatible.
For example, though the Android source
code could be ported to run on a phone
that doesn't have a camera, the CDD
requires that in order to be
compatible, all phones must have a
camera. This allows developers to rely
on a consistent set of capabilities
when writing their apps.
The CDD will evolve over time to
reflect market realities. For
instance, the 1.6 CDD only allows cell
phones, but the 2.1 CDD allows devices
to omit telephony hardware, allowing
for non-phone devices such as
tablet-style music players to be
compatible. As we make these changes,
we will also augment Android Market to
allow developers to retain control
over where their apps are available.
To continue the telephony example, an
app that manages SMS text messages
would not be useful on a media player,
so Android Market allows the developer
to restrict that app exclusively to
phone devices.
Thanks
Not all tablets support telephony, but some do.
Actually telephony is an "umbrella feature", where the tablet may support some sub-features.
There is a an explanation on this blog post and links for further information.
if you have a PC windows tablet, you can use USB telephony device or so called usb voice modem to create a full featured telephony solutions. Since it uses usb to connect to your tablet and resolve the hardware layer issues.
Related
I understand that to access SIM/eSE from an Android app we need to install Open Mobile API addon on Android Studio. However, is it true that it will not work on all NFC phones? For example, do some OEM limited access to SIM/eSE? Or are there phones where only custom firmware will work with Open Mobile API?
Also, is there a list of phones that support Open Mobile API by default?
That's correct. The phone needs to implement the Open Mobile API (by means of the smartcard system service) in order for your app to be able to use it. Not all devices implement this. It's mainly devices from Samsung, Sony, and HTC which support the Open Mobile API.
In addition to that restriction, you need the SE (UICC/eSE) set up to allow your application (this is handled by GlobalPlatform SE Access Control) to interact with the SE.
Finally, I'm not aware of any complete list (and ther probably is none). However, have a look at the question List of OMAPI supported devices to get some ideas on how to test devices and how to let Play Store generate a list for you.
You may also want to read our report Open Mobile API: Accessing the UICC on Android Devices to get some idea about how the Open Mobile API works.
I was looking for Android Dual-SIM API for Android, but more or less I found nothing. As far as I understand, there is no public API from Google/Android, only specific implementation of each manufacturer. Therefore is very hard to implement application supporting Dual-SIM (or more SIM) devices.
If I am not wrong about it in this time (17.02.2015), is there anything we (developers) can do to request/force Google to implement this?
I would like to "guide" all developers to same place (if there is one) to increase our power.
Thank you for any feedback.
[UPDATE: 10.03.2015]
Android support DUAL-SIM/MULTIPLE SIM cards in API since ANDROID 5.1.
Whether you want to share your phone with a family member or better manage your mobile costs, Android Lollipop 5.1 now lets you use more than one SIM card on a device with multiple SIM slots.
Read more here and here.
AFAIK, Google has never openly discussed their rationale for not supporting multi-SIM devices out-of-the-box, even though manufacturers are quite clearly gung-ho about it. None of Google's Nexus devices has had this feature, so obviously they do not advocate multi-SIM devices, whatever their reason.
I suspect it has something to do with security, and also with Google's perception of a smartphone being an abstraction of an individual, and all data being connected with a single phone SIM account, and thus representing that individual. Or maybe I'm crazy.
The official Google review branch for this feature is here. And the only relevant post on SO for working around this is here.
UPDATE:
Both Multiple SIM Card Support and True multi-user support are available.
Does anyone know how to build a test app that plays well with Samsung Knox? What do I have to so differently to build an app for samsung devices that have Knox installed on them?
From KNOX 2.0, App wrapping is not required.
This is from the Samsung KNOX 2.0 whitepaper:
The KNOX 2.0 platform features major enhancements to the Application Container from the original KNOX platform. The most significant enhancement is the elimination of application wrapping. This is achieved by leveraging technology introduced by Google in Android 4.2 to support multiple users on tablet devices. This enables enterprises to easily deploy custom applications without requiring Samsung to wrap the applications. It also reduces the barrier to entry for independent software developers wishing to develop applications for the KNOX container.
Complete White paper can be found here: http://www.samsung.com/ca/business-images/resource/white-paper/2014/03/Samsung_KNOX_tech_whitepaper_Final_140220-0.pdf
Multiple user: (Complete Ref: http://developer.android.com/about/versions/android-4.2.html#MultipleUsers)
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.
Might want to take a look through here https://www.samsungknox.com/en/blog/what-app-wrapping and here https://www.samsungknox.com/en/resources.
Looks like you have to develop the app and then send it in to Samsung to have them 'wrap' it.
Personal data on Samsung devices is protected from mobile threats such as ransomware, malware, and unauthorized rooting, even while you’re using your device.
Secure Folder
Samsung Pay
Samsung Health
Samsung Pass
Empower enterprise mobility by leveraging Samsung Knox and ensure seamless device deployment with advance security, taking device management to next level.
I am trying to find out about sensors in Android phones.
Do all/most phones have a basic set of sensors or do I have to look at the individual specifications to find what each supports. The specs I have looked at seem rather unclear as to what each phone actually provides.
I haven't been able to find even an out of date list of phones and their sensors, but if anyone can point me to one, I would be grateful.
I should have made it clear that I am looking for this information as my application may need a specific sensor or combination of sensors. If these are not generally available then the application may not be worth developing. In addition, it may be possible to use more than one combination of sensors to do the job, so information on what is likely to be available will aid development.
Android has no minimum hardware requirements for Android when it comes to sensors. The Android Compatibility Program states:
Android 2.3 includes APIs for accessing a variety of sensor types. Devices implementations generally MAY omit these sensors, as provided for in the
following subsections.
The best way of going about it is to specify the sensors your app uses in your AndroidManifest.xml file, along with whether or not those sensors are required for the application to work. The android market uses the details of required sensors (and other hardware features) to hide the app from unsupported devices on the market.
Details of the different flags and how to use them can be found here.
When you publish a draft of the app, you can see a list of all the devices which support the features requested.
What are the differences developers should be aware of?
I am aware of these limitations:
Pre-installed software. Real device can have preinstalled a lot more applications than emulator.
You cannot use "capture" photo/video functions in emulator.
According to emulator documentation, its limitations are:
The functional limitations of the emulator include:
No support for placing or receiving actual phone calls. You can
simulate phone calls (placed and received) through the emulator
console, however.
No support for USB connections
No support for device-attached headphones
No support for determining network connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insert/eject
No support for Bluetooth
IMO you can use emulator to simplify UI development, to view UI on "device screen", to be sure that app layout is ok, app can be run, you can test some special cases by simulating gps position, network speed or messaging etc. But testing on real device is a must.
With the 1.5 SDK the following limitations exists (from the SDK website):
No support for placing or receiving actual phone calls. You can simulate phone calls placed and received) through the emulator console, however.
No support for USB connections
No support for camera/video capture (input).
No support for device-attached headphones
No support for determining connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insertion/removal
No support for Bluetooth
No support for Multitouch
Based on experience I've noticed the following differences in actual developemnt:
There are bugs you'll be able to ignore in the emulator that will crash the device (not closing Cursors for example)
You interact with the device differently than the emulator. I use landscape mode a lot more with the real device than I do with the emulator.
There's a different CPU. Things that are fast on your emulator will be slower on the real device.
You can dogfood with the device. It is harder to dogfood with the emulator.
There is a google group here if you need real device testers.
One cannot test touch events with emulator which has to be tested only by means of mouse clicks on emulator which any developer going to develop an application based on touch screens should be aware of.
I'd say the main thing is that there are several "real devices" currently using Android, and there will be more, with different hardware endowments -- some will have GPS and some won't, ditto for touchscreen, real keyboard as opposed to virtual on-screen one, camera resolution, etc, etc.
While the OS will do a lot of the heavy lifting for you, you still want to make sure your design a user experience that makes sense on every Android device you intend to support, despite the variation in their HW features -- in this sense, designing applications for Android is more similar to designing them for, say, Linux, Windows, or the Web (cater for a wide variety of hardware-configuration details), rather than e.g. Macs or iPhone (where you need to consider a much narrower set of possible HW configurations).
The emulator is (or tries to be;-) "one" Android device -- but there will be others ("real" ones;-) with different screen resolutions, input peripheral devices, etc, etc...
One comment regarding google accounts: With version 8 of the google APIs for Android 2.2, you can add a google account on the device. However, it will only allow authentication for tests of the google APIs (e.g. google documents) but not syncing of contacts etc.
This is a bug, since camera and video support was attempted (incorrectly): the camera and video intents do not store their output in the MediaStore database after "capture."
In simple terms, an emulator is a device that runs on your computer (as software) whereas a real device is something you can hold. There will of course be a few differences between the two such as some device-specific features won't be available on the emulator.
Edit: Removed a link from the answer that had expired.