Have You Got What It Takes To Code Android Apps Using Assembly?

Do you have a rooted Android device and a computer running Linux? If so, you’re already on your way to coding for Android in Assembly. Android devices use ARM processors, and [Vikram] makes the argument that ARM provides the least-complicated Assembly platform, making it a great choice for those new to Assembly programming. We think his eight-part tutorial does a great job of introducing the language and explaining how to get the development tools up and running. You’ll need to know some basic programming concepts, but from what we saw you don’t need any prior experience with ARM or Android.

So why learn Assembly at all? We took a stab at Assembly for AVR a few months ago and really learned a lot about the hardware that we just never needed to know writing in C. It’s a great way to optimise functions that waste too much time because of quirks with higher-level language compilers. That means you don’t need to write your entire application in Assembly. You can simply use it to streamline hairy parts of your code, then include those Assembly files at compile time.

31 thoughts on “Have You Got What It Takes To Code Android Apps Using Assembly?

      1. I meant more that “Android” refers to the abstraction that apps run on, whereas coding in ASM for these devices would mean writing an ARM application, but not one that would necessarily run on the Android framework.

  1. > Do you have a rooted Android device and a computer running Linux? If so, you’re already on your way to coding for Android in Assembly.

    Not even close! I’m not that crazy! I haven’t even used assembly lang for 8 bit micros for a looong time.

  2. Nice project, but I don’t agree that ARM provides the least-complicated Assembly platform. RISC doesn’t make it easier for programmers to implement a given algorithm and the pre-/post-shift and other modifiers for the ARM instructions makes it more difficult to use the right instruction. The x86 instruction set is a CISC instruction set, but you are right, it is complicated, too. Take a look at the 6502 or 68k instruction sets, which I think are much easier to use for human beings, if you don’t have a built-in compiler and optimizer in your brain :-)

  3. Isotope, you are missing something.

    You have two options: Call streamlined asm functions from regular android code, or call android code from an asm application. The end user should be completely oblivious to the difference.

  4. I think PIC definitely provides the least complicated assembly platform. Considering some devices have very low instruction counts 35 on the ol’ 16f84a and a very simple architecture. Compared to ARM which has very many, and newer cores have various cool things like ThumbEE. Some features are only usable with secret codez.

    Arm assembly is very worth while learning and becoming proficient in since it’s likely to become more popular in the main computer market. And we need to get better at exploiting it.

    1. You should define “least complicated assembly platform” in more detail: Of course, if there are just 35 instructions, as in some cheap PICs, it might be easy to learn all instructions, but how difficult is it to write programs with it? Take a look at the programming language COW (I’ve written a JavaScript interpreter for it: http://www.frank-buss.de/cow.html ). It has only 12 instructions, each one very easy to understand, but it is very difficult to implement something useful in it, and more important, much more difficult to understand what some code does by just reading it. Same for ARM: I’ve seen a nice FFT implementation in ARM, but even with very good commented source code, it is very hard to understand how it works.

    2. I agree with Frank Buss…

      Knowing the instructions is not a problem as far as you have the instruction list clearly explained and I prefer one instruction to do something instead of 3 or more.

      Moreover, RISC processors are really interesting when they can offer a one clock cycle instruction… If too few instructions are implemented, there’s no interested at all. THis problem is common to PICs and low-end MSP430 for example.

      [mode mylife] I learnt “assembler” on 68000 and switched to AVR then. It took me one week only to implement a fully functional app from zero[/mode mylife]

  5. Android devices use ARM processors
    Except those that don’t. There are at least MIPS-based devices and Intel will be releasing their own port. By not using the virtual machine you’re effectively splintering the Android platform.

    1. X86 android devices are already shipping .. the Logitech Ruvue is one of them.

      @original article

      >>Do you have a rooted Android device
      >>and a computer running Linux?
      >>If so, you’re already on your
      >>way to coding for Android in Assembly.

      You can’t yet write an “Android Application” in 100% native code (I think the next version of NDK will make that possible), and even if you could most of the APIs you want aren’t available from native land unless you target 2.3 only.
      And.. I cant see any reason you couldnt do inline assembly for Android using the NDK anyhow.

  6. ARM is easy because all IP cores are flashed with initialization and management code at the factory, this includes consumer/hobbyist OMAP chips..To get to mess with the actual interesting stuff you gotta pay big money for one of the handset cores, and get special licensing. Unless you find memory corruption in certain parts of the kernel or boot chain on consumer devices.

    I actually did a paper on Trustzone before iphone and other products existed. RISC based I/O controllers are actually better to learn with, radioshack use to sale one..

    1. ARM is easy because all IP cores are flashed with initialization and management code at the factory, this includes consumer/hobbyist OMAP chips..To get to mess with the actual interesting stuff you gotta pay big money for one of the handset cores, and get special licensing.

      I don’t even understand what you’re saying. If you want to write all code from power-on onwards just buy a microcontroller board for $20. Even most application processors only have enough built-in capabilities to load a sector from NAND flash, the rest is up to you.

      1. “I don’t even understand what you’re saying”

        ok…everything has a loader ROM unless you do special licensing and factory flash your own..like I said..OMAP and others have USB and a lot of other stuff paged just in the first stage loader..

  7. There is a huge , make that monstrous, lack of people learning ASM. Sure you can write code with C or others but what do you do when that code doesn’t work like it should ? When the compiler has an error or the library you depend on doesn’t work ? Without knowing ASM you can’t use the debugger, that spits out things like registers and opcodes. You can’t go to the data sheet, that is talking about the same kind of things.

    I really have no respect for hardware developers that don’t understand ASM. Without knowing ASM you are just relying on other peoples software and will never be able to fully use the hardware.

    1. >>lack of people learning ASM.

      Maybe because it isn’t useful for the vast majority of development that is now done in high-level languages with frameworks and large “standard libraries”

      >>that code doesn’t work like it should ?

      http://www.gnu.org/s/gdb/

      >>When the compiler has an error

      You ask the people that have written the compiler.. ARM, Intel, Renesas do have people involved with GCC. I would rather they fix compiler level issues like working around chip errata, pipeline bugs than someone that think they are an asm h4x0r.

      >>or the library you depend on doesn’t work ?

      The only thing I can think of that you would need asm level debugging for is startup code.. source level debugging is more useful for fixing most issues.

      >>Without knowing ASM you
      >>can’t use the debugger,

      GDB is source level.

      >>that spits out things
      >>like registers and opcodes.

      Only if you ask it too do a disassembly or something. GDB has no problem working with source.
      Android’s NDK has support for GDB.

      >>You can’t go to the data sheet,

      The software manual for your chosen chip will tell you all the opcodes etc.. if such documentation didn’t exist no one could write assemblers or compilers.

      >>I really have no respect for
      >>hardware developers that don’t understand ASM.

      I have no respect for people that think they know better than the compiler. Do you fully understand the pipeline? are you 100% sure your “efficient”/”pretty” inline asm isn’t actually slower than the stuff your compiler is generating?

      >>will never be able to fully use the hardware.

      Unless you are very space constrained the only asm you need on ARM is maybe some in your crt0 (your toolchain vendor should supply it) and maybe some for ARM specific stuff like reading the status register. Any asm you use should be for very specific tasks.. there is no point writing asm that calls libc functions. On Android 2.2+ (IIRC) Dalvik has a JIT anyhow.. so there is even less point to this.

      1. regardless of android/dalvik, any C programmer worth their salt simply MUST know how to at least READ ASM code. I find your arguments weak and uniformed. You should have at least SOME idea of what ASM instructions your code turns into (counts EQUALLY for c++) and learn what you are actually asking the processor to do. It really IS important.

  8. And the conclusion of all this?
    I thought the closer to the Hardware the more control a programmer has, and the faster the App. However, it doesn’t make efficiency and effectiveness sense to write large Apps in assembly. It would take too long, too many programmers, no portability, readability, and independence from the Hardware. Thus we’ll always need some ASM for Kernel stuff, or when speed, or/and space, are at premium.

Leave a Reply to cantidoCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.