FAU Android

FAU's local android experts!

Determining your Device’s Info in Java

Posted by Charles Norona August - 25 - 2010 - Wednesday Comments Off

Sooner or later there will come an instance where one is developing applications on Android and will have to provide some kind of mechanism for making their applications compatible with different hardware platforms. Reasons for using this class can vary from ensuring that the user interface looks proper across different resolutions, changing parameters within algorithms in order to optimize performance, etc. Fortunately, the Android engineers have provided developers the android.os.Build class which can be used to acquire this information. An example of its use is depicted below:

private String TAG = "SSLA";


//Determine the local device info for compatibility
Log.i(TAG, "Device information: \n" +
"Board: " + Build.BOARD + "\n" +
"Brand: " + Build.BRAND + "\n" +
"CPU: " + Build.CPU_ABI + "\n" +
"Device: " + Build.DEVICE + "\n" +
"Display: " + Build.DISPLAY + "\n" +
"Fingerprint: " + Build.FINGERPRINT + "\n" +
"Host: " + Build.HOST + "\n" +
"ID: " + Build.ID + "\n" +
"Manufacturer: " + Build.MANUFACTURER + "\n" +
"Model: " + Build.MODEL + "\n" +
"Product: " + Build.PRODUCT + "\n" +
"Tags: " + Build.TAGS + "\n" +
"Time: " + Build.TIME + "\n" +
"Type: " + Build.TYPE + "\n" +
"User: " + Build.USER);

//Example application of using the Build class.
if ((Build.MODEL.equals("T-Mobile G1"))
|| (Build.MODEL.equals("HTC Dream"))
|| (Build.MODEL.equals("Era G1")))//T-Mobile G1 or HTC Dream
slideRate = 6;
else if (Build.MODEL.equals("Nexus One"))//Google Nexus One
slideRate = 4;
else//Default sliding background rate.
slideRate = 4;

The giant log statement produces the following output on the DDMS Logcat:

Output showing use of Build class.

Best practices and guidelines for writing efficient, well-designed Java programs

Posted by Georgiana Carvalho May - 19 - 2010 - Wednesday Comments Off
You must watch this video: Write Essay

This section covered several practices and guidelines for writing efficient, well-designed Java applications, specifically for the Android platform.

These guidelines are not only for improving the efficiency and speed of an application but also for making it more reliable, robust (less error prone and more secure), reusable and maintainable. 

To view the material covered in class please see Java – Best Practices.

To view the class recording see: Part 1 and Part 2.


  1. Effective Java, Joshua Bloch, Prentice Hall, 2008 (ISBN-10: 0321356683)
  2. Best practices for coding your Android applications: http://developer.android.com/guide/practices/design/performance.html

RIFL Now Hosted by Google Code

Posted by Charles Norona May - 15 - 2010 - Saturday Comments Off

I have started a Google Code page for my group’s past Engineering Design II project. You can find the page at http://code.google.com/p/rifl/. Here you will find relevant documents that were used during the design process, various updates, models, and other supporting information as well as a subversion repository to check out the basestation and mobile application projects or even contribute to it. Below is the project’s summary:

Originally an Engineering Design II project from Florida Atlantic University (http://www.fau.edu/) the Relative Indoor Firefighter Locator was meant to establish a Bluetooth piconet where sensor information can be used to track the user’s location (first responder) through the use of a mobile device. Ideally, this system would be self-sustained without relying on outside networks and work fairly well indoors.
As of the end the of Spring 2010 semester our EDII team managed to implement a Bluetooth data transmission medium and implement a simple version of a pedometer to track user’s relative location for a single mobile device. Future improvements consist of allowing multiple devices to connect to a base station, a data medium protocol to allow the piconet to communicate with other piconets which would form a scatternet—effectively extending tracking ranges—and an improved means of interpreting sensor information to better track the user’s location. It is our hope that by hosting this project that all of these areas can be met and the community can take advantage of the techologies available now as well as in the future.
We acknowledge the efforts of the members the Android Open Source Project (http://source.android.com/) for providing the foundations of bluetooth connectivity for the Android mobile devices as well as the efforts of Paul Totterman and Vlad Skarzhevskyy of JSR-82 BlueCove project(http://code.google.com/p/bluecove/) the and those who committed to it for providing the framework to allow Bluetooth connectivity on the PC platform. In addition, we would like to thank our project advisors Drs. Henry Helmken, Bassem Alhalabi, and Ravi Shankar for their support.

FAU Spring 2010 Engineering Design II Team Six
Project Leader: Charles Norona, cnorona1@gmail.com , http://android.fau.edu
CE Member: Allan Pinero
EE Member: Christopher Sizelove

RIFL Update T-Minus: One Week

Posted by Charles Norona April - 15 - 2010 - Thursday Comments Off

Here, I have compiled a collection of updates given that I have been busy managing our team in wrapping up our Engineering Design II project:

  • Power Metrics: In order to incorporate more electrical engineering aspects I have uploaded a couple of creenshots of some power consumption metrics acquired by the University of Michigan’s PowerTutor (http://powertutor.org/) application while the RIFL client application was running on the phone. Unfortunately, it only tells us about LCD and CPU power consumption (GPS and WIFI were not being used by the app). We still need to find out how much power was being consumed by the sensors and the Bluetooth radio. Both I think can be estimated based off of the information from the appended datasheets:

    AK8973 3-axis Electronic Compass:
    BMA150 3-axis Accelerometer:

    We still need to find out more about the Bluetooth radio and how much power it consumes during an RFCOMM streaming transmission.

  • Base Station Application: I have cooked up a little applet to test out the tracking of the RIFL system as well as output an excel compatible table of sensor values. It performs fairly well but as expected there are some inaccuracies. Allan is currently working on an the front end which will add many features to the RIFL system and take advantage of the capabilities of this applet. The test applet is available at http://engineering-design-ii-group-6-spring-2010.googlegroups.com/web….


  • Bluetooth Connectivity: In the past week we have successfully managed to connect the PC to one of the Nexus Ones we will be using as a prototype. After having implemented the RFCOMM server-client programming into the base station and the mobile device it was simply a matter of pairing the two devices together and matching their universally unique IDs (UUIDs) before they would server application on the base station would connect via Bluetooth to the client application on the mobile device.

Unit and Functional Testing in Android

Posted by Mihai April - 13 - 2010 - Tuesday Comments Off

Testing should be an integral part of the development process, no matter on what platform and what programming language you are using. Two flavors of testing were described to students:

  • Unit Testing, where you test your code to see if it runs correctly, and
  • Functional Testing, making sure that your system complies with the functional requirements.

Unit testing tells the developer that the code is doing things right, while functional testing tell a developer that the code is doing the right things.

If you are interested in this topic, and what has been discussed in class, please visit my blog post at http://mihaifonoage.blogspot.com/2010/01/unit-and-functional-testing-in-android.html.