Sometimes the Android Emulator that you just started up does not show in the Devices list in the DDMS Perspective of Eclipse. If that happens to you (like it just happened to me), then do the following in your command line to get it to show up:
You should see this output:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Then your Emulator instance should show up in the Devices list.
I’m not exactly sure why this happens, but it has to do with adb (the Android Debug Bridge) going into a bad state. The kill-server/start-server combo serves to reboot it and back into a good state.
Good news! I’ll be giving this talk again at AnDevCon San Francisco in November. I’ll be updating it based on questions I received in Boston, recent developments from Google and Intel. Also there are some things that I wanted to include in the original that I’ll be adding. Come check it out live in San Francisco!
Two weeks from now, on May 31st, from 2:00 PM to 3:15 PM, I will be giving a talk about the Android Emulator at AnDevCon Boston. It is titled “Becoming More Effective with the Android Emulator”, but in order to spice things up a bit, I’m going to give a it a MythBusters-style twist. The subtitle is “Android Emulator Myths…Busted!”
I’ve really fallen in love with the Android Emulator as part of my Android development workflow. I find it a lot easier to work with than switching over to a device, especially with the advancements that have been made in the past year or so. So I really want to share my insights in how to make it work well for everyone. I’m hoping it encourages more people to discover how useful the Emulator is as a tool in the Android toolbox and use it more regularly.
If you want to attend a pure 100% Android development conference, definitely check out AnDevCon. I’ve been to the previous two events and really enjoyed all the content as well as meeting more of the Android community in person. Also, if you use code “DELAROSA”, you should get an additional $200 off the registration.
Hope to see you there!
Here’s a paraphrased quote from the Q&A session after the What’s New in Android Tools session at Google I/O 2013:
We will continue to support Eclipse. We are focusing on the Android Studio to get that up to speed. We will be changing the build system of ADT (Android Developer Tools) in Eclipse to use Gradle (from Ant.)
- Xavier Ducrohet, Android Developer Tools Team
Here’s my quick notes on a git workflow to create a branch, merge and clean up:
Create a branch named “x”:
git checkout -b x
git branch x
git push origin x
git push -u origin x
git checkout x
git push --set-upstream origin x
Merge a branch “x” back into master:
git checkout master
git merge x --no-ff
Note that this creates a merge commit to make it easier to find where branches are merged into master.
Clean up branch “x”:
git branch -d x
git push --delete origin x
Update [2013-05-15]: Used the “-u” option with git push so we have one less line when creating a branch. Thanks to @jdriscoll for that tip.
Update [2013-07-11]: Used the “-b” option with git checkout so we have one less line when creating a branch. Thanks to @bobz44 for that tip.
I’ve been starting to use calabash-android, which is a way to run cucumber tests on Android. It requires Ruby Gems and Xcode Command Line Tools on Mac, which installed fine. However, when I ran the first sample test, then I noticed the app did not start. I looked at the output and saw that this error showed up:
App did not start (RuntimeError)
I looked around for the solution and did not find, so I tried a few things. It turns out to be an easy fix. In your Android app’s manifest, aka AndroidManifest.xml, include the line:
<uses-permission android:name="android.permission.INTERNET" />
inside of the manifest tag, after your application tag.
Why does this work? The reason is because Calabash-Android (and Cucumber in general) uses HTTP to communicate between the host computer and the target application. Since Android apps do not have permission to communicate via HTTP by default, the test fails to start.
So you’re being a good Android developer, using JUnit 3 tests [Sidenote: JUnit 4 does not play well with the JUnit runner in Eclipse for Android currently] and using Mockito to create mocks to make sure you’re focusing on the class that you’re testing. However, you run into a java.lang.ExceptionInitializerError when running your tests. This is pictured below. What should you do?
To use Mockito on a device or emulator, you’ll need to add three .jar files to your test project’s libs directory: mockito-all-1.9.5.jar, dexmaker-1.0.jar, and dexmaker-mockito-1.0.jar.
– “Mockito on Android” from the Square Engineering Blog
Put those 3 JARs linked above in a “libs” directory in your test project.
The root cause of this is that the classes that Mockito makes needs to interact with dex, which is what Android uses to create its classes. This can be done with Dexmaker and the Dexmaker/Mockito integration. Once you add in those 3 JARs into your libs directory, just do the refresh/clean project dance and then you should be good to go.
Special thanks to Jesse Wilson (@jessewilson) for making DexMaker and integrating Mockito with Android!
If you have ever had to implement the Parcelable interface for one of your Android classes, you will find that it is tedious. It is especially tedious the more fields your class has. So usually you don’t do it unless you have to pass it in an Intent to an Activity or as a Bundle of arguments to a Fragment.
Enter Parcelabler, which is a web-based tool that creates Parcelable implementations for you. Just copy the portion of your class which has the fields into the Code textbox and then press the Build button. I’ve had good results with it, although it is best at primitive fields. I usually edit the class in a text editor like Sublime Text to make it so that only the class and fields are entered.
Thanks to Dallas Gutauckis for creating this helpful tool!
I’ve recently been having problems with my Nexus 7 not booting up after it completely runs out of battery. Specifically – even if I have charged it overnight, if the power is off and I click the power button, then it does not turn on!
I’m not sure if this is related to 4.2.1, but this problem didn’t seem to occur with 4.1.1. I’ve got the 8GB version of the Nexus 7.
To solve it, press and held on to the power button until it starts up (for approximately 30 seconds.)
Note that Asus has a support page which mentions this titled Nexus 7 won’t start up. I agree with their recommendations, but I’d add that you’ll probably need to press and hold it for longer than what they recommend (around 30 seconds vs their recommended 15).
Update: after a quick search, a thread on Android Enthusiasts titled Nexus 7 wont boot after complete discharge corroborates my findings.