Hold It – Problems

To keep everything short (I had a lot of problems from the build last time, and this is just what I’ve found thus far), to sum.

  1. You need 64 bit version of Linux, and not 32 bit.
  2. Virtual machines require a BIOS setting to run 64 bit (Part of number 1).
  3. On a virtual machine, memory is limited.  Therefore, it won’t build correctly all the time.
  4. Mint vs Ubuntu? Which to use?
  5. What do I do when it’s all downloaded and built?
  6. envsetup.sh, important, but when?
  7. I have it downloaded, I can see the img files, but it still complains when I do this.

64 bit != 32 bit

I received the following error:

/bin/bash: prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/bin/arm-linux-androideabi-gcc: cannot execute binary file

So  basically, you need to use 64 bit for Jelly Bean.  And also, from what I’ve read (Not a lot, so not positive on this), also Ice Cream requires 64 bit to build also.

Virtual with 64 bit

My error:

VT-x/AMD-V hardware acceleration has been enabled, but is not operational. Your 64-bit guest will fail to detect a 64-bit CPU and will not be able to boot.

Please ensure that you have enabled VT-x/AMD-V properly in the BIOS of your host computer.

Note, I do use Virtual Box, and this was a simple solution (Even though it requires a computer restart, which those who know me know I hate restarting my computer).  Basically go in to BIOS, go to advanced, and enable the Virtualization.

-j4 Is Okay, Not Too Much

So, I was under the impression that the number you put after the 4 didn’t mean much.  However, I was wrong; wrong wrong wrong.  So basically, when I tried to build/make from source with -j4, it would conflict, or otherwise, not build a system.img (It did do the ramdisk.img and userdata.img).  So, I read a bit online, and it seemed that not many people had this problem.  I did however see someone mention that one of the errors that I came across often (When I built, I would do:

make -j# 2> ERROR_LOG.txt

so I’d get all my errors that occured and I can check on it later on rather than trying to catch glimpses in the hundred thousand lines or so) was caused by not having enough RAM.  More significantly, someone wasn’t able to successfully build Android with -j4 on a machine with two gigs of RAM.  Surprise surprise, I gave my virtual two gigs of RAM.  So I changed this to -j1, and it finished, and from here, I saw that my img files were created.

Mint or Ubuntu

This isn’t about what’s better.  As you might have read previously, I decided to use Mint.  Why? It’s less bloated, it has more dependencies at the start (I understand this is a bit contradictory as bloated == more dependencies, but just ignore this flaw), and in my opinion, works better.  However, after reading a lot of posts, everyone built the source using Ubuntu, so I decided to deal with the Unity bar and everything else that’s not needed, and use it.  The reason I mention this, it could have been a factor in why it wasn’t working.

Now What?

So now the source was good, I have my .img’s, and everything is going all well and dandy.  Hard to actually find much on what to do once you’re done, and a likely reason, if we look at the pages, we see three lines on starting the emulator, of which, only one word in those lines is what you really need, emulator.

I start up my emulator (But I can’t, look at next section for that), and I get an error, surprise.

emulator: ERROR: You did not specify a virtual device name, and the system
directory could not be found.

If you are an Android SDK user, please use '@<name>' or '-avd <name>'
to start a given virtual device (see -help-avd for details).

Otherwise, follow the instructions in -help-disk-images to start the emulator

So, can’t be that easy.  I look around, and see that I need to specify the .img files.  So I try it:

out/host/linux-x86/bin/emulator -sysdir out/target/product/generic/ -system out/target/product/generic/system.img -ramdisk out/target/product/generic/ramdisk.img -data out/target/product/generic/userdata.img -kernel prebuilt/android-arm/kernel/kernel-qemu -sdcard sdcard.img -skindir sdk/emulator/skins -skin WVGA800 -scale 0.7 -memory 512 -partition-size 1024

And my kernel doesn’t work, it’s not there, doesn’t exist.  So I decide to build it separately, but first…

Envsetup

So, I feel this file is a bit misunderstood.  In that, I run it at the begining of the build, then I do the make, and all good.  I then do ./emulator, doesn’t work.  Doesn’t exist.  Then I have to rerun the envsetup line:

source build/envsetup.sh


Now it works, good.  So remember, do this before and after!  Also, a possible problem.  If you have the SDK downloaded and set up, when doing ./emulator, it could be running the SDK, and NOT the built version.  I didn't have this problem, but thought of it while working.

Still Complaining – Kernel Panic

So, finally, the kernel.  It won’t work. I don’t know why.  I just want to do my weekly posts.  Also, I have some ideas:

  1. Build it seprately
  2. Try a pre-made kernel
  3. Build Generic
  4. Build Goldfish
  5. Re-make whole thing from scratch using -j1

And Alas I Am Done

So that’s it for now.  Outside of this project, I’ve gotten some done with my other project.  I’ll hopefully have something to show for it in two weeks.  Going to be a busy weekend, so might not be able to work on my side projects too much.

Downloading and Building Jelly Bean

Obviously the first step to my assignment was to download and build Jelly Bean.

Problems

1.  Permissions on certain machines.

2. Which lead to a problem with Java 1.7 is installed, and you need 1.6 in order to build and run the make.

3.  The time it takes for everything to download is slow.  I mean, it took 10+ hours and multiple repo sync’s.

Permissions on Machines

Obviously the school wouldn’t give me admin rights on the computers, however, I just needed to run (I believe) only one command and I could have finished up the make process on their machines.  The problem is, I couldn’t actually run “sudo update-alternatives –config java” to change from 1.7 to 1.6 (More on that later).  Further, a lot of what I did do up until the actual download (That went surprisingly smoothly on the machine in the lab) seemed a bit backwards because I had to find workarounds between security setings.  By the end after about three hours, I gave up on figuring out the Java problem and decided I’d try it all on a virtual the next day and see if I could get it to work on my own machine.

I ended up using Linux Mint as it’s based on Ubuntu, has more of the programs needed (Except for I found two specifically [bison and flex] and decided to just run their Ubuntu 12.04 lines:

sudo apt-get install git-core gnupg flex bison gperf build-essential \
  zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \
  libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \
  libgl1-mesa-dev g++-multilib mingw32 openjdk-6-jdk tofrodos \
  python-markdown libxml2-utils xsltproc zlib1g-dev:i386

This worked perfectly fine on my virtual, even without the following linker line, I assume that the machine already had libgl set up, so no biggy.

Anyways, after this (And as I type this out), the build is running with the make.  This brings a smaller problem, as to what number to put after the j in the “make -j#” command.  I personally used 4 as it’s on a virtual and I didn’t want to really slow down my computer.  But regardless, it’s building right now, so good!

Java 1.7 can not be used for the Jelly Bean build, Java 1.6 is needed

So this was an odd problem to me (Makes sense, with some methods being deprecated and from the warning message it actually used Java 1.5, not 1.6, but 1.6 was backwards compatible enough to work), and it is what ultimately made me use a virtual machine rather than doing it in the lab.  The general solution was to just download the binary file, run, and do the update alternatives snippet (See above).  This worked, however a little tip for future reference, you need to actually put the .bin in the /usr/bin and then chmod and execute it there (This allows it to be in your path).  You can then do an update.  However, I highly recomend following this post here by codingchyne. It’s what I followed, worked perfect. After this, it already set up the Java 1.6, so no need for the update alternatives.

Speed

So, this is where I feel a lot of newbies might be a bit surprised, and Dr. Mateti actually warned me about to begin with.  This process takes… Long.  As in, it took my 8-15 hours to actually update the repository.  This is on about a decent connection.  However, in the labs, I was getting a very fast connection (Friday evening, Saturday afternoon), so it only took about an hour there.

Now the build.  As I said earlier, I already started the build.  It’s been going at it for about an hour now, so obviously this is going to take some time.  I use -j4, which means I’m using 4 threads on my PC to build this.  In the lab, I want to try this again using -j32 and see if it really will finish this up in about two hours.  Lastly, Dr. Mateti brought up that he wants the system to allow distributed computing, and I’d love to see how that works and perhaps push this to -j128 or some other amount that would make it build in only minutes.  Maybe later on I can show a graph of speeds to thread numbers.

So what now?

Obviously, the build has to finish, and hopefully without errors.  If it does, then awesome.  If not, then no big deal, I have to talk to Dr. Mateti and see if I can get the Java versions switched so I can do this on there, and that’s where I’ll be doing most of my work.  After this, I believe that I’ll be working on pruning, or as I’m looking it up, kernel work (Which I’m actually really interested in).  This is probably going to take most of my time, and hopefully I can post updates on what I’m doing to the kernel and why.  We’ll see though, the build might not even work, then we’re back at step one!

Hello, World!

I’m starting out with a research position as of now with a professor in order to learn more and pretty much obtain real experience rather than just a normal class room setting.

Basically, the subject matter is going to be computer science, along with mobile security.  Mobile, meaning Android, means my first task is to build a ROM.  The end goal is to actually produce a fully functional ROM that others may install on their own machine.  In this blog, I’ll be posting updates whenever I do work on the project.  As I’m still in school, I can’t dedicate a lot of time to this, however my goal is to upkeep ten hours a week on this project, with most of my work being done on weekends.  I’ll try to update every Monday and possible Wednesday or Thursday (Depending on when I work).  Hopefully all works out, and this becomes something.

 

I’ll also be posting about food, and what I cook.  Being in college, I won’t be making fancy schmancy meals, but I’ll be making some delicious stuff as time goes on.  I love to cook, and listen to music, and the great thing is, cooking and listening music can be done together! Just like programming and music ;).  Things always work out!

Lastly, I do small mini-projects on my own.  As of now, I’m creating two Android apps (Both of which I’ll post about and problems that occurred during development) and hopefully they’ll get done within the school year (That’s the plan).  The plan is, weekends are a mix day, do both my own projects and research stuff, where-as through the week I do more of the research stuff and app development when I’m free and need a break.  Sort-a my personal 20% project. Last, I hope to start learning Go/golang.