Android under Subversion and possible compilation problems


If you decided to use Subversion as version control for your Android package is possible you could experiment some strange error during package compilation. These problems could appear only if you are using subversion under Linux and the old version of Tortoise under Windows ("old" mean before 1.7). 



Subversion is a very good tool in my opinion but clients have the "defect" to manage versioned file by creating an hidden folder called ".svn" in each folders of the project tree. Inside this folder there are a copy of all the files under control. In normal situation this mean only an additional space needed inside the storage but if you try to launch the compilation of Android (specially the latest version always more bigger) you could experiment some strange and unexplained error in different parts of compilation steps. Basically Android package is composed by a lot of scripts and code for compile all the required parts and assemble all together. Some of these codes, however, simply collect all the files present into the folders tree passed and make the operation requested. Using subversion have the consequence that also the files inside .svn folder are collected and, for some folders of Android package, we are talking about a big number of files that, in practice, are doubled. The consequence of this "abnormal" number of files collected are usually some crash of the tools used during compilation process mainly for memory full. This post cover the version of Android 4.2.2 where I found two patches that allow to bring off the compilation. However is possible you can find some other problems depends on the machine you use (basically quantity of ram) of the Android version you are compiling.

The first issue encountered was relative to compilation of documentation. Inside this file:

myandroid/external/doclava/src/com/google/doclava/Doclava.java

is there this function need for collect all the folders inside a specific tree in a recursive mode. As you can see the function assume to get all the subfolders available included .svn folders as well. This increase too much the number of files to include into the compilation and the task simply crash.

private static void writeDirectory(File dir, String relative, JSilver js) {
    File[] files = dir.listFiles();
    int i, count = files.length;
    for (i = 0; i < count; i++) {
      File f = files[i];
      if (f.isFile()) {
        String templ = relative + f.getName();
        int len = templ.length();
        if (len > 3 && ".cs".equals(templ.substring(len - 3))) {
          Data data = makeHDF();
          String filename = templ.substring(0, len - 3) + htmlExtension;
          ClearPage.write(data, templ, filename, js);
        } else if (len > 3 && ".jd".equals(templ.substring(len - 3))) {
          String filename = templ.substring(0, len - 3) + htmlExtension;
          DocFile.writePage(f.getAbsolutePath(), relative, filename);
        } else {
          ClearPage.copyFile(f, templ);
        }
      } else if (f.isDirectory()) {
        writeDirectory(f, relative + f.getName() + "/", js);
      }
    }
  }

The patch to apply into the code is showed in red. Basically this addition exclude all the .svn folders from the inclusion.

private static void writeDirectory(File dir, String relative, JSilver js) {
    File[] files = dir.listFiles();
    int i, count = files.length;
    for (i = 0; i < count; i++) {
      File f = files[i];
      if (f.isFile()) {
        String templ = relative + f.getName();
        int len = templ.length();
        if (len > 3 && ".cs".equals(templ.substring(len - 3))) {
          Data data = makeHDF();
          String filename = templ.substring(0, len - 3) + htmlExtension;
          ClearPage.write(data, templ, filename, js);
        } else if (len > 3 && ".jd".equals(templ.substring(len - 3))) {
          String filename = templ.substring(0, len - 3) + htmlExtension;
          DocFile.writePage(f.getAbsolutePath(), relative, filename);
        } else {
          ClearPage.copyFile(f, templ);
        }
      } else if (f.isDirectory() && f.getName().equals(".svn") == false) {
        writeDirectory(f, relative + f.getName() + "/", js);
      }
    }
  }

The second issue found was connected to the creation of recovery.img file. Also in this case the "raw" copy of all the folders needed for the recovery process include the .svn folders as well and this cause the image file to become too big. This generate an error and stop of compilation process. In this case the file to patch is the following:

myandroid/build/core/Makefile

Inside this file you need to find the following part:

$(hide) cp $(RECOVERY_INSTALL_OTA_KEYS) $(TARGET_RECOVERY_ROOT_OUT)/res/keys
$(hide) cat $(INSTALLED_DEFAULT_PROP_TARGET) $(recovery_build_prop) \
        > $(TARGET_RECOVERY_ROOT_OUT)/default.prop
$(hide) $(MKBOOTFS) $(TARGET_RECOVERY_ROOT_OUT) | $(MINIGZIP) > $(recovery_ramdisk)
$(hide) $(MKBOOTIMG) $(INTERNAL_RECOVERYIMAGE_ARGS) $(BOARD_MKBOOTIMG_ARGS) --output $@
$(hide) $(call assert-max-image-size,$@,$(BOARD_RECOVERYIMAGE_PARTITION_SIZE),raw)
@echo ----- Made recovery image: $@ --------

and add the line in red as follow:

$(hide) cp $(RECOVERY_INSTALL_OTA_KEYS) $(TARGET_RECOVERY_ROOT_OUT)/res/keys
$(hide) cat $(INSTALLED_DEFAULT_PROP_TARGET) $(recovery_build_prop) \
        > $(TARGET_RECOVERY_ROOT_OUT)/default.prop
$(hide) if [ -d $(TARGET_RECOVERY_OUT) ]; then find $(TARGET_RECOVERY_OUT) -name '*.svn' | xargs rm -rf; fi
$(hide) $(MKBOOTFS) $(TARGET_RECOVERY_ROOT_OUT) | $(MINIGZIP) > $(recovery_ramdisk)
$(hide) $(MKBOOTIMG) $(INTERNAL_RECOVERYIMAGE_ARGS) $(BOARD_MKBOOTIMG_ARGS) --output $@
$(hide) $(call assert-max-image-size,$@,$(BOARD_RECOVERYIMAGE_PARTITION_SIZE),raw)
@echo ----- Made recovery image: $@ --------

This will force the cancellation of .svn folders before creation of .img file. Please, note the use of the tool 'xargs' that I need to have in your system for allow the patch to work well.

These are the two patches I needed to apply for allow me to compile android 4.2.2 in my machine. As already said before is very probably next versions of android (in the same condition of use svn and same machine configuration) will require additional efforts (I hope no obviously). Anyway I hope these short suggestions will help some other people in my same condition to save a bit of time. ^_^

Comments

Popular posts from this blog

Access GPIO from Linux user space

Android: adb push and read-only file system error

Tree in SQL database: The Nested Set Model