Tag Archives: Android

Ion Successfully Rooted

I spent most of the day Friday scared half to death that I was about to brick my Ion, but the end result was a success! I got a shiny green # prompt in my terminal and I can now proceed to do fun things like download multitouch enabled apps and try out tethering 😀

I had some issues getting my phone linked back up to the T-mobile network after I installed the hacked OS, but the awesome folks at the XDA Forums helped me out. If anyone in the lab (or friends of the lab) would like their Ion rooted for them and tethering enabled, I can set it up for you. The rooting should take less than 30 minutes or so if all goes well on it. I haven’t done the tethering yet but I’m going to work through it for a few hours today.

Edit: But I’m not responsible if anything terrible happens to your phone! Surprised

Edit #2: After ~4 hours of working away at it, I hosted wifi from my Ion to my eeePC!!! Unfortunately, I can’t pick up 3G at my house, and the connection is terrible in general 🙁 So I can’t be 100% sure that everything is working perfectly until I’m somewhere with a better connection. Things look good though, and the tethering app I’m using is very cool as well; you can host wifi or bluetooth connections to the Ion’s 3G!

Introducing Mobile Metagenomics!

Mobile Metagenomics is the name of my latest project. What I am trying to achieve with this Android application is a mobile implementation of Rob’s Real Time Metagenomics webpage. I envision several development phases for this application, but the first stage will likely play out as follows:

1. Create a suitable UI (striking some type of balance between preserving look&feel from the website, and Android-ifying things)

2. Generate a request that the CGI online will recognize

3. Receive the results and organize them in some manner

These three tasks represent a bare-bones version of the application, but there are quite a few things that should also be added. I would eventually like to add: A file browser feature, connection type detection & large file warning, poor connection detection & retry popup, efficient results display, perhaps display of results as they are downloaded to take full advantage of the ‘real-time’ aspect of Rob’s website.

File Upload A Success (on a real phone!)

I finally got the upload proof-of-concept application to work on my Ion! As it turns out, the problem was actually the registration page for the university wireless network…

There is a redirect page the first time a new device is connected to the network, which requests some simple information like a name and email address. This page was apparently being loaded behind the scenes in my application, and giving me some strange errors (file IO errors for the website) in the ddms log. I likely would never have discovered that this was the problem, had I not opened up the actual web browser application, as was suggested by this post on Google’s Android Beginners.

Basically, the suggestion found there is to try to access your file upload page in the normal browser (even though that application disables file uploads!) to confirm that you can actually access the page from the phone. I know it saved me a ton of time, so I definitely recommend using this technique Smile

Android Debugging Protip & Mini Upload Update

I’ll start off with a very useful tip if you’re doing any Android development: use ddms and logcat!!! I heard this several times at Google I/O and even attended a talk about it, however, my work computer’s Eclipse doesn’t seem to want to let me use the DDMS perspective. Daniel’s works fine, and I found a work-around (close eclipse w/ emulator running, run ddms from terminal).

The DDMS tool allows you to view the phone’s (or emulator’s) file system, browse logs, and many other things. I find the logging aspect particularly useful though; not only can you browse for any messages where the OS thinks something is happening, you can actually insert your own debugging statements. You start to miss System.out.println pretty early on in Android development, because variable visibility in Eclipse’s debug mode is a little hokey (for some pretty complex reasons which are beyond me). However, the solution is of the form: Log.e(“MediaPlayer”,”Hey! I’m writing a statement out to Logcat at this point in the code!”);

I’m pretty sure MediaPlayer can be whatever you want too, but the snippet I found had that in it, and I haven’t tried to change it. (All it does is categorize the log messages)

As for my mini-update with the Upload code, it works again!!! The issue was with the file system, as I suspected. I’ve fixed the stupid things I did to it, and all is well. I can upload from emulator to octopussy flawlessly, but real phone to octopussy is still a no-go. I think it may have to do with internet permissions on the phone, but I’m still testing. I hope to blog some success on that front either later today or Monday!

Uploading Files from Android (progress update 2)

Right before I left the lab yesterday, I uploaded from the Android Emulator to Octopussy successfully. Daniel was here, he’s my witness.

Today, it doesn’t work, which is super awesome. It isn’t a matter of computer goblins or anything like that though, the Android Emulator was running a pseudo-SD card which I had manually pushed my test file onto. That is the only thing that changed from yesterday to today, so something has gone wrong with the file system. I’ve been making some attempts to get away from using the SD cards for my testing, because it is a bit unpredictable.

I wrote some code to generate files based on user input, but I’m getting the same crashes from that as I do from the SDcard version. I have a feeling it has something to do with file permissions, because when I browse the emulator’s file system with DDMS, the permissions on files I’ve pushed are all weird and different from other ones on the phone. I started having some issues yesterday with command line sdcard management, and I switched to direct code/DDMS options, which is probably why it is acting all weird.

Once again I’m really hoping I can get it up and running soon! It was really exciting to see it run successfully yesterday, and pretty disappointing to have it crash today 🙁

Uploading Files from Android a success! (locally)

Shortly after my last post I actually had a pretty major breakthrough with the upload proof of concept. I managed to get my Android application (running on the emulator) to upload a file to a server on my local machine. The PHP approach to the problem ended up being the way to go. I added a post to this thread which had been confusing me for about a week. Tons of people posted saying “it worked” or “this is the client side code that worked”, but nobody simultaneously posted the PHP and Client-side snippets which worked for them.

I found the XAMPP server application very helpful as I worked on doing the initial proof of concept. It creates a server on the localhost of your machine, so you can test web code without actually deploying it on a server (which is a whole other set of headaches-the ones I currently have!). One little gotcha that Carny helped me fix is that the permissions on the directory you want to upload to – they need to be such that your ‘server user’ has permissions to write to that directory (or just chmod 777 but be aware that this is NOT the good/secure way to do it – it works if you just need to test it and set it back afterwards though).

Another interesting thing I learned today was how to add a faux-SDCard to your android emulator. Just run the commands on that site in a terminal (from your tools directory). In order for the file upload to work, you need to manually push the file to your Android’s SD Card!

Also, please note (and I’ve forgotten it twice already since learning it in that tutorial…) that the directory path given in that link is NOT what you want to put as your own eclipse path. It looks deceptively like some super-secret google pathname, a G: drive, Android, SDK_Root, etc. However, this is just the path that the creator of the tutorial happened to have on his PC. You need to insert the path to the sdcard you create!

My next task will be to get the file upload working from a real Android phone to an actual server. I’ve been working on getting the uploader.php to run on Octopussy, but so far I’m getting errors. The PHP that I set up seems to be working fine though, which is nice to see. Hopefully by tomorrow I’ll have it all up and running!

Uploading Files from Android (progress update)

After I left the lab last night I realized I haven’t posted as to my activities in a while…

Basically, I’ve spent the past week+ researching various methods of achieving this task. I’ve looked into using CGI, JSP, and PHP for the server-side of the code. I had to scrap my CGI/JSP attempts as I couldn’t find any client side / server side code that meshed well (or tutorials to help me figure it out). I’ve been looking into a thread on using PHP, and it seems a lot more promising. I hope to have some results to show for all of this effort soon.

As a neat little side project (for when I need to take little breaks away from this upload thing), I’ve been working on that pseudo-tethering thing you can do with gphones and netbooks. I think it’d be useful for those of us with gphones to be able to (ab)use our 3G to get internet on our laptops where there isn’t any wifi. My last attempt at getting it to run crashed and burned though, so I’m going to go back to that one some other time.

Changing Android SDK Versions in Eclipse mid-development

First of all, let me say that you should definitely avoid being in a position to need this guide if at all possible. I would highly reccomend ignoring anything that tells you to use a version older than that absolute newest one possible, because you’ll probably end up doing a lot of work to fix it later. Should you end up in this unfortunate circumstance like I did, here is how you change your SDK version in Eclipse the ugly “I don’t actually know how to fix this but I can hack it” way:

1) Create a new project (you can’t name it the same as your old one, name it something similar). This time use the new SDK version.

2) Delete the following files out of your new project, and copy-paste the ones from your old project in their place: all src->’your.package.name’ files, all res->layout and res->value files, and finally, your Android manifest. Note that you may want to double check your Android manifest to see that the min SDK version variable updates itself. It did so for Daniel, but it may not for everyone.

3) Right click your old project, Refactor->Rename to old[ProjectName]. Right click your new project, Refactor->Rename to [ProjectName].

4) (Optional) if you’re using subclipse, it is now mad at you. You will still have a connection between your repository and what is new old[ProjectName]. To correct this, just do a commit of the newly made [ProjectName] directory, by going through all the steps associated with that. (Right-click, Team->Share Project, set up repository info, write commit comment etc). It will warn you that it needs to check out the most recent version, this should be fine since you likely have the most recent anyway, it does some magic and you get your pretty black asterisk back. Hurray!

Note that I am 100% sure all of this hackery is completely unncessary and that Eclipse has in it some magical function which would’ve just upgraded the SDK cleanly. However, I spent about an hour looking for said magic button and didn’t find it. In a pinch, you can use my foolish method to change your Android SDK version over!

GenomeSearch Demo Online!

I’ve uploaded a sneak peek of GenomeSearch in case anybody would like a look at the work we’re doing. To install it, first download it here, or use the QR code behind the read more cut (not working just yet, there are some issues with the .apk not being signed or something which prevent direct-to-phone installs), then follow the instructions here.What worked for me were the steps in the “How to Non-Market .Apk Application on Google Android G1 Phone” section. I connected my Ion to the Ubuntu PC I use in the lab via USB, typed adb install GenomeSearch.apk in a terminal window (from the correct directory), and it “just worked”. Note that I already have the SDK installed on this machine, had enabled applications from unknown sources, and that my Ion did not automatically mount itself as a USB storage device. Your mileage may vary on how much of that you already took care of for yourself!

A few words of warning for this version, beceause it is very alpha; if your internet connection is bad/nonexistant when you first launch the app, you will get a JSONParse error and the app won’t work (ever… I think). This is obviously a major cause for concern and a top priority for us at the moment. Assuming you have a decent connection and perform a valid search, there isn’t anything else that we know that will break the app. By all means though, when you find one, shoot Daniel or myself an email!

 

Continue reading →

EEEBuntu wireless gotcha & connecting an Android by USB

A few misc. Ubuntu and Android notes today:

1) I said a couple days back that I’d write up some EEEbuntu gotchas that I had a whole barrel of laughs with over the weekend. This one had me reformatting my EEEPC, so I think it qualifies. In the USB stick install, there is a nice convenient wifi notification on the top/right portion of the screen. When you actually install the OS, however, this isn’t present. I’m not good enough at linux (apparently) to figure out how to launch that wifi app, so this left me without a way to connect wirelessly. I did some googling and it turns out that you need to Right-click the menu bar at the top, and navigate to ‘add a notification’ (I can’t recall the exact path and I couldn’t google up any guides). NOTE: At this point you MUST restart EEEbuntu. You won’t get any confirmation that you added your notification successfully, and it will not show up until you restart. This is all you have to do to fix the wifi. (I won’t tell the whole story, but the basic jist of my reformat is that I sat there and added about 8 notification areas without rebooting, and when I tried to delete them I blew up the whole top menu bar and couldn’t get it back…)

2) Preparing your Android development environment to include real-phone testing! (This one is pretty cool once you get it working)

Essentially, just follow this guide, however there are a few little tricks. First of all, if you’re doing it on Ubuntu, all of those steps may not make it ‘just work’. As for which of the two strings to put in your rules file, Dapper and Gusty/Hardy are older version of Ubuntu, but string that worked for me was: SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”0bb4″, MODE=”0666″

Secondly, keep in mind you’re going to need to use the sudo command before just about every command related to this setup. (For those of you who, like me, aren’t well versed in linux, this gives you ‘root’ priveleges to do administrative stuff. If you don’t include it, the terminal will complain that you don’t have the rights to do things like save your rules file). My third tip is to restart your udev, which I found on the anddev.org forums. Use: sudo /etc/init.d/udev reload. Finally, use adb kill-server before you adb-devices if your device still doesn’t show up (but is connected). This was the magic trick that made it finally work for me (also from the same anddev.org forum post-that place is great).