Develop Reference

Google play 64 bits error despite apk is provided with all native libraries in 64 and 32 bits

I'm submitting an apk to goole play that seems perfectly 64 bits compliant, it has all native libraries provided in 32 bits and 64 bits. But I still get this error when trying to deploy the apk in the gogole play console :
This release is not compliant with the Google Play 64-bit requirement
The following APKs or App Bundles are available to 64-bit devices,
but they only have 32-bit native code: 2.
Include 64-bit and 32-bit native code in your app. Use the Android
App Bundle publishing format to automatically ensure that each device
architecture receives only the native code that it needs. This
avoids increasing the overall size of your app. Learn More
Here is a screenshot of native libraries in the apk :
This apk seems to be perfectly 64 bits compliant to me, I'm really stuck on this, any help or idea very appreciated.
[edit 2019 11 14] After comment from following comment from Robert, I checked all 10 .so libraries with the tool arm-linux-androideabi-readelf provided by the ndk.
I used these 2 commands :
arm-linux-androideabi-readelf -h armeabi-v7a/*
which outputs 10 ELF headers looking like this :
File: armeabi-v7a/libVuforia.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 17252004 (bytes into file)
Flags: 0x5000200, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 28
Section header string table index: 27
And :
arm-linux-androideabi-readelf -h arm64-v8a/*
which outputs 10 ELF headers looking like this :
File: arm64-v8a/libVuforia.so
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: AArch64
Version: 0x1
Entry point address: 0x10f3a0
Start of program headers: 64 (bytes into file)
Start of section headers: 27138992 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 26
Section header string table index: 25
That seems to confirm that the 10 .so libraries are correctly provided in 32 and 64 bits. Still stuck, any help very appreciated.

I found a solution (for my case - maybe the same as yours)
In the Dev console, I had an old apk which was set as "retained" (in 32bits, for old Android devices : 14+ to 19).
Disabling it allowed me to successfully deploy my new bundle.
Hope it can help.

Cross Compile with autoconf with Android toolchain

Objective Cross compile Cisco libsrtp for Android using NDK toolchain and use libsrtp.a to statically link against my own library.
Setup : I make use of the following file
<setup.sh>
export CROSS_SYSROOT=/home/psurana/aa/sysroot
export CROSS_COMPILE=aarch64-linux-android-
export SYSROOT=/home/psurana/aa/sysroot
export CC="${CROSS_COMPILE}gcc --sysroot=${SYSROOT}"
export CXX="${CROSS_COMPILE}gxx --sysroot=${SYSROOT}"
PATH=/home/psurana/aa/bin:$PATH
then I do the following configure:
source setup.sh && ./configure --host=aarch64-linux-android --build=`./config.guess` && make -j
This compiles it for me. doing a readelf -h libsrtp.a, yields--
File: libsrtp.a(ut_sim.o)
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: AArch64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 1480 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 10
Section header string table index: 7
So far so good.
Problem
However, when I link libsrtp.a as a prebuilt static library, I get following errors:
./srtp/libsrtp.a(rand_source.o): In function `rand_source_init':
err.c:(.text+0x0): undefined reference to `stdout'
err.c:(.text+0xc): undefined reference to `stdout'
and,
rand_source.c:(.text+0x28): undefined reference to `stderr'
rand_source.c:(.text+0x3c): undefined reference to `stderr'
My understanding is that Android does not have stderr in its libc, but then how does libsrtp get these?
I have previously built the same library using something similar and I know it builds. I do not know what the error might be.

I usually get this undefined reference with libc in any platform after 21 so I usually add -D__ANDROID_API__=21 to CFLAGS and it ends up fixing it. I believe the issue comes from the new unified headers in newer ndk versions.

How to use ndk-stack with shared library in AAR file

I'm using shared object libraries in Android application. These shared object libraries are in .aar file.
One of library is crashing. In order to check crash logs and exact line no. I am using ndk-stack took.
Usage of ndk-stack is
$ adb logcat | ndk-stack -sym <Path to your shared libraries>
Now How can I get a path of shared libraries in AAR file?

You should keep in mind that not every .so file is useful for ndk-stack. Android NDK produces two kinds of .so files: stripped and non-stripped. The most difference is that last ones contain debug information, that is needed for ndk-stack and first ones don't. readelf may help to check if particular file is stripped or not:
$ readelf <non-stripped-lib> -S | grep debug
[23] .debug_info PROGBITS 00000000 00302c 0052d9 00 0 0 1
[24] .debug_abbrev PROGBITS 00000000 008305 000879 00 0 0 1
[25] .debug_loc PROGBITS 00000000 008b7e 001aa7 00 0 0 1
[26] .debug_aranges PROGBITS 00000000 00a628 000088 00 0 0 8
[27] .debug_ranges PROGBITS 00000000 00a6b0 0000d0 00 0 0 1
[28] .debug_line PROGBITS 00000000 00a780 0009de 00 0 0 1
[29] .debug_str PROGBITS 00000000 00b15e 002387 01 MS 0 0 1
[30] .debug_frame PROGBITS 00000000 00d4e8 0003d0 00 0 0 4
$
$ readelf <stripped-lib> -S | grep debug
$
As you see not-stripped ELF has a lot of .debug_* sections, that indeed contain line numbers, private / static function names, etc.
Next, .aar files, both debug and release ones, has only stripped binaries. So they are useless for ndk-stack.
AFAIK, the only place where non-stripped binaries may be found is a obj/ dir. Its location depends slightly on used build system:
for ndk-build it is under <module_name>/build/intermediates/ndk
for CMake-based it is under <module_name>/build/intermediates/cmake
Also it looks like out-of-the-box android gradle plugin offers no way to pack unstripped libraries to your aar, so the only way here is some custom task in your build.gradle.

Openssl for Android x86_64 and mips64

I have built openssl for 5/7 of the android-21 (android-L) architectures: armeabi, armeabi-v7a, arm64, mips, x86. However I am unable to build it for x86_64 and mips64.
What I'm doing...
x86 - working
The following is my working script for x86, using a toolchain created by make-standalone-toolchain:
export ANDROID_NDK_ROOT=/Users/jacsteve/dev/android/ndk
export ANDROID_API=android-21
export ANDROID_ARCH=arch-x86
export ANDROID_EABI=i686-linux-android-4.9
export ANDROID_SYSROOT=$ANDROID_NDK_ROOT/platforms/$ANDROID_API/arch-x86
export ANDROID_TOOLCHAIN=/tmp/toolchain/x86
export ANDROID_DEV=$ANDROID_SYSROOT/usr
export SYSTEM=android
export ARCH=x86
export CROSS_COMPILE=i686-linux-android-
export CFLAGS="--sysroot=$ANDROID_SYSROOT"
export CPPFLAGS="--sysroot=$ANDROID_SYSROOT"
export CXXFLAGS="--sysroot=$ANDROID_SYSROOT"
./Configure android-x86 shared no-asm -no-ssl2 -no-ssl3 -no-comp -no-hw --cross-compile-prefix=$CROSS_COMPILE --openssldir=/tmp/ssl/x86
make depend
make
make install
This works fine, and leaves me with libssl.so and libcrypto.so in /tmp/ssl/x86
x86_64 - fails
However, x86_64 fails. Here's the script:
export ANDROID_NDK_ROOT=/Users/jacsteve/dev/android/ndk
export ANDROID_API=android-21
export ANDROID_ARCH=arch-x86_64
export ANDROID_EABI=x86_64-linux-android-4.9
export ANDROID_SYSROOT=$ANDROID_NDK_ROOT/platforms/$ANDROID_API/arch-x86_64
export ANDROID_TOOLCHAIN=/tmp/toolchain/x86_64
export ANDROID_DEV=$ANDROID_SYSROOT/usr
export SYSTEM=android
export ARCH=x86_64
export CROSS_COMPILE=x86_64-linux-android-
export CFLAGS="--sysroot=$ANDROID_SYSROOT"
export CPPFLAGS="--sysroot=$ANDROID_SYSROOT"
export CXXFLAGS="--sysroot=$ANDROID_SYSROOT"
./Configure android-x86 shared no-asm -m64 -no-ssl2 -no-ssl3 -no-comp -no-hw --cross-compile-prefix=$CROSS_COMPILE --openssldir=/tmp/ssl/x86_64
make depend
make
make install
The Errors...
x86_64
I get a load of error messages from the make call that look like this:
/private/tmp/toolchain/x86_64/bin/../lib/gcc/x86_64-linux-android/4.9/../../../../x86_64-linux-android/bin/ld:
error: libcrypto.a(cryptlib.o): incompatible target
/private/tmp/toolchain/x86_64/bin/../lib/gcc/x86_64-linux-android/4.9/../../../../x86_64-linux-android/bin/ld:
error: libcrypto.a(mem.o): incompatible target
...
collect2: error: ld returned 1 exit status
It looks to me like x86_64-linux-android-gcc is compiling everything fine, but when we get to the linking stage, x86_64-linux-android-ld can't read the compiled object files.
mips64
Using a similar setup for mips64 (with ./Configure android-mips ...) I get the following error, which looks to be a similar issue to do with mips64-linux-android-ld being unable to read object files:
/Users/jacsteve/dev/android/ndk/platforms/android-21/arch-mips64/usr/lib/libdl.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
Does anyone know how to build the x86_64 and mips64 architectures successfully?

Solved!
Instead of
./Configure android-x86 ...
I used
./Configure linux-generic64 ...
I also used linux-generic32 for the 32bit architectures.

Running make clean before ./Configure solved the problem for me.

The error from building openssl for mips64, I guess, resulted from the incompatible ABI format between objects and libraries, which the format objects is mips-ELF64, while libraries provided by ANDROID_NDK is mips ELF32
cd ${ANDROID_NDK_HOME}/platforms/android-24/arch-mips64/usr/lib
readelf -h libc.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0xa7d0
Start of program headers: 52 (bytes into file)
Start of section headers: 204792 (bytes into file)
Flags: 0x50001007, noreorder, pic, cpic, o32, mips32
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 18
Section header string table index: 15

android - BufferOverflowException when trying to unzip obb file

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.