Do all Android phones have a minimum set of sensors - android

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.

Related

API documentation and limitation for NFC tags on Android

I'm new at NFC and I'm trying to look up documentation what is possible and what is not but I have a hard time finding the right ressources.
I'm therefore looking for guidance pointing towards the right ressources.
The problem I have is a lot of the ressources I find require a third party app. E.g. Trigger. With Trigger you could implement more complex logic (e.g. check time, if time falls within a certain range, start google maps pointing to work address, always start Spotify) but it'd only work if you have Trigger installed.
I however am looking for a NFC project that works without requiring installing an extra app. Things that work on any Android device with latest OS are for example:
toggling Bluetooth
connect to WLAN with SSID and password
open an URL
...
I've seen it's possible to write an NFC tag to pair with a Bluetooth device. However when using a different phone, that does not have the NFC writer app installed, will the NFC tag still work? Example
My NFC tags are still shipping so I can't test. Also I prefer reading documentation and implementing according to docs over trial and error.
Newer Bluetooth speakers have NFC. I'm unsure if you can turn NFC-dumb devices into NFC-smart devices. (The NFC-smart devices may be telling the bluetooth speaker to go into pairing mode which is something you cannot do when you create a NFC tag.)
I've been trying to look up documentation what's supported by default but I have a hard time finding these ressources.
For now I want to focus my attention to Android only since I do not own Apple devices. I am aware what may work on Android may not work on Apple.
I'm looking for the API method calls documentation for Android that shows above mentioned bullets points being possible.
What is possible? What are the limitations?
The API for NFC is well documented. You will find that on the android developer site (Android developer documentation).
However, what is supposed to happen once you read a NFC tag is a different story. Your examples have nothing to do with NFC, even so they appear possible. This is what you have to cover with your app.
You are not after the API documentation on Android which is well documented at the low level but poorly documented as a System.
What you are after is the NFC Forum specification and what level of support that your particular version of Android natively supports these specification.
Unfortunately the NFC Forum specification are mostly a paid for resource can cover things like how to write an NDEF message for Bluetooth pairing, Wifi setup, etc.
Though some of these specification can be found hidden on the internet or you can pay to become an NFC Forum member.
You can get an idea of what Android OS natively supports by looking at the source code of the System App that handles this.
(mostly in ) https://android.googlesource.com/platform/packages/apps/Nfc/+/refs/heads/master/src/com/android/nfc/NfcDispatcher.java
But additional support for other message types can be added by any other App include apps installed by OEM vendors like Samsung, etc

Can you programmatically detect whether a device is a Google Edition Version?

Currently there are some hardware interactions with physical devices that a phone/tablet interacts with in our application. We target only specific devices for them. An example would be a hospital that is dedicated to using specific models that they will be using (based on a contract).
We can get the Build.MANUFACTURER and Build.MODEL, etc. to identify which particular model is being used; since this will change how the hardware interacts slightly with the device. This in not our exact case however. Ours is a little bit more open. Has anyone seen some sort of a pattern that is being used for differentiating between Google Play Edition versions of a device?
All that I have to compare with is an S4 which tags on a 'G' at the end of the GT-I9505 of the S4 model. I am unsure if this is truly a pattern or not since I have only one of them available to me and do not have a database to analyze of this info. Perhaps someone has come across this need or has picked up how to differentiate between devices at this level before.

How widely supported is the accelerometer in Android devices?

We're developing an Android app that relies on the accelerometer for certain features. I'm wondering how safe it is to rely on the existence of the accelerometer and not provide alternative UI options for devices that do not support it (e.g. a button). My observation is that most "smartphone" Androids out there support it. Am I correct?
It would be nice if someone can point me to some data or stats for all Android devices out there.
I've personally never seen an android device without an accelerometer. The internet seems to agree on that aswell:
Link 1
Link 2

Android: Does Tablets support telephony?

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.

Is possible to Install Android in other phone? Like the SH004 or other OEM Phones

I'm wondering if is possible to install/use Android with other phones? Will be nice to have it on such a piece of hardware like the new SH004.
Mobile phones are generally very hardware independent of each other and require a serious amount of hacking in order to do any sort of "moding".
I can barely find any information on the SH004, but I think it will have to be out for a few months before you will even start to hear people of moding it, yet alone installing another Operating system.
Your best bet is to find specialised forums such as CellPhoneHacks, (There are better around, but not sure if I should link to).
Android is actually designed to be portable, and to provide source code for most of the generic pieces. However, the possibility of running it on a consumer device intended for a different operating system/framework depends on three things:
1) The hardware must have sufficient capability - likely meaning it was originally designed to have comparable capabilities under whatever OS it shipped with.
2) Sufficient low-level documentation must be published or reverse engineered to adapt a Linux kernel, flash memory driver, user I/O drivers (touchscreen, etc), and anything communication related (wifi, mobile, etc) and optionally any extras (accelerometer, gps, etc)
3) It must be possible, either by design or by finding an exploit, to run arbitrary code on the device - ie, boot an image which has not been signed by an approved party such as the OEM.

Categories

Resources