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
Related
I am very unhappy with my Fossil Q hybrid watch (no screen, tracks activity & sleep and button functions) but honestly it looks good. The app keeps crashing though. I would like to make my own Android app to extract all kinds of data (for future analysis). Before investing a lot of time, I tried to do some research on how to access the watch. It operates obviously on BLE. But all the documentation is either about Wear OS or actual smartwatches with more advanced functionality. Search engines fail to distinguish between what I am looking for and most popular results.
I was wondering, if there are any known communication protocols between apps and smartwatches, where I can start experimenting?
BTW, HCI snoop log reports all traffic but it doesn't look like anything to me. But I can also try to hack it (if it is not encrypted...).
I remember that I have found once a info on dev site regarding the heart rate tracking but I cant find it.
Anyway I have found one thing that might help you:
https://developers.google.com/fit/android/ble-sensors
Unfortunately this is "fit" reference site, which data might be obsolete,
afaik the regular updates might come to API reference:
https://developers.google.com/android/reference/com/google/android/gms/fitness/SensorsApi
You can start by reading code and documentation of the GadgetBridge project: https://codeberg.org/Freeyourgadget/Gadgetbridge/
They support some of the "Q Hybrid" watches to some extent
Is it possible to retrieve raw ECG signals programmatically from QardioCore via bluetooth?
I only have an Android device, and as the Android Qardio app doesn't work for QardioCore, I wanted to know if anyone already tried to write an own app for usage with Android, and if it worked?
The manufacturer wrote me in an email:
Qardio Core will be compatible with iOS only and we are focused on providing
a smooth experience on Apple devices that use iOS 10.0 or later.
[...] there are no immediate plans to bring QardioCore to the Android
platform [...]
This apparently means that there are no SDKs as well.
I have also emailed the manufacturer and got a similar answer:
[...]
Qardio Core will only be compatible with iOS for the foreseeable
future. We strive to provide the best experience and have not been
able to guarantee flawless operation on the multitude of Android
devices.
An SDK is also not available at this time.
[...]
I am trying to write an android application that uses several of the android apis(like policy manager, package manager, wifi apis etc).
The concern i have is, android being open, manufacturers/carriers are free to take any specific version of android as their start point and customize the same and ship it with the device.
Note:Please excuse me if this post is in anyway a repeat of earlier posts on the same/similar topic. In such a case, appreciate anyone sharing the earlier post.
Few things that bother me are:
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
how do i ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know these are some naive questions for many of you who may have been on android for a while, but any pointers in this regard would be of immense help.
Any other information in general w.r.t cross version, cross device incompatibilities and strategies to deal with them would be very helpful.
Thanks a lot in advance.
Regards,
Deepak
Your concerns (and many other developers) are addressed by: http://source.android.com/compatibility/index.html
But this still does not guarantee that manufacturer will not change API and break your application.
The common approach is to initially target subset of devices that make up large percentage of market and then implement workaround for other devices (if necessary). Sample info about device market penetration can be found at:
http://opensignalmaps.com/reports/fragmentation.php?
Kind regards,
Bo
First off, I don't believe you should need to worry about this. Only after you have thousands of users will you end up needing to face the more complex issues caused by the great number of manufacturers offering Android devices. This should not discourage you from developing for Android.
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
No. But it would certainly work against them if they remove important APIs from the system. The core exists as a whole, though there really isn't anything preventing them from removing or disabling chunks as they wish. For example, AT&T had disabled the ability to sideload apps on Android devices some time ago (but I don't think they still do that). An example of a device with reduced functionality: Amazon Kindle Fire. It doesn't at all look like Android in the majority of its interfaces (except within third-party apps) and it doesn't offer the complete API set. Even with those dramatic changes, Android app developers still have great success building and selling apps that run well on the Kindle Fire.
Even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
That's the idea, but there isn't anything in place to forbid them from breaking things. Nor is there anything that will keep them from introducing bugs accidentally.
How do I ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know that some manufacturers will offer an emulator for their devices/configurations to help test against their systems. For example, Motorola offers MOTODEV Studio for this purpose.
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.
We want to place a device in a store that operates as sort of a kiosk device. As in customers walk up to it and start interacting with our custom app. The app could be developed for Android or the iPad, so I'm trying to decide which one to use and would like comments on the following ideas:
Is it possible for Android or iOS to access services over the USB port? This would enable us to disable the network.
Is one particularly better for 24 hour always on?
I like the iPad as I think its supply will be more constant as we move forward and need to replace devices due to ones gone bad. Also, our app will probably work on future generations of the iPad. With Android, I'm not sure there will be that sort of consistency from the tablet vendors.
Kiosk mode? I think with the iPad by putting it in a kiosk case that removes access to the home button and turning on the restrictions we'll get what we want. What about Android? I'd rather not have to get into rooting devices and replacing their firmware.
Remote control? Any way to remotely control iOS or Android in a standard means? Our app will be a client to a master server which will obviously be able to control the app somewhat (when used purely as a display device to a customer, controlled from behind the counter).
My feeling is that neither Android tablets or the iPad is best suited for this. Are there other options?
I will try to answer your points, but know that I am probably biased towards Android, because that is where my experience lies.
With Android 3.1+, at least with the Xoom, you have full USB host capabilities. Things like USB flash/hard drives, keyboards, mice, even digital cameras, all work. If you need custom interop with a USB device, you could go as far as to write a driver for it.
24 hour always on is not good for any device with a battery, but neither is better in this situation.
While android apps are forward-compatible, bad programming practices and/or deviations from "vanilla" Android software and hardware CAN break forward compatibility. That being said, if you grab a Google Experience device like the Xoom, you won't meet as many surprises.
In Android 3.0, the navigation bar is built-in at a low level, and it is not possible for apps to remove it. Therefore, it is trivial for anyone to break a "software nanny."
I know that it is possible to control android devices remotely, but without knowing your specific needs, I can't really offer more information than that.
Good luck!
iPad NOOO believe me I am a convert to Apple for my home and business but when we went to launch kiosk the iPad FAILED Big Time.. Here are a couple of little (Big) issues we ran into.
If the device reboots you cannot auto launch you iPad app since Apple does not allow that.
There is a serious memory leak in the iPads browser. We were running javascript / CSS3 and it cratered intermittently. I literally spent 2 hours "today" on the phone with Apple getting the MAJOR run around. I finally said let me speak to an Enterprise Sales Manager as my project could mean thousands of iPads and I got NO WHERE. One Apple employee even told me they don't have enterprise sales managers.
If those weren't enough even though we are just in the proof of concept phase, we are already getting request for other options. These other options are going to require access to the OS which Apple yea right. We are moving to Android immediately.
Sorry Apple I love you but you loose here.
If your using an Ipad you should consider if it can support the power for the USB thing. Watch this Using Powered USB Port
Your idea about putting the tablet behind another piece of glass/plastic is neat. To then deal with remote controlling, you might consider doing some Bluetooth programming.
My mobile development has been primarily with iOS, so I am biased toward that SDK. I will mention that the data/sync/charge port for iOS has (I believe) never changed. Your Gen 1 iPhone sync cord works on your iPhone 4... and your iPad or iPad 2. So, in terms of third party hardware, you may see more consistency with Apple.
I haven't found a good answer regarding whether it is easier to do Bluetooth programming for iOS or Android, but I think to stay cost-effective, you might see which one is more open to third-party devices. Here is an SO post/answer about iOS and third-party Bluetooth devices; I've not found anything on Android regarding third-party Bluetooth remotes, but considering a lot of hardware running Android is third-party, your chances from a naive perspective seem pretty good. Here's the Android Bluetooth API.
Buying an iOS or Android handheld to remote control an iOS or Android tablet does seem a bit steep, but then again, maybe not. Cost also depends on your ratio of remotes to tablets. 1:1? 1:N? N:1? N:M?
The lowest end iPod goes for $229 as of May 20, 2011. Android does have more variety in terms of hardware. You may be able to get a cheap Android phone with no service plan to act as a Bluetooth remote for an Android tab.
I have provided a solution for the kiosk mode using iPad here Lock-down iPhone/iPod/iPad so it can only run one app
I am afraid that I don't really know for Android if the same thing is possible.
To address the issue of crashing applications you can use an exception trampoline (see discussion here https://blog.compeople.eu/apps/?p=275) to catch the crash and reboot your app.
If the entire device is restarted however then other apps that are on the device can be started and will subsequently be locked in.
To answer your other points:
You can use a configuration profile to control network access. Force it to use a VPN or Proxy that only allows your custom app with embedded credentials to use. That way other network access can be prevented.
Your concern over future compatibility is spot on. The Android marketplace is so fragmented then maintaining a fleet is difficult.
If you have an app that is behaving as a server and is locked in then remote control is possible.
We manufacture tablet kiosks that support both android and iPad devices. In fact we are the only iPad kiosk that has achieved apple approval.
Generally speaking i think you will have an easier time with an iPad as the software and hardware will remain more consistent over time. Which is important if you have to change out a fault unit or deploy more kiosks 6 months or year from now when the original device is no longer manufactured.