Tag Archive: linux

A good way to share a functionality across teams or companies is to share it via packaging through libraries, where the code is invisible and the team requiring it can integrate it seamlessly with the code they are working on. iOS allows the usage of static libraries via “.a” files which can be statically loaded at compile time. Runtime usage of libraries(dynamically, “.so” files) is not allowed for user apps. Some general information about these archives and their usage is mentioned below:

• iOS Simulator and an iOS device have different architectures i.e i386 and armv7s respectively. This means it is necessary to test the final library (".a") file on a real device.

• It is possible to compile a i386 based lib via command line on the terminal on a Mac OS X system. However, it is not the same for if you are building for armv7s architecture. In case of armv7s (iOS device), XCode needs to be used.

Below mentioned are the steps to create a library that can be statically linked to iOS code on a device:

• Fire up XCode and choose a new project template type under OS X→Frameworks and Libraries→C/C++ Libraries.


• Name the project and choose type as “Static”.
• Import or just drag and drop .c and .h files into the project.
• Click on “Build Settings” for the project. “Base SDK” should be Latest iOS(7.0) and “Architectures” should be Standard(armv6, armv7).


• Check the “Build Phases” in targets. Add or move the header files to “Public”.
• Select the appropriate scheme and build (Make sure you have a connected iOS device which can be selected as a scheme).


• Go to Product→Archive→Distribute→Save to save the end product which will be a folder containing the headers and the .a file.

Below mentioned are the steps to create a library that can be statically linked to iOS code that will run ONLY on the simulator. Although this is redundant but is helpful if you just want a quick lib integration/usage check:

• Fire up the terminal on OS X and fire the two commands one after another.
• gcc -Wall -c -arch i386 -arch x86_64 *.c
• ar -cvq libXXYYYZZZ.a *.o

Custom Android, Custom USB

I have been working with a custom Android device for sometime now. This is a decently powerful 2.3.4 device(It is not a phone). It has USB capabilities too, but for some arcane reasons the vendor does not want to support the USB accessory api and hence one has to rely on native linux to handle the USB drive. The vendor’s app runs as a System app and needs to have the RW access to the USB. 


We were easily able to map the USB to mnt/udisk by having a quick look at the vol.fstab, which showed:

dev_mount usb /mnt/udisk auto /devices/platform/ehci-omap.0/usb1/

Since auto-mount was already enabled so it was not much of a hassle and things looked Vanilla and easy. But, Alas, everything went well until the code responsible for R/W was deployed. The Java code simply refused to acknowledge that the USB was plugged in and had data in it. Other apps, eg: Eclipse File Explorer, And Explorer, shell(OK, let’s leave this one out as it has root privileges), were easily able to acknowledge the existence of the USB. Now, what could have gone wrong with one small piece of File R/W Java code. The permissions looked pretty much Ok(other apps were already accessing the drive).

Few hours and 3 cups of coffee later, we had an aha moment when we released that the app was running as a System App and not a normal one. Putting the theory to test we ran the app as a normal one i.e. we immediately updated the debug.keystore to use the default one plus the manifest and yes everything was sunny again.


Hmmm….The issue at hand was solved now and the Vendor has been notified about the glitch, but This makes us think about the Android Security mechanisms. There should be a way to make system apps access USB but I haven’t found the answer to that yet. Will update as soon as I stumble on something.