I'm just getting started with Android Dev.
Which Android phones should I add as virtual devices to make sure that my apps will work for the majority of people?
The only articles I've found from google were written 2 years ago, and I think the market share must've changed quite a bit by now, hence the phones listed there might no longer be in use as much.
Specifically I'd like to know which screen dimensions + Ram/memory I should provide to the phones for testing.
if your question is about which Android versions you want to support, you should check this link.
So basically you can use eclair (2.1) has the minimum supported version.
I highly recommend that you target the last version (Jelly Bean at the moment). It is a pretty good practice and this way you won't have to update your app to adapt it when JB will become more popular..
For my tests, I usually have a virtual machine with eclair or gingerbread and my phone with Jelly Bean.
edit : one very important clarification, in your app manifest. You will have to declare the minimum android version you support with android:minSdkVersion="XXX". the tag android:targetSdkVersion="XXX" is not here to tell on what version you are focusing, but to tell to the system if you have thought about the last versions. so you should always target the last one (16 at the moment). If for example you target gingerbread (api level 9 I think), then the terminal will assume that you did not adjust to the disparition of the menu button and display one, EVEN IF you don't even use it !! It is a very poor user experience.
As for the screens size to support, This link is very helpful (and whenever you have a question about android development the official website should always be your first destination). I think that the question is not really here are the screen sizes, let's make a layout for each one of them, but the contrary : here is how I want to display my app on a standard size phone (around 4.2" inches I would say), at which point in terms of dp do I need another layout because mine is either too cramped or has too much whitespace ?
If you really want to know what sizes to consider, somewhere between 4 and 4.5 inches is where you will find most high end smartphones of 2012. You will maybe need another layout for 3.5" or smaller screens.
In the superior dimensions, I would focus on 7" (Nexus 7, kindle, galaxy tab 7) and 10".
Related
Hello fellow Android Devs!
My Question/Topic today is about the "Minimum SDK" we set for our Projects..
For years now, "API-15" (IceCreamSandwich/4.0.3) has been typical, covering 97.4% of users.
However, I've recently noticed now that "API-16" (JellyBean 4.1) has caught up, at 95.2%!
Over the past few years, the percentages were MUCH further apart, making API-15 the go-to.
SO, MY QUESTION IS:
Are there any advantages to setting API-16 as my Project's "Minimum SDK", instead of API-15?
For example, less need for certain support libs, or better compatability with anything, etc. etc.?
Basically, ANY reason at all why choosing API-16 as my "Minimum SDK" might benefit anything?
..Thoughts?
I've worked on apps with both 15 and 16 as the minSdkVersion. I would recommend a minApi of 16, particularly if you use SQLite.
Api 16 has:
SQLite 3.7.11. You now have setForeignKeyConstraintsEnabled for your SQLiteDatabase.
Up navigation. Api 16 supports android:parentActivityName in the manifest, so you don't also have to have metadata tags.
Font families in xml. For your password EditText, you can now set android:fontFamily=sans-serif, so it no longer defaults to monospace.
The drawback is that the Samsung Galaxy S2 runs on API 15, so if this is an important demographic for you, you'd be missing out on them if you use minApi 16. All of my new projects are minApi 16.
Android 4.1 (API 16) has Has offline voice recognition. Offline voice recognition enables you to perform voice actions, like dictating texts or using various voice commands, without an internet connection.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I bought a book and it suggested the use of the Android Studio Manager which I am now using. However when I try to utilize the emulator in this package it gets to the splash screen or a picture of a phone with android written on it and then stops.
I have left it running for up to an hour and a bit and it still doesn't get to a usable state although there is still activity taking place in the logcat file of the Android Device Monitor. This leads me to my first question, is longer than an hour an expected first load time for this particular emulator with my ballpark specs? It seems really excessive...
To clarify my AVD settings I am using an ARM cpu for API 23 with a 1080 x 1920 xxhdpi 4.3inch screen. I cannot use any emulators which require HAXM.exe as my processor does not support the VTx functionality. I am currently using host GPU setting rather than snapshot and have set the device RAM as 512MB in my AVD setup. So question 2 do these settings sound sort of sensible?
I do own an android device and am considering using it for my testing but am worried that I will spend forever bundling and installing apps on my phone if I try to use it as the basis for my learning. So question 3 is, is this the case or will the bundle time be quicker in the long run than waiting for emulation platforms?
Just to be clear I am at the hello world.apk stage of programming.
Any advice on speeding up the emulator so I can use it...
Unfortunately, for any kind of emulation (running Linux or Windows under VMWare, or emulating an Android device under the AVD), it helps to have lots of RAM, a fast 64-bit CPU ... and the VT extensions.
There are things you can do to speed up your emnulator, however:
1) smaller screen size
<= this is a biggie!!!
2) Set "use host GPU"= Y
... and, something I haven't tried, but looks interesting:
3) Run an Android image under QEMU:
How to speed up the Android Emulator by up to 400%
http://www.android-x86.org/documents/qemuhowto
With your configuration, as Gabe Sechan recommended, you should try using Genymotion instead of the built in emulator.
https://www.genymotion.com/
Link to their free personal use version: https://www.genymotion.com/#!/download
Thanks for the info all. Sounds like the general consensus is my best route is to use my phone for all debugging. I will try the other settings that have been suggested before I bin the emulator but in a lot of ways I think it will be more fun to see it all going on on my phone! Thanks all and I doubt you've seen the last if me!
That is a lot of questions, but to answer the general thrust:
Genymotion, like WINE, Is Not an Emulator! Neither is VMWare or VBox. These are virtualization technologies that may require VTx processor hardware support. This is exactly because they are NOT emulators, but co-located OS instances - its your machine that becomes virtualized into many machines, with separate IPs, etc. The OP has repeatedly stated VTx is not supported by his system (generally intended for servers).
The emulators are slow because they are just another process scheduled by your real OS. That is why they all share the same IP address - there is only one machine. They are good for layout tests with various screen resolutions. You could also try Eclipse, if Studio is giving problems. You can still download the latest SDKs with it. ADT is no longer supported, but is very stable.
For any other tests, I have found that deploying directly to a device is actually better (but monotonous - you might want to write an ant or other build script to do this).
Other than buying additional devices (and a rack, and usb hubs, and UPS, and a cooling system that sounds like turbines recycling), your best bet is to use the alpha and beta test launches, and cultivate relationships with a variety of device users. Depends on whether you want more friends, or a wicked cool ARM stack. Decisions ...
The worst, but most effective way is to just go ahead and publish early and often. Free QA, but your users will punish you for it with a hail of 1-star reviews. You could then just republish under a different package name to zap all reviews (also zaps download stats, effectively orphaning the old app - dark magic if it is also a paid app).
Google is launching a cloud testing lab (shared ARM stacks) which will run your app on the most popular real device/os combos simultaneously, and send back all the actual logs and real vidcaps of the screens in seconds. This a real answer to cross platform testing challenges like these, minus the turbine recycling noises, which they could easily add to the web UI.
I am still trying to figure out a solution for this. Ive created a multiple layout on my res folder namely: layout, layout-sw480dp, layout-sw600dp, layout-sw720dp. Now testing it to real device which is (Samsung galaxy (7 inches) and Alcatel T10(7 inches)) they both go to layout-sw600dp but samsung seems much bigger than alcatel. Most of 7 inches tablet works fine except Samsung. Ive read this link Screen sizes and found out that
The original Samsung Galaxy Tab is an interesting case. Physically it is a 1024x600 7” screen and thus classified as “large”. However the device configures its screen as hdpi, which means after applying the appropriate ⅔ scaling factor the actual space on the screen is 682dp x 400dp. This actually moves it out of the “large” bucket and into a “normal” screen size. The Tab actually reports that it is “large”; this was a mistake in the framework’s computation of the size for that device that we made. Today no devices should ship like this.
My Samsung galaxy is 3.2 so I am sure that it fits on my requirements.
Does someone know how to handle this kind of problem?Like can I create a new folder for Samsung Galaxy only?
Sorry for my english, it is not my native language.
I struggled with the above issue for sometime and found that thr was no alternative for this in xml.
You must handle this during run-time, if you only want it for this specific model then u can get the model make during runtime here and then handle the scenario.
I dont see anyway u can have a special folder for samsung, if you find out,please do let me know :)
I am a noob to Android (and Java). I have successfully setup Eclipse and the Android Virtual Device (AVD). I am guessing the AVD's Target is the version of Android to be emulated, but I want to make sure. I am trying to develop something for my Droid X2 phone.
As such...
Which AVD Target is the right one for a Droid X2?
Is there an online list someplace explaining each Target?
...I have Googled both unsuccessfully.
Thank you for the help.
According to motorolas website, the Droid X2 ships with Android 2.2 (api level 8).
I'm not sure if there are any updates rolled out yet, so consider this the lowest version you will get for this device.
So target 2.2. or lower.
But just a general advice: If you want to ship your app to other people, it's usually best to target the broadest audience. So I recommend going for 1.6 as a target, that will still run on your phone. You can start to raise the target version when you notice that you need a certain feature (can be easily done from the "project properties" dialog inside eclipse in 5 seconds). If you don't seem to need any higher api features, you are way more compatible to many more devices this way.
Edit: To the targets. See Android API levels. Clicking on a version takes you to the changelog. Theres info whats new. Also notice that anything below and equal 2.3.3 is a phone os at the moment. Anything equal or above 3.0 is a tablet os.
Hey, for an application I am writing I need to use the data which is given in Sensor.TYPE_ROTATION_VECTOR. The bad news are that I program, among others, to my G1 device, which runs Android 1.6, i.e. API Level 4, and not 9 as needed. Nevertheless, I am pretty positive that my phone does have a sort of gyroscope, which means it should be possible for me to get the exact orientation of the phone. So, the question is, how do I do it?
Thank you in advance.
I don't think that the G1 has a gyroscope - it just has the basic accelerometers. Here's an interesting post about how to program to use accelerometers when they are available and not crash when they aren't.
[Update]
If your phone has a gyroscope, you will require Android 2.3 (and above) on the phone to get access to it.