I want to know if it is possible to make an android application that features up to 6 touches simultaneously with the multi-touch option (not just two). Please can u help me to find some relevant literature. I've found some answers here on stackoverflow, but i am afraid that that's not enough.
I would appreciate every help. Thank you all in advance.
Devices that support "jazzhands" will handle up to 10 simultaneous touches. Your app can require jazzhands support via the following manifest element:
<uses-feature android:name="android.hardware.touchscreen.multitouch.jazzhand" />
Not all devices will support this -- for example, the Kindle Fire only supports two simultaneous touches IIRC.
There is no software difference between 2 or 6 touches (except for the permission), it is hardware related and if you can't use more of 2 fingers then you should try on another device.
Anyway, if you want good multitouch litterature, have a look here:
Making sense of multitouch (android-developers.blogspot.fr)
Related
I don't know the answer to the question posted at https://code.google.com/p/android/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&groupby=&sort=&id=155879.
How do i sort it out please as I was kindly asked to refer this and other questions here?
For one, your emulator is using a Nexus 5 layout, and your preview is using a nexus 4. This is causing the difference
For two, please don't link to external sites with your question, but posting it directly on SO it ensures that others who come in the future will be able to see the question (what happens if the external site goes down, or changes it's link structure)
For three, please make your layout flexible to different screen sizes as you will not be able to control what devices your users will be running your app on. (unless you are only using this app in a controlled environment, and not releasing it to the public)
I am currently working with Android Sensor API and accelerometer data.
Though the internal components should support high acceleration (even +-16g), I tried some recent smartphone and found that the maximum range of exposed data is usually +-2g (e.g. Nexus 5) and sometimes +-4g (e.g. Nexus 4).
Is there any way to set the full scale of the sensor? (I didn't manage to find a public API for this)
Alternatively, is there any flagship smartphone that support higher range from stock? (e.g. +-8g, +-16g).
I'm facing the same problem as yours.
DISCLAIMER: I just discovered what I'm writing, so I haven't tested it at all... but I think it's in the right direction.
Checking what range is functional is quite simple: Sensor.getMaximumRange()
http://developer.android.com/reference/android/hardware/Sensor.html#getMaximumRange%28%29
Now, as you know, setting the appropriate value is a much more involved thing. I believe it has to do with Android's so-called "Hardware Abstraction Layer"
https://source.android.com/devices/reference/files.html
I've found this document by STMicroelectronics, who are the manufacturers of the accelerometers embedded in Samsung Galaxy SIII and S4 http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00063297.pdf
If I'm getting it right, you need to #define ACCEL_MAX_RANGE in configuration.h (page 5 of the document) as 8 or 16*GRAVITY_EARTH. There are plenty of instructions following, which I'm still trying to understand, but I think one would need to root the smartphone and compile Android from its source.
Hope this helps! If you manage to solve it, please let me know so that we can help each other.
Regards
Sorry that this is an answer and not a comment, but I don't have the rep yet. I've got a Moto X 2nd Gen, and the accelerometer has a 16-g range(+/-).
Here's the datasheet for the sensor. It's an MPU6515 from Invensense.
As ignzz stated in his/her initial post, it does not seem to be a problem from the sensor hardware, which in his/her case can also record +/-16g in principle. I believe it has to do with the settings of the operating system.
However, I haven't had time to give a try to what I described above. Has someone tried?
I am using systrace to dig into the performance issue in my app, I am wondering if there's a way to add a tag / marker when certain event happens in the systrace result? The specific event I am looking for is input event, but it's hard to tell from systrace which input event is which. I am on Android 4.2.2
Cheers,
Johnny
You can, using android.os.Trace, but the feature wasn't added until Android 4.3 (API 18). You can find an example here.
I'm spending considerable time in making my UI to work with keyboard input only. But in the end I'm not sure whether I can rely on the assumption that Android devices all have touch screens.
Is there a way to determine if an Android device has a touch screen?
You should research the existing devices and read the Android Compatibility Definition Document (CDD) and decide for yourself.
I have spent some considerable time trying to figure out this problem for myself. The posters above are correct that Android already powers some non-touch devices and will power Google TV in the near future, but as it currently stands, the CDD specifically requires that ALL Android devices MUST have a touchscreen.
Basically, the Android Compatibility program was created to hedge against the sort of fragmentation issues you're worrying about now. It lists a bunch of requirements, and if a device does not meet those requirements, it does not get access to Android Market. These requirements include a touchscreen, wireless communication, bluetooth, a camera, and much more.
If you research those tablets and netbooks, you will find that not a single one carries the Android Market. Augen recently tried to pull a fast one with their new GENTOUCH 78 tablet, but had to rescind their claims that the tablet would carry Android Market after being shot down by the Android Compatibility Team.
So, if you are only distributing your app through Android Market, you have nothing to worry about until Google changes the CDD. But if you'd like to offer your app on other app stores or as a direct download, then you'll have to worry about your key mode navigation issues.
If it's any consolation, I have found that many, many apps have the exact same problem; they are impossible to use without a touchscreen. Many of them also have serious issues with focus and the soft keyboard. Sometimes the keyboard stays up when it should be hidden. Sometimes you can't get the keyboard to pop up no matter how many times you click on an EditText. IMO, the Android framework does not handle these things all that well.
Given all that, it will certainly be interesting to see how Google TV fits into all this. Will they update the CDD to be compatible with their set-top boxes? Will they use a different SDK and CDD for Google TV implementations? Will they ignore the Compatibility Program altogether when it comes to Google TV? Your guess is as good as mine.
Update:
It seems that someone at Google has finally come forward and admitted that Android is not ready to run on a tablet:
http://phandroid.com/2010/09/10/shocker-google-says-android-not-meant-for-tablets-in-its-current-state/
To me, this says that Google was not prepared for the accelerated adoption of the Android OS and has not adequately roadmapped the future of the platform. Supporting screens larger than 480x800 is barely possible, and Samsung was only able to do it by working closely with Google on the Galaxy Tab. So I'm not so sure we need to worry about non-touchscreen devices in the near future. They'll be here eventually, I'm sure, but when they do arrive we may see a separate app market just for those, or some altered filtering scheme on the existing market, a new CDD, who knows.
To me, this says that Google is still playing it by ear, and we'll just have to do the same.
All the phones so far have touch screens, but there is no promise that they must.
However there are lots of netbooks, notebooks, and soon to be TVs that have no touch screen.
However these devices have mice. From what I've seen, the mouse input gets pumped through the touch system so MouseDown is ACTION_DOWN, etc... (Don't know about right click though)
Are you targetting just the phones? Android is appearing on many devices including TV's I've no idea if new libs will be released to isolate parts of the devices from each other, but if you want a broader audience I'd suggest keeping the keyboard input available if you are
Google TV (GTV) is the most popular Android notouch device (as of the time this answer is composed). However, there are several devices that will call for notouch renderings if you have "notouch" resources (e.g. a directory like res/layout-notouch/ )
To accommodate notouch devices, made sure that focus will cause a visual selection indicator, and (for GTV) that keystroke listeners are in place for the directional-pad center button. Using default widgets and themes will often accomplish much of this automatically. If you make your own buttons, you need background 9-patches for focused and focused+pressed.
Running on a GTV is a good test environment to make sure that notouch works well, and GTV has an emulator now, though it runs only on Linux/x86.
Recently myself and a small group of friends became interested in developing a game for a mobile platform. Originally we considered the iPhone but none of us use macs, so we decided Android would be a more realistic platform to use. Before we get started, I was hoping that I might find some answers to a couple questions so we don't waste our time if this project isn't feasible. Any help is appreciated!
I can't seem to find out how many programming languages Android supports. Java is obvious, but what about C+? It seems that Android supports C and C++ through Eclipse, but is that it? (I'm not the programmer for the project which is why I'm asking this. He's comfortable in C+).
Our game involves the use of two digital analog sticks (it's not a twin-stick shooter but it's a similar concept). It would seem that most Droid devices unfortunately don't use multi-touch though... Are there many devices out there right now which support this functionality and I'm just not seeing them, or should we possibly consider the development of a different game that would only use a single input?
Assuming there's no snags following those first two questions, what would you consider the best screen resolution to develop in? It seems like there are a variety of resolutions out there right now and we can't decide which is the best to use.
Again, any answers are appreciated!
You will have to use at least some Java, though you can call C++ with the newly released NDK.
To my knowledge at least the Droid and Nexus One support multitouch. Not sure about the newer ones.
I would develop for multiple screen sizes.
Chris Pruett did two very good presentations on writing real time games for android you may want to look into, they were a huge help for me.He also lightly touches on the NDK in the second one, linked below. I can only post one link since I'm a new member, but a google search for "writing real-time games for android" should turn it up.
http://bit.ly/checYY
1) Java is the language of the SDK. The majority of apps are and should be written in Java. The only reason for the NDK is for apps previously written in C++ that are to be ported to Android. There are downsides - it only supports compiling to 2 different CPUs (one is the Nexus one's CPU, can't remember what the other is). So if you do use C/C++ in the NDK, you are seriously limiting the number of devices you can ship to.
2) If you want to use dual analog sticks, why not display the sticks in the corners of the screen and allow the user to place their thumbs on them? You don't need hardware support.
3) Android SDK supports multiple screen resolutions so you don't necessarily need to worry about it immediately. I would aim for WVGA to start with (800x480 - Nexus One / HTC Desire).
Your first question has been answered by others already. The SDK is based on Dalvik, you're going to have to speak Java to the Android framework to do things like set up your activity, handle events, etc. You can call into a native code module built with the NDK for other things.
The multitouch situation on Android is dependent on hardware. Android >= 2.0 supports it in the framework, and you can use the PackageManager to query for what kind of multitouch functionality the device supports. The two you care about are FEATURE_TOUCHSCREEN_MULTITOUCH and FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT. Some screens that only offer FEATURE_TOUCHSCREEN_MULTITOUCH have problems distinguishing precise movement when both fingers are along or near the same X or Y coordinate. This is fine for things like zoom gestures, but you might have problems doing dual-analog style controls on a device without FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT.
Plan on supporting multiple resolutions. If you provide low and high resolution assets the resource system can select the appropriate ones for you automatically at runtime. More details on this here. You will still need to deal with different resolutions that do not necessarily share an aspect ratio. For example, the Droid is 480x854 while the Nexus One is 480x800.