I will add a version using Gluon and Windows 10 soon. So stay tuned.
|Lubuntu after a couple of small changes running inside VirtualBox|
As I need a really up-to-date Java development kit, I decided to download it directly from the Oracle website. Though this is mere personal taste, I like to put it in /opt and add a symbolic link without a version. This is convenient as I encourage you to include its bin directory in PATH. Switching Java versions can then be done be changing the link, rather than modifying PATH. This brings us to the question of where to change this environment variable. I chose .xsessionrc in my home directory. Why? Well, if another user doesn't want or need a JDK, I think he shouldn't see it.
# Java (JDK)
As I need Android Studio and the Android SDK as well, I set it up in .xsessionrc, too.
ANDROID_HOME comes in handy if you plan to use Gluon Mobile. Well, and access to the tools and platform-tools directory provides quick access to, for example, adb and emulator.
I did not know that I could have installed NetBeans through apt-get, so I downloaded it from the NetBeans homepage. The installer kindly put an entry in the Lubuntu desktop menu. As I wanted this for Android Studio, as well, I added that entry on my own. Here is how to do that. Provided, you have installed Android Studio to /opt/android-studio, just create a file called studio.desktop with the following contents and save it to /usr/share/applications.
Finally: I am a big fan of Sublime Text 3. Here is how to install it.
sudo add-apt-repository ppa:webupd8team/sublime-text-3
sudo apt-get update
sudo apt-get install sublime-text-installer
That's it. Happen to have any other tips regarding Lubuntu? I'd love to hear them.
I will have both the pleasure and honor of hosting a full-day workshop about Java on mobile devices. Titled Ménage à trois, we will be taking a closer look at how to build Android and iOS apps using Java and JavaFX. Based upon the open source project JavaFXPorts and its commercial sibling Gluon Mobile, we will build a few real-world apps and deploy them to both emulated and physical devices.
Interested? Take a look the the schedule:
Introduction of the participants
A little bit of history... Java on mobile devices
A first glimpse at the tools: emulators, simulators and virtualization
Setting up the development environment #2
Looking under the cover (walkthrough)
Gluon Mobile and its components
Using device functions #1
Artefact archeology - what finds its way on a device?
Using device functions #2
If something goes wrong (debugging)
What will not work (missing functions)
What's up? Profiling and performance
Sounds good? Remember the early bird offering ends tomorrow, Jul 22. Book now.
Although the Google toolchain used to rely on standard Java byte code as an intermediate step, this may no longer be the case in the future. Its final artifact (the end of the toolchain if you like) consists of one or more Dalvik executables. If you take a look at an Android application package (.apk), you will find a file named classes.dex. Depending on the size of the app, there may be other, similarly named ones, too. As application classes as well as any dependent library are put there, I decided to use the .dex files for my dependency analysis.
The Android SDK contains a tool called
dexdump. Its purpose is to provide a (nicely) readable representation of .dex files. Hence, all I needed to do was to bake a small tool that interprets
dexdumpoutput. You can find this tool here. It is written from scratch and is completely unrelated to Degraph. Still, I feel the need to credit Jens, especially for his idea to visualize the output of his tool using yEd.
You can extract classes.dex using
tar xf. The screenshot shows a small portion of a
dexdumpoutput. To use it with my tool, you should create a text file as follows:
dexdump -l plain -f classes.dex > classes.txt
Let's see what
DexAnalyzercan make out of it.
As you can see, by default analysis is based upon packages. The following screenshot shows how to distinguish classes and produce a file that can be opened in yEd.
I am going into more detail later. For now I encourage you to play with my tool. Please keep in mind that it is in its infancy. If you encounter any misbehavior, please feel free to let me know. Passing command line arguments seems to not work as expected if options appear after filenames. Also, please note that checked exceptions currently do not count as dependencies. I plan to add this later.
The Mac is still a lovely machine for developers. I enjoy the beauty of macOS, its slick ui and versatile commandline interface alike. Don’t get me wrong. I love Windows, too. That is why I have a Windows 10 running inside VirtualBox. This allows me to work with Visual Studio, for example in order to write Xamarin-Android-Apps. There is one issue, though. The current version of VirtualBox does not allow me to run Hyper-V, the Android Emulator utilizing HAXM, or any other virtualization technology. Para-virtualization is not easy to implement, I am sure. Other products appear to offer this feature, but one of the beauties of VirtualBox lies in being free.
So, what can we do about this?
As a VirtualBox client shares the network with its host, I asked myself why the Android Debug Bridge should not be able to find an emulator running on… the host.
So, I fired up Android Studio and Android Emulator on the Mac. Here is what I got.
So while we may see a resolution in the future this does not help us now.
Other Android emulators appear to face the same fate.
So, are we left without options? Far from it… If VirtualBox is the only virtualizer that may run at a time, why not run Android inside VirtualBox? Just get an Android x86 image from the Android x86 project homepage, configure a client and install Android from the iso image. Make sure to configure a bridged network.
Once you have finished setup, you will be able to debug Android apps running inside VirtualBox from within another VirtualBox client.
Almost. A few steps remain to be taken.
First, get the ip adress of the emulated Android device. Open system settings, navigate to About Phone/Tablet and click on Status.
Second, open up the Terminal Eumlator app and enter the following command: adb tcpip 5555
Third: On the virtualized Windows client, issue the following command: adb connect <device-ip-address>
Finally, use adb devices to verify that the connection has been established.
That is it.
Welcome inside the matrix.