I am new to Android Development and would like to know which phone I should get to test my apps? Obviously, I would like the phone for which drivers for all devices are easily available and for which I would find the most amount of support discussions online - for when I run into problems.
I'd suggest using the latest Google Android device, currently that is the (Samsung) Galaxy Nexus, but rumors suggest it is to be updated very soon (?)
Main reason is that the Google phones allow you to see your own debug message on the console pretty easily, where as most other phones have so such junk debug messages on the console, that they swamp your own debug messages making it difficult to test & debug your own apps. You can filter debug messages but the console fills quickly (in Eclipse) anyway & then has to be reset.
If you can live without relying on debug messages through Eclipse then any good & recent phone will likely do, eg Samsung Galaxy S3, HTC One X, etc.
The Google phones get OS updates before other phones as well.
On Monday, October 1, 2012 5:54:28 AM UTC+10, Nilashis Dey wrote:
> I am new to Android Development and would like to know which phone I > should get to test my apps? Obviously, I would like the phone for which > drivers for all devices are easily available and for which I would find the > most amount of support discussions online - for when I run into problems.
Doesn't really matter. I find myself testing on 4 different devices in the emulator - corresponding to different screen sizes. The only time I load into a real device is just before a release, and that's just habit (see what it looks like on real screen) rather than a requirement. The fact is that you have to test on multiple devices, and just because you own a real device as well doesn't help much. The only time I have ever used a real device for something meaningful is to measure frame-rates in games; the emulator on my PC runs at about 1/5th the rate of my HTC Desire 1 Ghz phone for 2D graphics so occassionally its good to see how fast the game runs on real devices. Most apps aren't real-time, and this is a pretty minor use.
I would buy an Android phone/tablet if you need a phone or tablet for other reasons, and buy one for those other reasons. The fact is that a real device doesn't actually help you much in developing apps.
On Monday, October 1, 2012 5:54:28 AM UTC+10, Nilashis Dey wrote: > I am new to Android Development and would like to know which phone I > should get to test my apps? Obviously, I would like the phone for which > drivers for all devices are easily available and for which I would find the > most amount of support discussions online - for when I run into problems.
On Mon, Oct 1, 2012 at 4:09 PM, Peter Webb <r.peter.w...@gmail.com> wrote:
> Doesn't really matter. I find myself testing on 4 different devices in the
> emulator - corresponding to different screen sizes. The only time I load
> into a real device is just before a release, and that's just habit (see
> what it looks like on real screen) rather than a requirement. The fact is
> that you have to test on multiple devices, and just because you own a real
> device as well doesn't help much. The only time I have ever used a real
> device for something meaningful is to measure frame-rates in games; the
> emulator on my PC runs at about 1/5th the rate of my HTC Desire 1 Ghz phone
> for 2D graphics so occassionally its good to see how fast the game runs on
> real devices. Most apps aren't real-time, and this is a pretty minor use.
> I would buy an Android phone/tablet if you need a phone or tablet for
> other reasons, and buy one for those other reasons. The fact is that a real
> device doesn't actually help you much in developing apps.
> On Monday, October 1, 2012 5:54:28 AM UTC+10, Nilashis Dey wrote:
>> I am new to Android Development and would like to know which phone I
>> should get to test my apps? Obviously, I would like the phone for which
>> drivers for all devices are easily available and for which I would find the
>> most amount of support discussions online - for when I run into problems.
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
You dont even need a phone to test your apps. You can test using the eclipse sdk. However, it is nice to have a phone... doesnt matter which one... to see your apps working. That being said, if I were going to buy a new phone I would buy something with the latest system version, but be sure to develop your apps and release for older devices, like 2.3 which is still very popular.
On Sunday, September 30, 2012 3:54:28 PM UTC-4, Nilashis Dey wrote:
> I am new to Android Development and would like to know which phone I > should get to test my apps? Obviously, I would like the phone for which > drivers for all devices are easily available and for which I would find the > most amount of support discussions online - for when I run into problems.
On Sunday, September 30, 2012 2:54:28 PM UTC-5, Nilashis Dey wrote:
> I am new to Android Development and would like to know which phone I > should get to test my apps? Obviously, I would like the phone for which > drivers for all devices are easily available and for which I would find the > most amount of support discussions online - for when I run into problems.
If your needs aren’t satisfied by the emulator, as gjs suggested, I would look into purchasing any of the pure google devices. They have all the binaries and factory images available via Google's developer site.
On Monday, October 1, 2012 4:06:33 AM UTC-4, gjs wrote:
> Hi,
> I'd suggest using the latest Google Android device, currently that is the > (Samsung) Galaxy Nexus, but rumors suggest it is to be updated very soon (?)
> Main reason is that the Google phones allow you to see your own debug > message on the console pretty easily, where as most other phones have so > such junk debug messages on the console, that they swamp your own debug > messages making it difficult to test & debug your own apps. You can filter > debug messages but the console fills quickly (in Eclipse) anyway & then has > to be reset.
> If you can live without relying on debug messages through Eclipse then any > good & recent phone will likely do, eg Samsung Galaxy S3, HTC One X, etc.
> The Google phones get OS updates before other phones as well.
> Regards
> On Monday, October 1, 2012 5:54:28 AM UTC+10, Nilashis Dey wrote:
>> I am new to Android Development and would like to know which phone I >> should get to test my apps? Obviously, I would like the phone for which >> drivers for all devices are easily available and for which I would find the >> most amount of support discussions online - for when I run into problems.
> I'd suggest using the latest Google Android device, currently that is the > (Samsung) Galaxy Nexus, but rumors suggest it is to be updated very soon (?)
> Main reason is that the Google phones allow you to see your own debug > message on the console pretty easily, where as most other phones have so > such junk debug messages on the console, that they swamp your own debug > messages making it difficult to test & debug your own apps. You can filter > debug messages but the console fills quickly (in Eclipse) anyway & then has > to be reset.
I assume that by "debug messages" you mean the logcat contents. You can filter those by command-line quite readily also, for example into a text file, that you can examine at your leisure. You can also modify the buffer size to capture more data, or run the "adb logcat" command in the background redirecting to a file for an arbitrary amount of data.
> If you can live without relying on debug messages through Eclipse then any > good & recent phone will likely do, eg Samsung Galaxy S3, HTC One X, etc. > The Google phones get OS updates before other phones as well.
>> I am new to Android Development and would like to know which phone I >> should get to test my apps? Obviously, I would like the phone for which >> drivers for all devices are easily available and for which I would find the >> most amount of support discussions online - for when I run into problems.
Andrew Cesario wrote: > You dont even need a phone to test your apps. You can test using the > eclipse sdk. However, it is nice to have a phone... doesnt matter which > one... to see your apps working.
Actually, no. You can test using the Android SDK, for which there is an Eclipse plugin. Other ways to run the emulator and tests also exist.
> That being said, if I were going to buy a new phone I would buy something > with the latest system version, but be sure to develop your apps and > release for older devices, like 2.3 which is still very popular.
> Nilashis Dey wrote:
>> I am new to Android Development and would like to know which phone I >> should get to test my apps? Obviously, I would like the phone for which >> drivers for all devices are easily available and for which I would find the >> most amount of support discussions online - for when I run into problems.
A real device is useful for testing various hardware features - bluetooth, nfc, hd video recording, sensors - accelerometer, barometer, compass, gryo, magnetic, wifi direct etc etc
On Tuesday, October 2, 2012 6:22:44 AM UTC+10, Lew wrote:
> gjs wrote:
>> I'd suggest using the latest Google Android device, currently that is the >> (Samsung) Galaxy Nexus, but rumors suggest it is to be updated very soon (?)
>> Main reason is that the Google phones allow you to see your own debug >> message on the console pretty easily, where as most other phones have so >> such junk debug messages on the console, that they swamp your own debug >> messages making it difficult to test & debug your own apps. You can filter >> debug messages but the console fills quickly (in Eclipse) anyway & then has >> to be reset.
> I assume that by "debug messages" you mean the logcat contents. You can > filter those by command-line > quite readily also, for example into a text file, that you can examine at > your leisure. You can also modify > the buffer size to capture more data, or run the "adb logcat" command in > the background redirecting to a file > for an arbitrary amount of data.
>> If you can live without relying on debug messages through Eclipse then >> any good & recent phone will likely do, eg Samsung Galaxy S3, HTC One X, >> etc. >> The Google phones get OS updates before other phones as well.
> The world doesn't comprise Eclipse alone.
>> Nilashis Dey wrote:
>>> I am new to Android Development and would like to know which phone I >>> should get to test my apps? Obviously, I would like the phone for which >>> drivers for all devices are easily available and for which I would find the >>> most amount of support discussions online - for when I run into problems.
On Tuesday, October 2, 2012 5:40:32 PM UTC-7, gjs wrote:
> Hi,
> >The world doesn't comprise Eclipse alone.
> Wow really [sic]! Thanks for letting us all know...
> A real device is useful for testing various hardware features - bluetooth > [sic], nfc [sic], hd [sic] > video recording, sensors - accelerometer, barometer, compass, gryo [sic], > magnetic, wifi direct etc etc
Indeed, yes, a real device is useful, and like an emulator, can be tested via command-line or Eclipse means.
You didn't answer my assumption about what you meant by "debug messages", but if you meant logcat output, that's the same whether it's through Eclipse or not.
Wow, really.
So what is the deal about not "relying on debug messages through Eclipse"?
If you didn't mean logcat output, would you please tell us what you were referring to?
"debug messages" was to imply anything emitted by locat, System.out.. , System.err.. , printStackTrace from Exception etc
And yes it's the same whether through Eclipse or otherwise, I suggested it can be painful when debugging in Eclipse with some real (non Google sponsored) devices that emit an excessive amount of these messages to find your own messages within that mess, filtering and redirecting to file and grep and changing buffer sizes and other time wasting steps aside. Some of the carrier sourced devices fill the default Eclipse buffer in a minute or so, particularly when GPS is on, the Google devices Galaxy S, Galaxy Nexus, Nexus 7 don't.
On Wednesday, October 3, 2012 11:17:42 AM UTC+10, Lew wrote:
> On Tuesday, October 2, 2012 5:40:32 PM UTC-7, gjs wrote:
>> Hi,
>> >The world doesn't comprise Eclipse alone.
>> Wow really [sic]! Thanks for letting us all know...
>> A real device is useful for testing various hardware features - bluetooth >> [sic], nfc [sic], hd [sic] >> video recording, sensors - accelerometer, barometer, compass, gryo >> [sic], magnetic, wifi direct etc etc
> Indeed, yes, a real device is useful, and like an emulator, can be tested > via command-line or > Eclipse means.
> You didn't answer my assumption about what you meant by "debug messages", > but if you > meant logcat output, that's the same whether it's through Eclipse or not.
> Wow, really.
> So what is the deal about not "relying on debug messages through Eclipse"?
> If you didn't mean logcat output, would you please tell us what you were > referring to?
Yes, testing on real devices is important and useful for all the reasons you gave. But there are others. For one, it takes a ridiculously long time to launch the emulator. Hook up a real phone via USB instead, and it is ready in under 10 seconds. Another: the permissions are different on a real phone and the emulator. You automatically have root permissions on the emulator. Not so on the phone. This means that if you want to test the software in the environment the user will see (and you really should want this), you get a much closer match by using a real phone.
So summarizing briefly, yes, you can do a lot of useful testing on an emulator, and it is a cheap and easy way to test on various screen sizes. But before you release your product to the market, it must be tested on a real phone, and should be tested on as many as possible.
On Tuesday, October 2, 2012 5:40:32 PM UTC-7, gjs wrote:
> Hi,
> >The world doesn't comprise Eclipse alone.
> Wow really! Thanks for letting us all know...
> A real device is useful for testing various hardware features - bluetooth, > nfc, hd video recording, sensors - accelerometer, barometer, compass, gryo, > magnetic, wifi direct etc etc
> Regards
> On Tuesday, October 2, 2012 6:22:44 AM UTC+10, Lew wrote:
>> gjs wrote:
>>> I'd suggest using the latest Google Android device, currently that is >>> the (Samsung) Galaxy Nexus, but rumors suggest it is to be updated very >>> soon (?)
>>> Main reason is that the Google phones allow you to see your own debug >>> message on the console pretty easily, where as most other phones have so >>> such junk debug messages on the console, that they swamp your own debug >>> messages making it difficult to test & debug your own apps. You can filter >>> debug messages but the console fills quickly (in Eclipse) anyway & then has >>> to be reset.
>> I assume that by "debug messages" you mean the logcat contents. You can >> filter those by command-line >> quite readily also, for example into a text file, that you can examine at >> your leisure. You can also modify >> the buffer size to capture more data, or run the "adb logcat" command in >> the background redirecting to a file >> for an arbitrary amount of data.
>>> If you can live without relying on debug messages through Eclipse then >>> any good & recent phone will likely do, eg Samsung Galaxy S3, HTC One X, >>> etc. >>> The Google phones get OS updates before other phones as well.
>> The world doesn't comprise Eclipse alone.
>>> Nilashis Dey wrote:
>>>> I am new to Android Development and would like to know which phone I >>>> should get to test my apps? Obviously, I would like the phone for which >>>> drivers for all devices are easily available and for which I would find the >>>> most amount of support discussions online - for when I run into problems.
On Wednesday, October 3, 2012 2:36:34 AM UTC-7, gjs wrote:
> Hi,
> "debug messages" was to imply anything emitted by locat, System.out.. , > System.err.. , printStackTrace from Exception etc
> And yes it's the same whether through Eclipse or otherwise, I suggested it > can be painful when debugging in Eclipse with some real (non Google > sponsored) devices that emit an excessive amount of these messages to find > your own messages within that mess, filtering and redirecting to file and > grep and changing buffer sizes and other time wasting [sic] steps aside. > Some of the carrier sourced devices fill the default Eclipse buffer in a > minute or so, particularly when GPS is on, the Google devices Galaxy S, > Galaxy Nexus, Nexus 7 don't.
As you say, the volume of output can be excessive, but if so, it's the same excess as in command line.
I don't believe the steps to filter output and adjust buffer sizes can be considered time wasting. Time is wasted if it produces less value than it costs. These steps produce more value than they cost.
While I normally use only command line myself, I find the Eclipse logcat window to be very flexible. It has all sorts of convenient tools to help you filter your messages, so if anything folks would find it easier to use than command line, contrary to your conclusions. It lets you dynamically filter on debug level, process id (pid), regexes, app, tag or specific text. AFAICT it's infinite, so buffer size is a non-issue, and it has buttons to save the output and manage your filters.
YMMV, but I don't recommend scaring people off the Eclipse logcat window.
On Sunday, September 30, 2012 3:54:28 PM UTC-4, Nilashis Dey wrote:
> I am new to Android Development and would like to know which phone I > should get to test my apps? Obviously, I would like the phone for which > drivers for all devices are easily available and for which I would find the > most amount of support discussions online - for when I run into problems.
Galaxy Nexus here. Why did nobody mention the app 'Adb Wireless'? It's so comfy not to have to attach the phone to your laptop, especially if you have to move around (your phone or even yourself with it). So another plus for having a device in addition to a set of emulators.
Yes, official Google devices are great, but it helps to have some low-end
ones for performance testing, and maybe a device of a popular brand that
may have its own bugs for compatibility testing.
So a highly compatible, high performance device is a double-edged sword.
I'm also finding myself using the x86 emulator images more and more to
speed up my compile/debug cycles. If only GPU acceleration worked on my
system again... :)
> Why did nobody mention the app 'Adb Wireless'? It's so comfy not to have
> to attach the phone to your laptop, especially if you have to move around
> (your phone or even yourself with it). So another plus for having a device
> in addition to a set of emulators.
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
On Thursday, October 4, 2012 8:21:00 AM UTC+10, Anton Kaiser wrote:
> Galaxy Nexus here. > Why did nobody mention the app 'Adb Wireless'? It's so comfy not to have > to attach the phone to your laptop, especially if you have to move around > (your phone or even yourself with it). So another plus for having a device > in addition to a set of emulators.
I also think some emulator may work for most case. I have a Galaxy Nexus
phone for testing the release version and also send it to my friends who
have a Android phone.
On 1 October 2012 16:09, Peter Webb <r.peter.w...@gmail.com> wrote:
> Doesn't really matter. I find myself testing on 4 different devices in the
> emulator - corresponding to different screen sizes.
I have a question: what's the config for the 4 different emulator? I think
the OS may include 4.1 and 2.3, but how about the screen size?
It is true, but misleading that "the emulator may work for most cases". Unless you are doing a very simple app, you should not even think of uploading it to the market until you have tested it on a real phone, preferably unrooted, since that is what most users will use. It is imperative if you are using OpenGL, the video, camera or sensors.
This is because there really are different bugs in each of these areas not only on different phones, but even different software releases for each phone. This is the infamous "fragmentation" Google loves to pretend does not exist. But it is real, and that keeps companies like DeviceAnywhere in business, since they can test your software on a staggering variety of phones.
On Tuesday, October 2, 2012 8:12:16 PM UTC-7, newkedison wrote:
> I also think some emulator may work for most case. I have a Galaxy Nexus > phone for testing the release version and also send it to my friends who > have a Android phone.
> On 1 October 2012 16:09, Peter Webb <r.pete...@gmail.com <javascript:>>wrote:
>> Doesn't really matter. I find myself testing on 4 different devices in >> the emulator - corresponding to different screen sizes.
> I have a question: what's the config for the 4 different emulator? I think > the OS may include 4.1 and 2.3, but how about the screen size?
Everything you cay about command line vs. Eclipse window could be true yet there would still be one overwhelming advantage for the command line: the Eclipse UI and documentation for how to do all this filtering is limited and put in odd places; it is much easier to find out how to use command-line redirection and grep on command-line output, and those are both well documented. The documentation is easy to find, too.
Also, when the Eclipse window simply fails to display the logcat output, I can never figure out why (except for one case: when 'Device' got mysteriously de-selected, which should never happen but does happen). When the command-line fails to display it, I can easily figure out why.
On Wednesday, October 3, 2012 10:57:10 AM UTC-7, Lew wrote:
> On Wednesday, October 3, 2012 2:36:34 AM UTC-7, gjs wrote:
>> Hi,
>> "debug messages" was to imply anything emitted by locat, System.out.. , >> System.err.. , printStackTrace from Exception etc
>> And yes it's the same whether through Eclipse or otherwise, I suggested >> it can be painful when debugging in Eclipse with some real (non Google >> sponsored) devices that emit an excessive amount of these messages to find >> your own messages within that mess, filtering and redirecting to file and >> grep and changing buffer sizes and other time wasting [sic] steps aside. >> Some of the carrier sourced devices fill the default Eclipse buffer in a >> minute or so, particularly when GPS is on, the Google devices Galaxy S, >> Galaxy Nexus, Nexus 7 don't.
> As you say, the volume of output can be excessive, but if so, it's the > same excess as in command line.
> I don't believe the steps to filter output and adjust buffer sizes can be > considered time wasting. Time > is wasted if it produces less value than it costs. These steps produce > more value than they cost.
> While I normally use only command line myself, I find the Eclipse logcat > window to be very flexible. It has all > sorts of convenient tools to help you filter your messages, so if anything > folks would find it easier to use > than command line, contrary to your conclusions. It lets you dynamically > filter on debug level, process id (pid), > regexes, app, tag or specific text. AFAICT it's infinite, so buffer size > is a non-issue, and it has buttons > to save the output and manage your filters.
> YMMV, but I don't recommend scaring people off the Eclipse logcat window.
