[Android Software/Hacking General [Developers Only]] Surge1223:
LOL man from all this work you do, I would have never pegged you for a windows user :D

Well I fresh cloned on my mac which i just booted and from clone to build this is my output

Surges-MacBook-Pro:~ surge$ git clone https://github.com/Surge1223/ndk-random jni
Cloning into 'jni'...
remote: Counting objects: 535, done.
remote: Compressing objects: 100% (435/435), done.
remote: Total 535 (delta 81), reused 528 (delta 79), pack-reused 0
Receiving objects: 100% (535/535), 2.91 MiB | 1.36 MiB/s, done.
Resolving deltas: 100% (81/81), done.
Checking connectivity... done.
Surges-MacBook-Pro:~ surge$ cd jni
Surges-MacBook-Pro:jni surge$ NDK_ROOT=/Users/surge/Downloads/adt-bundle-mac-x86_64-20140702/sdk/ndk-bundle
Surges-MacBook-Pro:jni surge$ $NDK_ROOT/ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APPLICATION_BUILD_SCRIPT=./Application.mk
cp: zipalign/obj/local/armeabi/libz.a: No such file or directory
cp: zipalign/obj/local/armeabi/libzopfli.a: No such file or directory
Android NDK: WARNING:zipalign/Android.mk:zipalign: non-system libraries in linker flags: zipalign/libandroidfw.a zipalign/libandroidfw.a zipalign/libutils.a zipalign/libcutils.a zipalign/liblog.a zipalign/libm.a zipalign/zlib-lib/libz.a zipalign/zopfli-lib/libzopfli.a
Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK: current module
Android NDK: WARNING:zipalign/Android.mk:zopfli: LOCAL_LDLIBS is always ignored for static libraries
Android NDK: WARNING:zipalign/Android.mk:zopfli: non-system libraries in linker flags: zipalign/libm.a
Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK: current module
[armeabi] Compile++ thumb: zipalign <= ZipAlign.cpp
[armeabi] Compile++ thumb: zipalign <= ZipEntry.cpp
[armeabi] Compile++ thumb: zipalign <= ZipFile.cpp
[armeabi] Compile++ thumb: zipalign <= logstubs.cpp
[armeabi] Compile thumb : zopfli <= blocksplitter.c
[armeabi] Compile thumb : zopfli <= cache.c
[armeabi] Compile thumb : zopfli <= deflate.c
[armeabi] Compile thumb : zopfli <= gzip_container.c
[armeabi] Compile thumb : zopfli <= hash.c
[armeabi] Compile thumb : zopfli <= katajainen.c
[armeabi] Compile thumb : zopfli <= lz77.c
[armeabi] Compile thumb : zopfli <= squeeze.c
[armeabi] Compile thumb : zopfli <= tree.c
[armeabi] Compile thumb : zopfli <= util.c
[armeabi] Compile thumb : zopfli <= zlib_container.c
[armeabi] Compile thumb : zopfli <= zopfli_lib.c
[armeabi] StaticLibrary : libzopfli.a
[armeabi] Compile arm : z <= adler32.c
[armeabi] Compile arm : z <= compress.c
[armeabi] Compile arm : z <= crc32.c
[armeabi] Compile arm : z <= deflate.c
[armeabi] Compile arm : z <= gzclose.c
[armeabi] Compile arm : z <= gzlib.c
[armeabi] Compile arm : z <= gzread.c
[armeabi] Compile arm : z <= gzwrite.c
[armeabi] Compile arm : z <= infback.c
[armeabi] Compile arm : z <= inflate.c
[armeabi] Compile arm : z <= inftrees.c
[armeabi] Compile arm : z <= inffast.c
[armeabi] Compile arm : z <= trees.c
[armeabi] Compile arm : z <= uncompr.c
[armeabi] Compile arm : z <= zutil.c
[armeabi] StaticLibrary : libz.a
[armeabi] StaticLibrary : libstdc++.a
[armeabi] Executable : zipalign
[armeabi] Install : zipalign => libs/armeabi/zipalign
Surges-MacBook-Pro:jni surge$

A few of these warnings i have fixed but havent pushed yet

I removed the logic to this, its just a warning message for remnants at this point

cp: zipalign/obj/local/armeabi/libz.a: No such file or directory
cp: zipalign/obj/local/armeabi/libzopfli.a: No such file or directory

This is because i added them to LDFLAGS instead of LOCAL_STATIC_LIBRARIES Im used to gcc and i assume that isn’t isn’t hurting anything but Ill make it stop complaining anyways

Android NDK: WARNING:zipalign/Android.mk:zipalign: non-system libraries in linker flags: zipalign/libandroidfw.a zipalign/libandroidfw.a zipalign/libutils.a zipalign/libcutils.a zipalign/liblog.a zipalign/libm.a zipalign/zlib-lib/libz.a zipalign/zopfli-lib/libzopfli.a

Now this is an error I didn’t catch, libm is the math library, so hopefully I didn’t accidentally use a arm64 limb.a instead of a armeabi libm.a

Android NDK: WARNING:zipalign/Android.mk:zopfli: non-system libraries in linker flags: zipalign/libm.a
Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK:

Oh and sorry if I wasnt clear about why I was posting my output lol

essentially if i didnt cd to the jni dir then got the same messages as you

so the commands i use to build are

Surges-MacBook-Pro:~ surge$ cd jni

Surges-MacBook-Pro:jni surge$ NDK_ROOT=/Users/surge/Downloads/adt-bundle-mac-x86_64-20140702/sdk/ndk-bundle

Surges-MacBook-Pro:jni surge$ $NDK_ROOT/ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APPLICATION_BUILD_SCRIPT=./Application.mk

or more clearly for those who follow us at some point

cd jni

$NDK_ROOT=/Users/surge/Downloads/adt-bundle-mac-x86_64-20140702/sdk/ndk-bundle

$NDK_ROOT/ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APPLICATION_BUILD_SCRIPT=./Application.mk

(if anyone else is reading and just learning/observing read the below)

I'm specifying both the APP build script and APPLICATION script because it will give me more control later to specify the use of different ABI's , compilers flags and platform compatibility Also its a easy way of having a control mk file to control the flow of building, though apparently it likes to conditionally listen, I told it to build for all ABI's, yet it builds for just whatever i set in my path. One time I got it to make armeabi armeabi-v7a arm64-v8a all in one, was kinda convenient. IIRC the Application.mk script went something like this

EDIT:

for some reason the space bettwen "$NDK_PROJECT_PATH=. " and "$APP_BUILD_SCRIPT=" above looks non-existant...

The reason i made the "edit" stand out is because I would be super annoyed if the reason i spent four hours diving through some of the most poorly commented on code/makefiles in human existence was because a space.

Please refer to the correct use in the image below