Tag Archives: android

Wow, Technology.

It’s days like this that I wish so damn much that I could go to events such as CES (Consumer Electronics Show) 2011, going on right now. One day, I swear I’ll go. Really.

I was just reading my usual roundup of tech blogs for the day and couldn’t help but realize that I got just about 217 items just in the past 24 hours regarding CES and all the ridiculously cool new technology they’re featuring there. Take for example Sony’s 27(!) new HDTVs, many of which are 3D-enabled and all of which are incredibly elegant-looking. Or Samsung’s new razor-thin televisions (seriously, how much thinner can they make it?). Or the tons of new cameras and camcorders, now at a phase where 10MP is just barely making it (yes, I know pixel quantity is not everything, but it does count for something). Or like the dozens and dozens and dozens of new phones featured today. Like that new Motorola Droid Bionic with 1080p output. Seriously? Full HD output from a freaking phone?! Wow. (I’m looking at you, rate-limited HDMI-output Evo).

And the elephant in the room for me, the announcement of Android 3.0, or Honeycomb, for tablets. To be completely honest, I’m not totally quite into this tablet frenzy that’s been stirred up in the past few months with everyone and their mother announcing a new tablet, but if there’s anything like Honeycomb running on it, I might just be interested. Arguably, the Galaxy Tab running Froyo is the best Android tablet on the market (are there others? Yes there are. Very few). But I played with one and felt like it was a bit of a letdown. For one, it was just too laggy for my taste and the cosmetic changes that made it distinctive from a large phone (iPad?) were too minimal. However, the new sneak peak of Honeycomb on the Google Mobile blog today is pretty impressive. Of course the video is extremely and almost annoyingly flashy enough to be taken straight out of Tron, but it gave a pretty neat exposition into how Android will look on a completely different form factor. I entirely disagree with Apple’s UX choice to literally scale up the exact iPhone interface for the iPad. A dedicated OS for specifically that form factor is the right idea and I think Honeycomb is looking good so far.

It also shows the power of Android at extensibility to different kinds of hardware. About a month back, Google so kindly sent me a free Google TV device (the Logitech Revue) for my contributions to Google Code and I got around to playing with it. Initially, I thought this was just a simple, standalone OS/firmware but quickly realized that it was actually Android 2.1. When I played around with the interface, I actually didn’t believe it until I saw the version number on the device itself. Needless to say, it looked and felt entirely different (although imperfect in a couple of ways). Now we will soon have a version of Android designed specifically for tablets. Which brings me to the next question. Where does Google Chrome OS play into all of this? From whatever I’ve read, there seems to be a bit of ideological gap between the Google Chrome OS team and the Android team as far as objectives. Yes, they’re different but they’re also getting closer and closer to the same types of hardware. I could definitely seen Chrome OS running on a tablet device (since a fair assumption is that a portable device like that will be always connected to the Internet). So eventually one is going to win. Now if only I got one of those CR-48 netbooks, I might be able to pick a side fairly..

Leave a comment

Posted by on January 6, 2011 in Uncategorized


Tags: , , , , , , , , , ,

So What’s New?

It’s been a few weeks since I last updated this with a real post, so here it is.

I finished my research for the summer a few weeks back. I’m probably going to continue it again once the school year starts, but I decided I wanted at least some time to work on different things during the summer as well as catch a break. At the time that I ended, most of the major tasks assigned to me had been completed. That is, all but one program module had be written and polished and most of it had been used to generate at least first-run data. I can’t go very much into the details about what the modules did exactly, but the broad concepts are the same: write software that parses the millions of lines of log data efficiently and offers a way to gain greater insight into it

Despite the fact that some of this code will only be run once, I decided to nevertheless invest the time into making it nice and modular, etc. This is a time when I truly saw the importance of good code design. Code that I had written at the beginning of my research period, about two months back, really does look alien if you’ve lost touch with it. Among the people I was working with, I started first, so there was no code to start off from. I ended up making up my own standards for how to run certain modules – a certain combination of command-line flags and stdin/stdout redirects and all. In this process, of course a lot changed and later parameter paradigms greatly differed from the early ones. At some point, I realized that it was a major pain to remember how to run each program so rewrote lots of my previous code to accommodate for that. For example, there was a certain little script that I used to run the same program on many log files over a period of time. This little script started off first as an inline bit of Bash fu that I could start in the background and let it run through the day and into the night if necessary. It then evolved into a script of its own, became more standardized to accept the executable and as my knowledge of Bash improved, was written more efficiently. In fact, it even went on to become so commonly used that I included it in nearly module I wrote. The same goes for implementations of commonly used data structures – these were soon put in a common lib/ folder and linked to from various modules. Even commonly used functions that mapped to all elements of those data structures were placed in a specials utils.c file. Another useful little macro directive that I used to help with (possibly careless, irresponsible, and brash) memory management was a wrapper on GNU free that was double-free safe. So, every single free() call was replaced with nxfree() with the following implementation:

#include <stdlib.h>

 * Convenient wrapper for nfree().
#define nxfree(s) nfree((void**)&s)

 * Wrapper for GNU free. Checks for NULL and sets pointer to NULL
 * after freeing. Avoids accidental double frees.
#define nfree(p) {if(*(p)) free(*(p)); *(p) = NULL;}

So, pretty simple, but useful. I ended up using many such little snippets of code to make my life easier. In addition, I also rewrote my original Makefiles to be more modular. I ended up creating a standard template for all Makefiles, with only trivial changes to customize it for the module in question. The template is generic enough for use pretty much anywhere gcc works and is below:

CC = gcc
CFLAGS = -Wall
CDBGFLAGS = -Wall -g

LIBOBJS = ../../lib/*.o   #Shared Library Code Path

TARGET = <Release Target Name>
DBGTARGET = <Debug Target Name>

OBJS = <All Source Files Names, with .o Extensions>
DBGOBJS = <All Source Files Names, with Dbg.o Extensions>

        $(CC) -o $@ $^ $(CFLAGS) $(LIBS)

        $(CC) -o $@ $^ $(CDBGFLAGS) $(LIBS)

%.o : %.c
        $(CC) -c -o $@ $< $(CFLAGS)

%Dbg.o : %.c
        $(CC) -c -o $@ $< $(CDBGFLAGS)

all: $(TARGET)

debug : $(DBGTARGET)

        rm -f $(TARGET) $(DBGTARGET) $(OBJS) $(DBGOBJS)

        make clean && rm -f *~

Now after research was done, I got a bit more time to work on the Mozilla Crowdsourcing project I’ve mentioned before. We completed Phase 1 a few weeks back (check the Mozilla Labs’ blog for all sub-teams findings and here for just my sub-team’s). After that, we got started on Phase 2, which consists of designing a Design Challenge using our findings that took into account the various things we picked up along the way. The final result of the Crowdsourcing team’s designs will eventually replace the current model of the Lab’s Design Challenges. Last Sunday was the deadline for that and our sub-team had a pretty concrete set of guidelines. These will soon be written up and fleshed out into a blog post. Once this stage is complete, we will take our three sub-teams’ designs and combine them into one, which will be our official proposal. Then come the actual implementation of the proposal, which may include some actual development and/or extension of existing software. I’ll speak more of this as it comes up in the next few weeks.

Apart from that, I’m also just doing my usual things, such as testings and bug reporting for Minefield (Firefox Panorama officially ROCKS) and Chrome. I also decided on one Saturday to re-root my Droid from scratch since a couple things needed fixing. I was unable to install updates for certain applications such as Google Maps, doubleTwist, WordPress, and Facebook for Android. And Chrome-to-Phone was not working correctly either. In addition to the fact that my phone was still feeling rather sluggish. So, after many hours of figuring out what the hell was going on, I decided to format everything, install ClockworkMod Recovery, and flash a custom rooted Froyo ROM. This was actually the FRG01B build of Froyo, which replaced the earlier update that I had previously installed on my Droid. I also got SetCPU (I’m an xda-developers member, so I got the APK from there – if I continue using it, I’m going to consider donating to the developer). So far, my experience with that has been pretty much flawless. I set up a few failsafe profiles just to prevent spontaneous combustion of my device and the homescreen widget works great. I used a 1GHz kernel again and am currently running at a max of 1000MHz and a min of 500MHz on “performance” mode. My CPU temperature usually hovers around 33 to 35 degrees C, which is pretty normal and the phone is stable. Obviously, it feels a lot more snappy with the overclocked kernel and runs pretty smoothly on most things I’ve thrown at it. I’m pretty happy with that. There actually is another minor upgrade that was released after FRG01B that basically just enabled the download of the official Adobe Flash 10.1. Except that that build hasn’t been rooted yet and I side-loaded official 10.1 APK anyway, so I chose not to upgrade for now at least. From all accounts, the newer version is the last of the Froyo upgrade process for Droid and does NOT add any new features.

Well that’s what’s keeping me busy right now. I’ve got about two weeks before college starts again, so I’m prepping myself as necessary for that. I expect this year to be pretty challenging again, but at least I know I will enjoy the classes even more now, having had more flexibility in choosing them. In the meantime, I think I’ll finally take a look at Google Code University and see what they offer – been wanting to do that for quite a while.

Leave a comment

Posted by on September 1, 2010 in Uncategorized


Tags: , , , , , , , , , , , , ,

Rooted Droid + Android 2.2

So I finally took the leap and rooted my Motorola Droid!

It was a completely painless procedure. My main goal was in order to get full access to my own phone (which I think should be a given, since the device is mine..). Then, I got a little zealous and decided to take it a bit further. I figured hell, why not see what flashing Froyo will do? So I did. And that was painless too. The main thing that was stopping me from doing this a long while ago was because last I had heard that WiFi was not working. This was a showstopper for me because since I do not have a Verizon subscription, I only use my Droid over WiFi. However, after looking at a tutorial provided by the friendly guys at The Unlockr, I was up in no time.

For the record, the exact tutorial that I used was this one. I was originally going to write up my own set of instructions giving my personal experience, but the tutorial was so clearly written that I literally just followed it exactly and everything worked nicely. A couple of notes to point out:

  • Be patient. Pretty much the only way you can mess this is up is if you jump past important instructions, stop without completing the procedure, or get tired of waiting for something to load and turn off your phone/pull out the battery/feed it to your rabid armadillo, etc.
  • Rooting will destroy all your data/apps on the phone, although files on your sdcard will remain, such as photos, music, etc.
  • I did not re-activate my phone after rooting, although it will ask you to. You can bypass that if you want by looking below how to skip the tutorial, or by hitting the Home button if that works).
  • I got one message when I was rooting the phone (the first part) saying that a certain file did not exist on my sdcard (I forget the exact name for it now, sorry!). I safely ignored the message and continued and there was no issue.
  • I got a few more warning messages during the flashing of the new kernel. These too I was able to safely ignore.
  • I used the 1GHz kernel, so technically I overclocked my phone a bit. Since this is not my primary device, battery life is not too much of an issue when compared to performance, so I decided to go with it. I’m not badass enough to try the 1.25GHz kernel; I’ll leave that to someone handling their phone with flame-retardant gloves.
  • Even with the 1GHz kernel, the phone is pretty stable so far and I haven’t had any issues (only had it for an hour or so though, so remember that).
  • When the phone first reboots after flashing Froyo, it takes all eternity. Again, keep your rabid armadillo away, it will load correctly (hopefully..).
  • In order to skip past the Android tutorial, touch the four corners of the screen clockwise, starting with the top-left. This is a cool tip I picked up from a couple videos on YouTube.
  • After the first load, Android is very slow. This confused me for a while until I realized that it takes a bit of time for the JIT module to warm up. Once the caches were hot, performance greatly increased. This took about 5-10 minutes for me. Menus went from stuttering to buttery smooth. Sweet!
  • I downloaded Adobe Flash: it eats two batteries for breakfast, but works pretty nicely (for a phone).  It’s actually pretty cool to see Flash video load in-page. But for your sake, please set Plugins to load On-Demand or your phone will suck at battery life.
  • I was able to get Flash to work on the NYTimes homepage and it loaded fairly well. Audio was less than perfect and audio was a bit jaggy, but again, it’s better than nothing.
  • Droid has five home screens! Cool. Not sure if this is just something about my custom ROM or if the official version will have it as well. The other advertised aspects of Froyo including improved universal search, new dock bar, 3D application drawer, etc. are all there too.
  • You still have root access after flashing 2.2, I believe.

And so yup, that’s an overview of my thoughts on it. It was really quite painless. The longest step was waiting for Droid 2.o.1 firmware to download (it’s like 130MB) over Megaupload speeds. Remember, you have to downgrade to 2.0.1 and then root and then go to 2.2. The process was made incredibly straightforward and simple, so I need to thank all of the dozens of devs and modders from all over the Internet including the Android Forums, xda-developers forum, and The Unlockr. You guys really make my day. Thanks!


Posted by on July 15, 2010 in Uncategorized


Tags: , , , , , ,

Motorola Droid, iPhone 3GS, iPhone 4

Okay so the deal is that I bought an iPhone 3GS last year after wanting it for a long time and then I registered for Google I/O and I got a free Droid (couldn’t actually make it to the conference because of a computer science final… so I didn’t get the free HTC Evo) and then now I ordered and got an iPhone 4 so that’s how I have three phones. I’m going to be selling my 3GS in a few days time and I use my iPhone 4 primarily (seeing as I don’t have service on my Droid). But I wanted to give my impression of them all since I’ve had a chance to play with all three. More importantly, I’ve had a chance to interact with both iOS 4 and Android 2.1 (and hopefully soon 2.2…) and want to give my impressions on that too.

To put it very plainly, iPhone 4 currently is the winner in my opinion. There are a lot of reasons for this but I don’t believe that’s any longer impossibly far ahead of Android. With the announcement of Froyo at this year’s I/O, I expect that the coming months will bring about some changes to the mobile landscape. Already, there is talk and rumors about Gingerbread, the next version of Android, so it is comforting to know that this is not something that’s going to die away soon. But there are certainly some issues across various levels of the Android experience that are potentially fatal.

In its current state, 2.1 Android is not too shabby. The Droid is the first Android device I’ve owned and I can easily tell that it is far better than the first iteration of devices both from a hardware and software perspective. As expected, it takes a few cycles for any upcoming competitor to catch up to speed, but it is important to know when to actually stop giving this benefit of the doubt. And I believe that time is now.

We’ve been through a few software releases and with Froyo and onwards, Android needs to start looking more like a comprehensive mobile operating system for a variety of users (not just us geeks who can forgive the occasional mishaps and difficulties) that can stand on its own. It is one thing to gain the interest of the hacker community and quite another to gain the interest of the most average user.

To be short, Android needs more polish in this respect. I know that the developers are working particularly on UX for Gingerbread but I still think that’s a bit late. To be clear, 2.1 isn’t ugly on the whole and is definitely useable, but the differences are more apparent when compared with iOS 3.x or 4.

At this point, the glaring omissions have mostly been taken care of and the more stubtle points need some attention. For one, I just recently discovered that the Droid has no spellcheck for the hardware keyboard. While this may be a conscious decision, I can’t say I agree with it at all. The truth is that sticking firmly to philosophies may work great if you’re writing the Linux kernel, but maybe not so for a front-end feature. Our phones should fit our needs and expectations, which are neither simple nor static. If users are familiar with and expect spellcheck for hardware keyboards, it better be there. I believe the success of an end-user product is inversely proportional to the thickness of the User Manual. In the same vein, Android must recognize that users have already picked up certain behaviors from using competitors’ product – that’s a “skill” that should be taken advantage of. In this respect, I like that Android has kept with many of the sweeping unofficial standards. This gives it an edge over competitors who aim to reteach user interaction.

Being a Linux user, I guess I have a natural tendency to like Android. After all, its guts are very much Linux and you can see the characteristics of Linux in a lot of places. I love the true multitasking and the approach that notifications have taken. I like that my homescreen is almost desktop-like and can provide me with customizable and dynamic information, aka widgets. But the UI needs some help. Consistency is important and in some ways Android currently fails that.

The Market is one place that needs the most help. The bag icon to get to the homepage of the Market is completely unintuitive. The loading bars for app updates are jerky and inconsistent. The color scheme is quite ugly too. Most icons are very blurry even when their actual icons when installed are sharp. Not all apps have screenshots. Perhaps most discouraging is that there are all kinds of apps that have copyrighted icons or content.

This last point is important because it represents a larger issue that needs to be handled. I’m just as much in support of “free as in freedom” as the next FOSS guy, but something needs to be done about the quality of apps and the content of apps that break federal copyright laws. For the first point, it is again a consistency issue. There’s a reason iOS 4 looks so good – the apps are clean and in tune with the design principles laid down by the OS. In Android, many apps outside the ones by large organizations honestly look quite bad. Misaligned text boxes and ill-placed dropdowns and radio buttons evoke a particularly strong GeoCities-esque feel. The objective of a drag-and-drop UI should be to not betray that it is so. Again, the user should never need to learn how to use an app. And this is of particular importance because individual developers are of great value in this open system. We need to make sure all apps make our OS look good. And for the second issue, I’m starting to wonder if some sort of approval process might be a good idea – if at least to keep out the malicious and illegal content. Surely Google can do this – Apple has done so for every one of its apps and there are twice as many of those. There needs to be more accountability in this respect and more incentive to stick to the design principles. Perhaps a section specficially to highlight great interfaces. The point is that we can’t make this a functional collaborative system unless we actually collaborate.

The next issue is fragmentation. This is well-known and progress has already made on this front. I support the regular updates but delivery needs to be sped up (Google, us Droid owners want Froyo already!). For this aspect, Android’s greatest strength is its weakness. The fact that the theme can be so customized causes huge delays for phones with Sense, Blur, etc. That process needs to be streamlined. Further, new versions need to stop making so many older phones obselete! This of course is not just Google’s responsibility. Hopefully these issues will get ironed out with the next release.

I know that’s a lot of criticism, but it is just that I’ve skipped over all the good stuff, which greatly exceeds the length of this list. I really like Android and want more than anything to see it do great. And I think it will.


Posted by on July 7, 2010 in Uncategorized


Tags: , ,