my visual code settings config

  • wordwrap
  • python formatter
  • c,c++ formatter(clang)

“editor.wordWrap”: “on”,
“editor.wrappingIndent”: “indent”
“editor.formatOnSave”: false,
“editor.formatOnType”: true,
“clang-format.executable”: “/usr/bin/clang-format-3.9”


spatial transformer networks

encountered while reading “STN-OCR: A Single Neural Network for Text Detection and Text Recognition” which adopted spatial transformer networks.

This video is very clear in understanding how it works. Although I didn’t fully understand the interpolation equations, the other parts were clear. And at the end of the video, it briefly compares the spatial transformer with deformable convolutional networks which is interesting.


Notes on parsing and compiling procedure in AOSP

Here is a drawio diagram[png version] that shows the flow of how file is parsed and the build command is executed.

Mind you, this is a note taken while I was trying to link the su binary with which is newly introduced as a part of my modification.

  • suprisingly, the LOCAL_SHARED_LIBRARIES modifier didn’t seem to actually do anything…

  • the gcc command is located inside /build/core/ file. Not sure when this is executed. If you want to see the actual gcc command, you should tweak it toi print out the command.
  • the linking command is also located inside /build/core/ file. Not sure when this is executed.

  • In the linking command, I cannot find a flow where LOCAL_SHARED_LIBRARIES values are related. On the other hand I have found a flow where LOCAL_LDFLAGS is related.

  • LOCAL_LDDIRS by default directs to the /out/.../intermediates/lib directory. If I have already built the beforehand, the original copy will be located under this directory.
  • Adding -lcap to the LOCAL_LDFLAGS is enough to let the linker know that it should link the as well. It is normal to omit the lib characters at the front of

adding shared library in ``

Linking a shared library in

This document is based on my experience of modifying su binary.

Working with for C source files

Sharing my experiences of trying to build su binary which a small modification of my own: linking with shared library. Assumes that I already have built.

At first it was confusing because I didn’t know which options to modify in my file.

Initially I thought that I had to refer to libcap through the LOCAL_SHARED_LIBRARIES option. However, this was not the case. The additions that I added were:

LOCAL_LDFLAGS:= -lcap -fPIE -pie
LOCAL_C_INCLUDES += external/libcap-for-Android-master/libcap/include

I am actually referring to the through the -lcap option in LOCAL_LDFLAGS. the pie, PIE is added in order to make the output as a position independent executable. I may have overwritten things about pie here. Perhaps it would have been enough to specify pie either in LOCAL_CFLAGS or LOCAL_LDFLAGS. But I haven’t tested that part. But hey, specifying it in both options seems like a safe bet.

If I don’t specify the PIE related flags, then the built executable will cause the following error when executed.

error: only position independent executables (PIE) are supported.

Note that I have also added the path to the header files of libcap in LOCAL_C_INCLUDES. This is necessary for the su.c code to refer to the libcap header files.

Working with for C++ source files

I also had to link the with Zygote source code. Linking the even for cpp source code’s was not so different.

LOCAL_LDFLAGS +=  -lcap -fPIE -pie
LOCAL_C_INCLUDES += external/libcap-for-Android-master/libcap/include

“Unsupported major.minor version 52.0” error when gradle build

when I tried to build a specific module only by using /gradlew command, it gave me the error

> java.lang.UnsupportedClassVersionError: com/android/build/gradle/AppPlugin : Unsupported major.minor version 52.0

It usually worked but suddenly it didn’t. I noticed that I have changed the default java, javac to jdk7 from jdk8. I reset both tool to jdk8 with update-alternatives and it now works fine.