Is there any way to simulate the behaviour of a cellular mobile network (GSM/UMTS) in the Eclipse Android emulator?
More specifically: I want to develop an app to show information about the network, such as coverage level, parameters of neighbouring cells etc, as provided by the TelephonyManager and other related classes. I would like to do as much debugging as possible with the emulator, before testing in an actual phone.
For that I would need the emulated phone to "see" a functioning cellular network, with its protocols and parameters. Is that possible?
Emulator doesn't give you the option of setting that things. I have developed a toy app for showing network parameters and the only way I found was using a real phone.
By the way, not all phones implement all methods of Android's API, so you will find that some parameters will not be shown. And also many parameters are not available from API and you will need to get them throw AT commands (you will need a rooted device)
Note: I realize this question is two years old, but since this question received a slight edit from its original author 5 minutes ago and so got bumped back up to the front of the site, I am assuming that he may still be looking for an answer.
Yes, AT&T provides such a free tool to simulate and analyze different network conditions to a certain extent. And it can be used in conjunction with Eclipse ADT, Android Studio, or something else entirely. So it's not tied to any particular IDE.
http://developer.att.com/application-resource-optimizer
That being said, I have no idea if it will give you any cell tower related meta data.
Related
I'm stuck at home with a rather bad webcam. I was considering upgrading, but then it struck me: phones these days have really good cameras embedded in them. So why not use it as a webcam?
However, as I was researching this further I was really disappointed with the available apps for this. As far as I was able to find, we have Android apps that work roughly as follows:
Present phone camera as a network attached camera. Then you can use local software to use that feed as a webcam. See e.g., IP Webcam. This may be sufficient, but it's a complicated setup, and network latency makes this far from ideal.
The Android app sends the camera feed to an custom host application that in turn creates a virtual web camera. See e.g., DroidCam. This mostly solves the latency problem, but it is still rather complicated, and requiring us to install a specific third party application is troublesome in regard to user privacy. Especially since the applications are closed source.
So, I took the engineering approach and tried to see if it was even possible to improve the situation. As far as I was able to find, Android supports being used as a custom USB accessory. And looking over the USB video class documentation, it strikes me that it should be possible to create an Android app that presents the phone as a generic UVC webcam, such that we do not have to resort to tricks such as the ones above.
Ideally, I would have liked Android to add another USB device option ("Use USB connection as webcam") in addition to debug mode, file-transfer, etc. This seems quite unlikely to happen in the short term however.
So, my question is this: Does an application that does the above already exist? My searching thus far haven't yielded any results, but I might be missing something as googling for this turned out a bit harder than I expected.
Alternatively, am I wrong in my assumption above, such that there is some fundamental issue why an Android application cannot be made to work in that way?
There does not seem to be any complete app yet as of 2020-10, but the parts are mostly there:
https://github.com/tejado/android-usb-gadget has code to switch the Android device into gadget mode (but no UVC yet)
https://git.ideasonboard.org/uvc-gadget.git feeds v4l2 into the uvc gadget output
Sources:
http://www.davidhunt.ie/raspberry-pi-zero-with-pi-camera-as-usb-webcam/
https://www.raspberrypi.org/forums/viewtopic.php?t=148361
https://www.reddit.com/r/androiddev/comments/iabc2o/can_i_use_my_android_as_wired_camera_ie_as_a/g1nrijl/
It appears Google has started to take notice on this issue and are currently working on a "DeviceAsWebcam" service, which is exactly the solution to this problem, as seen in the Android review below:
https://android-review.googlesource.com/c/platform/system/sepolicy/+/2410788
Naturally though, this is a Android 14 feature, so it will like take a while before this is usable on a lot of devices. Hopefully, someone is able to backport this feature to older versions of Android.
If android / the version of Android that comes on your target phone provides / permits use of the USB gadget driver, then libguvc,
https://developer.ridgerun.com/wiki/index.php?title=USB_Video_Class_Gadget_Library_-_libguvc
can be used to "make an application appear as a USB webcam".
Potentially relevant to get you started would be https://stackoverflow.com/search?q=Android+USB+gadget (other SO references to the use of the USB gadget driver on Android).
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 9 years ago.
Improve this question
I'm going to be writing my Android app soon, and thinking about buying a solid android device to develop on and play with. My question is for you guys, assuming you wanted to develop and test your app on an Adroid device, what would you recommend?
Samsung Galaxy looks promising, but I know choosing a good dev phone is one of those things you definitely need to choose wisely on. The Android device landscape seems to be broadening every day, so it'd be good to hear about the latest devices for developing. Perhaps I could just get a cheap clunker and it won't make a difference?
I'm sort of a nerd, so if the device is pricey, but has some cool features that others don't, then I'd still consider it. However, I don't want to waste too much money on features that I may not need (or that may distract me ;)), like HD video, although it looks like a lot of phones have HD support anyways.
Tablets seem a bit much, but I'm still open to it... if you're loving your Android tablet for developing, let me know about it. I could see some benefits like being sure my app will run on Android tablets and different resolutions.
Any caveats I should be worried about? I have a buddy who was developing Android when it first came out and I remember him complaining that he could never update his device, since the updates were always restricted for some reason. Is that still the case?
If you can speak to any of these points, I'd be happy to hear them.
Also concerned about using the location based stuff, like gps, will I need a contract?
I'll be developing on my Macbook Air OSX, if you have any additional input as far as devices go, and using a Mac, that would be great too. Thanks!
You should develop against the Android 4 platform, but during the course of development, you will figure out which APIs you are using. The level of APIs you are using determines which minimal OS you will support. There's 2 manifest settings in play here: target API (15 aka ICS), and minimal API (depends on what you use).
To get a good mix of API support and broad coverage in the consumer market (using the dashboard that #Basic pointed to), I tend to point people at API level 8, which is Android 2.2 (aka Froyo). You'll hit roughly 93% of people out there and you'll get the APIs you need for most development. If you know you need newer APIs, by all means use them. The world will catch up, it may just take some time.
I typically point people to get a Nexus phone or XOOM tablet. You need the reference design so you can stay on top of the official releases from Google as quickly as they come out. The AOSP builds are important to follow, but they aren't the only game in town. After that, if you want to be serious about it, you should pick up one phone each from the major OEMs so you can deal with the differences in the customized platforms (Sense, Blur, Touchwiz, etc.)
Disclaimer: I work for Motorola. MOTODEV Studio is my teams' product (thanks Basic!)
Samsung Galaxy Nexus, Good because it is a phone that is supported directly from Google.
Samsung Galaxy S2, it just has all the features you need
One of those two for spec heavy phones, but you also need a cheaper not so good phone so you can get both ends of the device range, so get something like a IDEOS as well.
All you need to remember is that there is never going to be just one type of device being used, there are hundreds, if you have a phone thats close to the bottom and your app works almost as well as a phone as the top it will be good, because you will be able to catch the whole range of customers.
Also for location based things all you need to do is put permissions in the android manifest and it should be good, users are notified about these when they download the application
Mac can be good for development, its supported by Android as well so I dont think you will have a problem, when I went to the Android devs lab it seemed to be that all the Google guys had macs anyway
It depends what you want to support. There's a whole spectrum from the HTC Wildfire up to Galaxy S2 / HTC One.
What versions of Android are you going to target? Some people are still on 1.5!
Regarding updates: Google releases updates at their own speed. The problem is that before that update reaches a given device, the carrier usually customises it to include branding, mandatory aspps, etc... Which can take an indeterminate length of time or may not happen at all. This was one huge benefit of the Nexus One - it wasn't branded so updates were available as soon as they were released.
Regarding Development: eclipse is available for almost every platform and is a great starting place. MOTODev Studio is based on eclipse and is excellent as it comes with templates, pre-configured emulators, etc...
Location Services: Android uses 3 approaches to get your location: GPS (Works poorly indoors, can be slow to get a fix, quite a battery hog), Wifi (Google have mapped the location of a lot of wifi networks - thus if it can see a known wifi network, it knows roughly where it is) and finally network (It knows the location of the cell tower(s) your phone is talking to).
None of the above needs a contract but Wifi requires an internet connection (to perform the lookup) and Network obviously requires your phone to be in range of and allowed to talk to a cell tower - which usually just means getting a sim for a network which covers your area.
Note that when getting location on the device, you can opt to have coarse of fine-grained location information. Coarse doesn't fire up the GPS (They also require different permissions)
See this page for more info about location
Personally, I would recommend the Toshiba Thrive 10.1 Inch Android Tablet.
It has:
1 GHz Nvidia Tegra
1 GB RAM
Full Size USB Port
Full Size SD Card Slot
Full Size HDMI Port
Mini USB Port
Can be upgraded from Android 3.1 to 3.2 or 4.0
And it usually only costs about $200-250 depending on how much memory you want.
I haven't seen this capability with any android app, nor have I seen anyone ask it. Is there any way that the Bluetooth or something can be used within your app to see a list of all the other android devices around you? For example, if my friend is using my app and he is in the same room I can see his device on a list in my app, and he can see mine...
There would have to be something that ties to two devices together, for example being on the same Wifi. As it is there is nothing that broadcasts to other devices that you are there by default. Even Bluetooth requires you to turn on discovery mode, or discoverable mode, and even then it will only stay on for a few minutes. If you wish for two devices to tie together, I am almost sure you could use the Bluetooth, but you would have to go through the normal process of discovery, synchronization, and permissions.
I don't think you can use BT to see what OS any phones around you are using, and they would also have to be set to discoverable.
If you want to make an app, it's possible to construct one where people agree to be located, but that's a voluntary issue, and it would be based on GPS radios in the various phones. I'm working on an app right now that has this capability, but again, it's something people sign up for so they can be located specifically for this purpose.
I would explore using the Google Latitude API as a possible avenue of exploration, before you reinvent the wheel creating a similar service.
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.
I started developing android applications. And am testing with the android emulator. Do I really need android phone before releasing it for public usage?
Short answer No. You can test and build a android application package with the SDK and an emulator. But I would say there are usually many things which it would be wise to test on a device.
Personally I have noticed that the emulator does not give a good indication of response times for UI controls. It is usually necessary to move functionality which has long processing times into background threads to maintain user interactivity without the 'force close' pop-up. Testing the effectiveness of your UI responsiveness must be done on a phone to be meaningful.
Network connectivity is another aspect which can be vastly different on a phone, 3G or wifi.
Device sizes and Android platform versions can be tested effectively on the emulator.
Some phone allow hot-swapping of the SD card (replacing the SDcard without turning off the phone). I am not sure how to replicate this on the emulator.
There may be many more things which may only become apparent when using your application on a real device. I would strongly suggest to always test under real conditions when feasible for any commercial project.
From a technical perspective there's no reason why you can't develop purely on the emulator. You're not going to be able to test on every available device, so there's always going to be possibility of device specific bugs that you've missed.
However, I'd strongly recommend getting an actual phone to test your application on.
For me the biggest difference between an actual device and the emulator is the difference between using the interface with your fingers and using a mouse. Interactions which make sense in the emulator sometimes don't work as well when you start using touch on the screen. So if you develop purely on an emulator you'll won't lots of little improvements to your UI that would obvious when you used your app on a phone.
You can't feel a real app in your hands until you have a real phone. (I'm telling you as an Android developer)
So, developing w/o real phone is possible, but real phone gives you a lot more experience, fun & usefulness.
It depends on what type of application you're developing, for serious ones you need at least one device to test it on. For complex applications you would need a range of devices, for example with or without hardware keyboard, different navigational button etc. For basic, simple applications you'll probably do fine with just the emulator.
I would imagine with games you would definitely need to test on real devices.
Thanks to you all. I am going to get HTC Legend and test it, so that I can hope that my apps can be used by others :)
You guys suggest me HTC Desire or HTC Legend?