When developing on BlackBerry or iOS, you can deploy your application just by dropping the compiled code into a special directory, and when the simulator boots up it will check that directory and install any apps that it finds there. Is this possible for Android?
The reason this feature is desirable is because my build system deploys builds nightly. I want the emulator ready to go when my QA team gets in the next morning. To do that, I have to write a script that boots up the emulator, waits for it to start up, then calls adb install and finally shuts down the emulator. It would be great if I could just drop the .apk in a directory and have it ready to go the next time QA boots up the emulator.
Edit:
Someone asked for the script I described above. It's unfortunately written in Perl, but here it is: http://pastebin.com/6UcNgYRs
Edit 2:
I just found an awesome little command that can help you if you're trying to write a script like the one I mentioned above. You can have your script wait for the emulator to come online with the command $ adb wait-for-device!!
Is this possible for Android?
No, sorry. Nice idea, though.
You can just tell the QA people to use the install script as the emulator itself, just remove the "close the emulator" bit.
Related
I have a problem with the game crashing after the build. If I run the game in Unity, then everything works. And when I build it on android, when I start the first training scenes work fine, but when I reach the main stage, the game crashes. There is a error in Unity:
Google.JarResolver.ResolutionException: Cannot find candidate artifact for com.google.android.gms:play-services-games:8.4+
Maybe that's the problem. If that's not the problem, how do you know what it is?
So this looks like plugin resolve problem. But more information wouldnt be bad and you should learn how to see your device logs on Android. Here is how:
You should check the logs of your mobile device in the moment of the crash. You can do it by using "adb logcat".
First you should download SDK Platform Tools.
Then, enable USB debugging on your phone.
Connect your phone to your PC and give the permission it needs. It will ask you when you first connect it.
Open command line on your computer, go to your SDK Platform Tools folder, copy the directory and paste it after writing "cd " to your command line
Now you can use adb to figure out your Android crashes. To filter the ADB you can use
adb logcat -s Unity ActivityManager PackageManager dalvikvm DEBUG
This way you will only see Unity related logs from your device.
i'm currently reading through head first python and upon reaching chapter 8 I got stuck. The book wants me to download SL4A from the link http://code.google.com/p.android-scripting however that link no longer works. So I did some searching and found the file on github. My real problem is when I try to download it on the emulated device it just says waiting for data connection and it never downloads. I am wondering if there is a way to fix this. Any help is appreciated thanks!
EDIT: to get it to work I downloaded both files from here https://github.com/kuri65536/python-for-android/blob/master/README.md
then I copied the files to the folder
C:\Users\lucas\android-sdks\platform-tools
then I opened CMD and cd to the path above.
then use the command:
adb install (filepath)
for both files and they appeared on the emulated device.
Download to your pc and push through ADB.
Download files and adb install worked for me in my installation (Windows 10, android studio 2.1.1) with minor differences:
1) adb command is located in:
C:\Users\MyUser\AppData\Local\Android\Mysdk\platform-tools
Need to add to path
2) Needed release sl4a-r6.1.1-x86-debug.apk. Downloaded it from release pages
I'm also reading through HeadFirstPython and got stuck at this stage (with the error: app not installed). I tried the abs method above and ended up with yet another problem: install_failed_no_matching_abis. After a lot of research, I got to understand that the "native libraries" of the sl4a.apk were not matching the system architecture of my emulated android. In other words, if one wants a faster emulator in android studio, he ought to use an x86 architecture android; but the problem with that is scripting layer for android is programmed to work on ARM architectures hence the 'install_failed_no_matching_abis' error.
The solution that worked for me was to go back to AVD in Android Studio, delete the downloaded emulator (which was of x80 cpu/abi) and download one with armeabiv7 cpu, recommended level=24. It took a lot of trial and error to get to this choice as other android cpu/abi were either too slow or just wouldn't allow me to install the required apps.
Edited: In the end, I was directed to use GenyMotion as that performed better in terms of speed. I was reluctant at first but, to my surprise that really is the case (It is super faster than ARM android studio alternative). Not only is it a great emulator, it also has this ARM translation tools that allows one to easily install ARM sl4a.apk on the x86 devices.
I'm jumping head first into Android for Google Glass development and I'd like to know how I can let my client see the .apk that I'm working on.
My client owns a pair of Google Glass too but lives far away.
So far, the only way I have been able to upload to Glass is using ADT, Run As -> Android Application when my Glass is connected by USB.
How can I put the Glassware (apk) up online so he can "load it up" into his glass remotely? Or deploy it to his glass?
I read Send the .apk file to client for review but it's more related to Android devices, whereas my client uses Google Glass and doesn't have debug mode on (I can ask him to turn it on though) and won't root his device.
You might want to have your customer use ChromeADB -- you can see it here: https://chrome.google.com/webstore/detail/chromeadb/fhdoijgfljahinnpbolfdimpcfoicmnm/reviews?utm_source=chrome-ntp-launcher
From the comments it looks like other people are using this for similar situations.
I suppose your client owns source code so they may be glad to download the SDK at http://developer.android.com/sdk/index.html and install ADT then use the Android SDK Manager to install the SDK Platform, so they can either get your updated source and install it to Glass from ADT, or run adt-bundle-mac-x86_64-20131030/sdk/platform-tools/adb install .
Well my client has the Android SDK installed on his system and he just turns on the usb debugging mode on on his glass. Then he installs the apk using the adb install app.apk command
So far there is no other option available than this.
For Installation and testing on client side one need to follow below mentioned steps.
Download this android-tools.zip to Windows PC and extract it using any unzip tool
Copy the desired APK file (Say testapp.apk) to the extracted folder i.e in android-tools
Now open command prompt Win -> Run -> cmd -> ok
Run this command adb install testapp.apk
adb is open sourced, it shouldn't be difficult to wrap it up in a standalone application or you can rebuild adb and dependencies (due to binary license you can't simply redistribute you need to build the AOSP based code which is distributable - but IANAL)
If wrapping up commands (easier route) you can refer to these command line scripts to uninstall and run by simply passing the apk file name:
How to start an application using android ADB tools?
Hopefully this helps...
But you could use BlueStacks and have the client install the APK into the program. BlueStacks will setup a preference for ".apk" files to open up in the program itself, So no command line ADB is required. I dont know how well Glass APK's will run, however the BlueStacks emulator has come along way and work well with most general applications. So if your client has either Mac / Windows, they can easily setup an the Android emulator and can run your APK's. They could always just setup the Android SDK and use the standard emulator, It still will wont resemble a Glass device, however this could help the client understand what you are doing in the app. Its worth a try at least.
I have this application which I'm testing. I use a script which automatically installs the app but I also want to restart the device. This is important as after the installation I run a monkey-test on the device and all kind of quirks and bugs may arise. To get rid of these I want to restart the phone to get it into some kind of "known state". (These bugs are not only in the app as the phone has been known to suddenly shutdown during the tests)
My installation script is run with jython and I know of the device.reboot() command but this takes almost no time at all (which makes me suspicious) and doesn't work very well. I know there's three arguments: "bootloader", "recovery" and "None" but I can't find the impact these would have on the device.
So my question is, is device.reboot() the right command to use? If yes, what happens when I don't use any arguments with the device.reboot() command and what is the effects of the arguments.
It may be worth mentioning that I run the jython script from a batch command prompt in jenkins. So any batch commands using adb or similar would work just as fine.
device.reboot("None") works on my device
I have been developing on Android with Eclipse for a while, and I recently switched over to using Ant for my build system. This gives me a number of useful advantages, but it seems to really badly break Eclipse's behavior with respect to building and the emulator.
My biggest problem right now is that, if I change something in my code and hit the "Run" or "Debug" buttons, it rebuilds the app like it's supposed to, but when it comes time to install the app and run it, I get the dreaded "Application already deployed. No need to reinstall." message, and it refuses to install it. Even if I do a "clean" and rebuild my app from scratch, it still doesn't recognize it as newer than the one installed on the emulator.
Of course, I can uninstall the app from my emulator first, but that's a huge PITA, because my app involves setting up a user account after initial install, and I don't want to have to do that every time I am testing a change. I can also force install from the command line through "adb -e install -r ...". That's what I'm doing now, but it's an extra step that shouldn't be necessary. I would really like to be able to take advantage of the "I" part of my IDE and actually compile, run, and install from it the way I am supposed to be able to.
How does the Android SDK in Eclipse decide whether the app needs to be reinstalled? Is there a timestamp on some particular file that it looks at? Is there a way I can force it to install every time?
There has to be a solution to this problem.
This works fine in my eclipse, and it always had. So I would suggest:
reinstall ADT plugin
reinstall eclipse altogether.
Or you can workaround this issue by adding extra step to your project with "adb -e install -r ..." command line (using ant build script).