Develop Reference

Can't compile Chromium for android on Debian 9 - Unable to create file. File name too long

I am trying to compile chromium for android on Debian 9 and I get this error, can someone help me on this?
dacod#phoenix:~/Devel/chromium/src$ ninja -C out/Default cast_shell_apk
ninja: Entering directory `out/Default'
[0/21317] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate...snapshot_external_references(//build/toolchain/android:android_clang_arm)
ninja: error:
WriteFile(__third_party_WebKit_Source_bindings_modules_v8_generate_v8_context_snapshot_external_references___build_toolchain_android_android_clang_arm__rule.rsp):
Unable to create file. File name too long
ninja: build stopped: .

The file system you are building on does not support name sizes long enough to accommodate the 150 character filename:
__third_party_WebKit_Source_bindings_modules_v8_generate_v8_context_snapshot_external_references___build_toolchain_android_android_clang_arm__rule.rsp
Typical file systems will support 255 character file names. Here is a reference:
https://serverfault.com/questions/9546/filename-length-limits-on-linux
However, eCryptfs only supports 143 character file names if it is also configured to encrypt the file names themselves [source]. Are you building in your home folder and is it encrypted? If so, this may be the reason. To check the file name size, run the following in your build folder:
$ getconf NAME_MAX .
143
If it is not 255 you may be building on an ecryptfs partition. Try building in /tmp instead, as it may not be encrypted. You can check this with:
$ getconf NAME_MAX /tmp
255

zipalign: error while loading shared libraries: libc++.so: cannot open shared object file: No such file or directory

I am trying to build android app. When I run the zip align tool to optimize the APK, I get this error message:
zipalign: error while loading shared libraries: libc++.so: cannot open shared object file: No such file or directory
I tried to install libc++
sudo aptitude install libc++
it says: Couldn't find package "libc+".
Snapshot of my terminal

If your system is 64-bits, there should be a folder lib64 on the path of
[android-path]/build-tools/[version]/
The files in lib64 are
[ec2-user 25.0.2]$ ll lib64/
total 51628
-rwxrwxrwx 1 ec2-user ec2-user 30712616 Dec 23 07:22 libLLVM.so
-rwxrwxrwx 1 ec2-user ec2-user 482522 Dec 23 07:22 libbcc.so
-rwxrwxrwx 1 ec2-user ec2-user 433914 Dec 23 07:22 libbcinfo.so
-rwxrwxrwx 1 ec2-user ec2-user 1211614 Dec 23 07:22 libc++.so
-rwxrwxrwx 1 ec2-user ec2-user 20019608 Dec 23 07:22 libclang.so
Just copy the folder lib64 and zipalign program together to the destination path, and you can run the zipalign correctly. It worked for me. I guess the zipalign has a dependency on the files in lib64 folder.

I met the same problems and google it. You can try the following suggestions:
If you are in 64-bit environment, try: sudo apt-get install lib32stdc++6 lib32z1 lib32z1-dev.
Update the latest android sdk tools and do not move the zipalign binary to any other folder. It solve my problem.

I had the exact same problem and it was probably because I moved the zipalign binary from <android-path>/build-tools/23.0.3 to <android-path>/tools.
The solution is to add the build-tools/23.0.3 dir to your path:
export PATH=${PATH}:<android-path>/build-tools/23.0.3

cat command is adding extra characters

I have a weird issue where I am reading a binary file with cat. Piping the output is adding extra characters, specifically 0D0D. So I can read a file in a binary editor and it looks like this
...82 FF B3 C9 0A 97....
However, when I cat the output to a text file it mysteriously adds 0D0D like this
...82 FF B3 C9 0D 0D 0A 97...
I am reading a btsnoop_hci.log file generated by an android phone. These are the actual characters in question. I know for a fact that this happens in the middle of a string of characters that make up a Bluetooth link key, so those extra characters should DEFINITELY not be getting added. Does anyone know what is going on, and why cat is adding extra characters??

You are getting two carriage return bytes inserted before a line feed byte. These characters are significant, in different combinations, as line terminators for various operating systems. (Windows uses the two-byte terminator 0D 0A, Unix and OS X use just 0A, and the original MacOS used just 0D).
It looks, therefore, as if you are getting some kind of text mode processing of your binary data, though why you get that specific processing I couldn't say. I'm somewhat surprised by your claim that cat is performing such munging, but if it's really cat and not something else in the pipeline then you probably need to use a different tool.

cat is not adding any characters. Try the following:
$ adb shell
android$ md5 yourfile
android$ cat yourfile > newfile
android$ md5 newfile
Here's an example from my device:
shell#hammerhead:/mnt/sdcard $ md5 /system/bin/sh
cf3301e2cf56e5edc88ee20e3899a31e /system/bin/sh
shell#hammerhead:/mnt/sdcard $ cat /system/bin/sh > newfile
shell#hammerhead:/mnt/sdcard $ md5 newfile
cf3301e2cf56e5edc88ee20e3899a31e newfile
shell#hammerhead:/mnt/sdcard $
You'll notice that the checksums are identical. cat did not modify the file in any way.
Now let's try adb:
$ adb shell cat /system/bin/sh | md5sum
23c023cc5eaca953d4b1733afcdd1097 -
The checksum is different.
The problem is not with cat. Delete this question and ask a followup about adb.

Android JOBB don't dump good

I tried create an OBB file and then, dump this file to see all works fine.
I have a folder called "HOLA" in C:\Users\abreu20011\Desktop\HOLA with the next distribution:
HOLA
\_>hola.txt (i wrote "hello world" inside)
\_>emulator-arm.exe
\_>emulator-mips.exe
\_>emulator-x86.exe
I put emulators file, because when I trying to compress with the text file only, I received the next error when I write the sentence:
jobb -pn es.test.test -pv 1 -d C:\Users\abreu20011\Desktop\HOLA -o hola.obb
Slop:0 Directory Overhead: 0
Slop:289 Directory Overhead: 224
java.io.IOException: no data clusters
at de.waldheinz.fs.fat.Fat.<init>(Fat.java:129)
at de.waldheinz.fs.fat.Fat.create(Fat.java:96)
at de.waldheinz.fs.fat.Fat.SuperFloppyFormatter.format(SuperFloppyFormatter.java:236)
at com.android.jobb.Main.main(Main.java:414)
So, I fattened the directory with this emulators, and the jobb tool worked fine:
Slop:0 Directory Overhead: 0
Slop:2453 Directory Overhead: 608
But the real problems arise when I try to dump the obb file. Since the jobb tool creates the obb file in the same directory of the tool, I wrote the dump sentence:
jobb -dump hola.obb -d C:\Users\abreu20011\Desktop
The program extracts a partial file of emulator-arm.exe and wrote the next error:
Package Name: es.test.test
Package Version: 1
LFN = emulator-arm.exe / SFN = ShortName [/☺[←►▬←☺ifl -- 2f 1 5b 1b 10 16 1b 1 6 9 66 6c ]
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2335
at de.waldheinz.fs.fat.ClusterChain.readData(ClusterChain.java:225)
at de.waldheinz.fs.fat.FatFile.read(FatFile.java:126)
at com.android.jobb.Main.dumpDirectory(Main.java:137)
at com.android.jobb.Main.main(Main.java:315)
Why I can't create an obb file of his size is smaller?
and why I can't dump the original file?
Thanks for your help and for your time! :)

Unable to see the source tree through Finder while doing repo sync in OSX

I am downloading the android source as per the instructions mentioned in source.android.com. I have made a different case sensitive file system and have made a directory in it and doing a repo sync. I can see through terminal ls -la
the following files
Aruns-MacBook-Pro:ANDROID_DIR ArunAbraham$ ls -la
total 0
drwxr-xr-x 3 ArunAbraham staff 102 May 14 17:26 .
drwxr-xr-x 5 ArunAbraham staff 340 May 14 17:23 ..
drwxr-xr-x 6 ArunAbraham staff 238 May 14 17:27 .repo
But i can't see the same through the Finder. Is this how it is supposed to behave ?
Could someone explain me this behavior ? Or have i done something wrong ?

Finder treats files starting with a . as hidden files. ls does as well but the -a option you gave overrides it.
Here's a tip to show all hidden files in the Finder, but you will see everything, not just theones you want. Short version:
defaults write com.apple.Finder AppleShowAllFiles YES