There is some way to know if my Android app is running on debugger or on a phone?.
I want to check some variable, property, or something like that to know where the app is running to prevent some crash when I call some 3rd applications (not available on debugging time)
Thanks and sorry for my poor english
You might want to look into DDMS
You can access logs, threads and heap information. also check running apps and services. You can also simulate phone behaviours on the emulator, like an incoming call, as an example. Well, I would also recommend reading all the information in the debugging section, there are a lot of useful tools available for Android developers.
You mean detecting the emulator? Because you can run under debugger also on your device.
Use this to detect the emulator (worked for me a while ago):
"google_sdk".equals(Build.MODEL)
Related
Greeting QiSDK Pepper robot community !
We know that there is an option to make Pepper QiSDK Android to reboot with full sensor check (long reboot), but we have forgotten how to make that happen and can't find instructions.
Please help :)
The Qi SDK relies on the Android SDK, and the latter does not provide a programmatic way to reboot the device. So the short answer is that you cannot.
But with a bit of creativity and a bunch of know-how, who knows...
Though it is not documented, the API for NAO 2.8 usually works for Pepper 2.9. So you can use libqi to connect, authenticate, and call ALSystem.reboot. Note that you will be able to authenticate only if you know the password of the robot, i.e. if you own the robot.
I had other bad ideas to reboot the tablet, but as discussed in the comments, this is not relevant since you want to reboot the robot and have it do the full check-up. I keep them here for the record:
I found this page about "Device Control" that mentions rebooting a device remotely. But it comes as part of a broader framework that seems deprecated, so I doubt it works.
You could have access to the tablet via WiFi and run adb reboot remotely. But leaving the remote debugging enabled is not a good idea in terms of security.
You can certainly access such system-level methods if you root the tablet. But this is a staggering security hazard.
Android website recommends to test an Android application on a real device before releasing it to others. Based on this I would like to know one thing:
When USB debugging is enabled on the device and android applications are tested in real time, does it have any effect on the functionality or performance of the Android phone?
What I mean to say functionality is, about the working speed, app failure or anything similar.
No, there is none or a little bit that you wont even notice. Your phone will still function normally. You can also use eclipse to log your phones performance and other things. The only thing the eclipse do when you debug the application is attach the debugger to your app and debug it. It will only install your app and lets you test and debug the app. No performance degradation is done. However the application will still occupy the memory on your phone. So it will definitely consume your internal memory like every other application does.
USB debugging allows you to use the debug in Eclipse or any other Android SDK you are using to test your application. You can have it set to allowed (USB debugging) and you won't even notice it. If anything, it will just drain your battery faster
From the perspective of an application it won't affect performance, but at platform level it can.
I'm trying to develop an app that would normally be considered to be malware, but the customer's demands are very specific and logical. We have around 50-100 cheapset Android phones that are bolted down, plugged in, and the app is supposed to send some of the sensor data via tcp to a remote server. It sounds simple enough, but there are two features that I struggle with (since I'm not an experienced Android developer, and have never rooted a phone):
#1 The app should be always on. If it crashes, server should get the error report (stack trace), and the app should be restarted after 10 minutes one more time before giving up. Also, the OS could theoretically kill the app (although I did my best to minimize the memory usage). I'd like to somehow handle that as well.
#2 It would be great if the app could be remotely updated, or auto-updated, with no user interaction whatsoever (since there is no conventional user).
To implement #1, I see no other solution than to root the phone (AlarmsManager doesn't seem to work as I expected, and adding another application to take care of the first one just feels wrong). Is there anything I'm missing?
I don't know how to approach implementing feature #2 at all. If I put the app on the market and check the "keep this application always up to date" checkbox while installing it, will that work? I fear that the auto-update would not occur while the service is running, and even if it did, that the OS would not restart the service after installing the update (unless feature #1 is implemented). If I programatically download the latest .apk and open it, I still need the user to click the "Install" button. I'm even considering implementing the updateable part in some scripting language.
Is there a solution to these problems within the limits of Android API?
EDIT: Thank you all for your answers, you've been very helpful. It seems that the only way to make Android behave as a non-user piece of hardware is to root it. That's the only way to do silent auto-updates. Always on can then be implemented by enabling cron (AlarmManager apparently doesn't fire the event in case of service termination via crash, but it could be used by another trivial, non-crashable service to keep the first one running).
For #1 you can use an foreground service. I don't know how often you need to get sensor data, but what's the problem with AlarmManager? I don't see how rooting could help with #1 though. You can't really do #2 without rooting or building your firmware. If you install your app as a system app (in /system/app) you can use a hidden PackageManager to silently install the new version. Using Market/Play autoupdate should work as well, but you have no way to control the update schedule. And, yes, it won't restart your service, but if you use AlaramManager, this shouldn't be a issue.
All in all, stock Android is not exactly an embedded system that gives you full control, so depending on how much time/effort you are willing to spend, you might want to customize it somewhat (or find a custom ROM that gets close to your requirements).
Re: question #2, there are a few open-source (licensed under the Apache Software License 2.0) options you may check and see how it works.
https://github.com/lazydroid/auto-update-apk-client is the android client for the auto update service (i'm affiliated with), which is small, easy to implement and supports silent updates on rooted devices.
https://github.com/commonsguy/cwac-updater is written by Mark Murphy, however it might require you to run your own update server and I'm not sure about silent updates.
Is there any way to restart a device per code from within android. I can highly customize all software on the device (tablet). As Backgroundinfo: I want a timer that restarts the device after a defined count if he did not get reseted.
Edit:
If there there is no Buildin-Way is it possible to do this anyway?
In general Google dont allow third party apps to Reboot device below are few link might be helpful
http://groups.google.com/group/android-platform/browse_thread/thread/daf7c685e020d296
http://groups.google.com/group/android-developers/browse_thread/thread/5a97467ef5b4bf47/a1fe9379d4f5e30f?pli=1
This isn't possible from within an app, I believe.
The intent for rebooting the device (ACTION_REBOOT, if I recall, but I'm happy to be corrected!) can only be called from the system itself, not from any software residing on it.
(See the Android reference docs here.)
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?