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! :)
Related
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
I am trying to build cyanogenmod, but the build fails with the following. My drive on /mnt has plenty of space, however the root-partition where /tmp resides has less space, so I assume this happens while writing a temporary file.
Therefore I would like to redirect the temporary directory for this to somewhere under /mnt as well, how can I do this in cyanogenmod/Android build system? I tried setting TMP and TEMP but they don't seem to have any effect.
Package OTA: /mnt/android/system/out/target/product/oneplus3/cm_oneplus3-ota-178d4560f4.zip
unzipping target target-files...
running: unzip -o -q /mnt/android/system/out/target/product/oneplus3/obj/PACKAGING/target_files_intermediates/cm_oneplus3-target_files-178d4560f4.zip -d /tmp/targetfiles-RM6VsH
--- target info ---
...
cache_size = (int) 268435456
...
recovery_size = (int) 67108864
...
userdata_size = (int) 57436708864
(using device-specific extensions from target_files)
loaded device-specific extensions from /tmp/targetfiles-RM6VsH/META/releasetools.py
Warning: could not find RADIO/filesmap in <zipfile.ZipFile object at 0x2b4193f91fd0>.
using prebuilt recovery.img from BOOTABLE_IMAGES...
using system.img from target-files
Total of 770048 4096-byte output blocks in 2698 input chunks.
Generating digraph...
Finding vertex sequence...
Reversing backward edges...
0/0 dependencies (0.00%) were violated; 0 source blocks stashed.
Improving vertex order...
Revising stash size...
Total 0 blocks are packed as new blocks due to insufficient cache size.
Reticulating splines...
Traceback (most recent call last):
File "./build/tools/releasetools/ota_from_target_files", line 1772, in <module>
main(sys.argv[1:])
File "./build/tools/releasetools/ota_from_target_files", line 1727, in main
WriteFullOTAPackage(input_zip, output_zip)
File "./build/tools/releasetools/ota_from_target_files", line 664, in WriteFullOTAPackage
system_diff = common.BlockDifference("system", system_tgt, src=None)
File "/mnt/android/system/build/tools/releasetools/common.py", line 1302, in __init__
b.Compute(self.path)
File "/mnt/android/system/build/tools/releasetools/blockimgdiff.py", line 299, in Compute
self.ComputePatches(prefix)
File "/mnt/android/system/build/tools/releasetools/blockimgdiff.py", line 618, in ComputePatches
new_f.write(piece)
IOError: [Errno 28] No space left on device
make: *** [/mnt/android/system/out/target/product/oneplus3/cm_oneplus3-ota-178d4560f4.zip] Error 1
make: Leaving directory `/mnt/android/system'
Update: I found a workaround by editing /mnt/android/system/build/tools/releasetools/common.py and setting a temp-dir manually with something like tmpdir = tempfile.mkdtemp(dir='/mnt/tmp') at line 1299, according to documentation mkdtemp should use TMP and TEMP, however that seems to not have worked for me here! Python is at version 2.7.6.
To set the TMPDIR environment variable, specify a directory that is accessible to the user ID that runs the replication or publishing programs. Ensure that files cannot be deleted by other user IDs.
For example, the following command specifies the /home/repldba/tempfiles/ directory:
export TMPDIR=/home/repldba/tempfiles/
Is there a known limit on the path for the Android ndk input files? I've run into an issue where the input path is over 155 characters the android g++ command fails to find the file.
The local path back down to my base directory is quite deep, in a few cases I have a full path back to a source file in the jni project making the path a bit long, though 155 doesn't seem like a very high limit.
LOCAL_PATH := $(call my-dir)/../../../../../../../../../..
Here is an example of a failure, at 155 characters:
/cygdrive/c/java/Android/android-ndk-r10d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++ -c jni/VECodecG723/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/./././VECodecG723/VECodecG723.cpp
arm-linux-androideabi-g++.exe: error: jni/VECodecG723/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/./././VECodecG723/VECodecG723.cpp: No such file or directory
arm-linux-androideabi-g++.exe: fatal error: no input files
And a success case, at 153 characters:
/cygdrive/c/java/Android/android-ndk-r10d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++ -c jni/VECodecG723/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/././VECodecG723/VECodecG723.cpp
jni/VECodecG723/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/../gen/././VECodecG723/VECodecG723.cpp:26:17: fatal error: jni.h: No such file or directory
#include <jni.h>
The repeating ../gen is just for this sample, the actual path contains 10 ../ and then the full path back to the file.
I've tried the paths with the regular g++ compiler and it does not fail because of the path length. I have also tried this in a Windows command shell with the android g++ and it has the same issue.
Is there anything I can do short of renaming my folders.
I took another look at this and figured it out. I was running into the max path length for Windows, 260 characters or so. When I added the base path forming an absolute path to the source file the breaking point was around the windows max. No good way around this other than to build on Linux or a Mac.
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.
when I try to unzip a encrypted obb file using the jobb tool jumps me the following error:
jobb -dump /temp/obb-output/ -o my-app-assets.obb -k secret-key
Package Name: com.example.sample
Package Version: 1
SALT: -63dddd10f3a63bb
29eb26a5c9227f6efeab677fc53a7348
[LFN = video.avi / SFN = ShortName [/> ifl -- 5 2f 1d 10 3 3e c 1d 69 66 6c ]]
Alignment off reading from sector: 2433
Partial read from sector: 2433
Exception in thread "main" java.nio.BufferOverflowException
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183)
at java.nio.ByteBuffer.put(ByteBuffer.java:832)
at com.android.jobb.EncryptedBlockFile$EncryptedBlockFileChannel.readDecryptedSector(EncryptedBlockFile.java:292)
at com.android.jobb.EncryptedBlockFile$EncryptedBlockFileChannel.read(EncryptedBlockFile.java:142)
at de.waldheinz.fs.util.FileDisk.read(FileDisk.java:118)
at de.waldheinz.fs.fat.ClusterChain.readData(ClusterChain.java:214)
at de.waldheinz.fs.fat.FatFile.read(FatFile.java:126)
at com.android.jobb.Main.dumpDirectory(Main.java:137)
at com.android.jobb.Main.dumpDirectory(Main.java:112)
at com.android.jobb.Main.main(Main.java:315)
Can anyone help me?
It is to do with expansion file version numbers. I just needed to increment versionCode in my manifest and in the obb file. Android doesn't seem to like you updating with a new obb file with the same version number, Hope it helps.