So i am try to build openSSL into my qt android app. and to all my efforts from using precompiled binary to installing ubuntu 18 and still failing i am getting desperate.
I have read from this thread:
QT + OpenSSL + Android
that i can get them from ANY existing apk, so how do i extract it from the apk? Because i do not find it in the android ndk and sdk. if its only selected apk, what program do i use indor for me to see it.
im using Qt 5.11 on windows, but i have linux OS too if needed :) Thank you!
I've built OpenSSL for android a few months ago, with zero issues. Just follow this guide for Linux:
export ANDROID_NDK_ROOT="/home/dev/android-ndk-r12b"
SR="$ANDROID_NDK_ROOT/platforms/android-16/arch-arm"
BR="$ANDROID_NDK_ROOT/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-"
RANLIB="$BR"ranlib CC="$BR"gcc ./Configure android-armeabi --prefix=$SR/usr --sysroot=$SR
ANDROID_DEV=$SR/usr make
make install
Obviously, you will have to replace the paths with your own depending on where and what NDK version you install, and you will already have downloaded and extracted the OpenSSL source. Also, keep in mind that Qt doesn't seem to work with the latest and "greatest" android toolchains. In fact, android has already switched to llvm, but for Qt you will need to use the older gcc toolchains.
You can use this script to build libcrypto.
There are many prebuilt binaries you can get online, without having to rummage about in apk files, for example this repo has openssl libcrypto for a bunch of platforms, including android.
Don't know where you got the idea that you could get the libs from any apk file, obviously, it has to be a package from an application that incorporates those libraries for dynamic linking.
Last but not least, if you still plan on getting pre-compiled binaries, keep in mind they have to be built with a version that is compatible with your compiler. Which is why it is best to build the libs yourself, with the same toolchain you are using for your application. There is also the danger of getting "bad" libs from an unknown source, they might be outdated or tampered with.
You can open them by simply changing their extension to ".zip" :) will update if i can find apps that has these files.
PS: No all apk has libcrypto.so and libssl.so.
Related
Note - I am relatively new to Android and AOSP...
Where can I find the Android SDK in the AOSP? As we know, we build apk files in the android studio using the separately installed SDK. But for some reason, I wish to use the SDK in the AOSP if it is available. I see the source code of SDK in the AOSP; do we need to build it?
Why/How I have arrived at the above question:
I had created an .apk in the AOSP which had JNI files and dependency on some existing Broadcom libs (so). It is a system app. What I noticed is the .apk package does not contain the JNI libs but rather is copied to /system/lib folder separately. Hence I had a doubt how the .apk upgrade will work? Is it possible?
I assumed the .apk upgrade won't work that way and the .apk should be packaged including the JNI libs. Hence I planned to build the .apk in the studio and use the .apk as prebuilt and just sign it in the AOSP (we have the keys). Then I also wanted to allow the developers to build the .apk in AOSP itself by running the Gradle in the command line. I did so by adding the command to the Android.mk. But the point here is, it is still using the SDK installed in /home//Android/Sdk. But there may be build machines which may not have the SDK installed. So I am putting this question - Do we (where?) have the SDK in AOSP? Can I use that instead?
I tried to explain the problem.. in case it's not clear please let me know... Will try to give more details...
OTA update will work. Update with Package Manager - won't. This is normal for system apps with native libraries.
In AOSP applications are built differently depending on their location in build tree. Apps placed in ~/packages/apps and ~/device/some_vendor are system apps and they are handled differently by the system. One of differences is that during build process they are stripped of their native libraries and those libraries are simply copied to the /system/ partition.
Including pre-built apk is a good solution.
Yes you can build sdk yourself from sources. Yes, it's there. But I don't understand why you need that. Are there any changes to the API?
There are other options. For example, you can mangle your build scripts. Say, you can add a global FLAG that would disable lib stripping for system apps.
I'm trying to install some python packages (pillow) for QPython on Remix however I get the error that arm-linux-androideabi-gcc does not exist.
I googled and I think I need NDK, however looking at the website (https://developer.android.com/ndk/downloads/index.html) I couldn't find a way to do this on android.
Any help is much appreciated, thank you!
Installing the NDK on Android? As in running the NDK compilers on an Android device? We don't support Android as a host OS for the NDK.
Check out AIDE android ide from the Google playstore
Despite Dan's answer, which I respect. It's not entirely accurate. The Android ndk build system doesn't allow for for host to be set to the $TARGET_ARCH, but building it manually in much the same way you would for any custom toolchain is entirely possible.
I should note that I have only done this for gcc, and have not attempted to do so with clang.
From Googles ndk toolchain repo just take the essentials needed, gcc, binutils, gmp, mpfr, etc and set your host and target to the ndk toolchain gcc. Use the ndk sysroot as build-sysroot, and then just add your compiler flags and with a little fiddling you should get it.
Id be happy to post more, it's been a project of mine to build Android on Android, also i highly recommend adding static versions of the ndk libs, as the android system doesn't have a c++ lib, and a few others. You may have to build some manually using aosp build system
I built it with stage-one flags so that the binaries would be static, as you never know when android might remove a lib that your toolchain depends on.
I encourage you to try, as an added benefit you will then he able to build many useful android native binaries that usually aren't available without editing the aosp source. Also having the ability to build binaries on the fly is very useful
This is not a duplicate question, I will post the links to the questions whose 'accepted' answers did not work for me.
I have been trying to integrate a third party library for my flex android application for a few weeks now, with no success. Unfortunately there is no reliable end-to-end documentation for the same. What little Adobe has documented on the topic is insufficient to say the least.
The tools I am using:
ADT to package ANE from command line on Windows 7.
Flash Builder to package the final APK (ANE with the flash part)
My directory structure for the ANE:
The ADT command I am using:
<Adt path>\adt -package -storetype PKCS12 -keystore ./cert.p12 -storepass <password> -target ane myane.ane ./build/ane/extension.xml -swc ./build/ane/*.swc -platform Android-ARM -platformoptions platform.xml -C ./build/ane/Android-ARM/ . -platform Android-x86 \ -C ./build/ane/Android-ARM/ .
Here are a few questions on Stack Overflow that I did refer to and which did not work for me:
Question#1: Accepted answer is to simply combine both JAR files using the JAR tool in java. It did not work for me, I get a NoClassDefFound error when trying to access any class inside ThirdPartyJar.jar. I export my Native Jar from Eclipse like this:
My doubt here is, in combining the two JARs where did I define the dependency? How is a simple combination of JARs working for others who have accepted the answer?
Question#2 : The accepted answer here talks about creating a platform options XML which defines the said 'packaged dependency'. Seems more logical. I tried to create it, as visible in my folder structure above and the adt command I am using. Here's how the 'platform.xml' looks:
<platform xmlns="http://ns.adobe.com/air/extension/4.0">
<packagedDependencies>
<packagedDependency>ThirdPartyJar.jar</packagedDependency>
</packagedDependencies>
<packagedResources>
</packagedResources>
</platform>
At first, I was getting an 'Namespace should be same as extension.xml' error while trying to build the ANE, but after I changed both of them to '...../4.0' I could build the ANE without any errors. However, when I included the ANE in my Flex Project, and tried to Run As > Mobile Application, it would give me this error:
I would then rename the strings.xml file in my Android Native Project, re-build the ANE, to get this error:
How do I get it to work? Between these two solutions I have tried myriad ways to package the two JARs together but it just would not work!
Your second method using the platform options method is the best method available.
Problem with packaged dependencies with Android and AIR are nearly always caused by the build tools in the AIR SDK. The versions included with older versions of the SDK are not recent enough to use the latest features from the Google Play Library nor use some of the more recent SDK's.
If you have the Android SDK build tools installed then you can copy the dx.jar file from build-tools/x.x.x/lib/dx.jar over the same file in your AIR SDK located here:
AIRSDK/lib/android/bin/dx.jar
You must replace the one in the AIR SDK with the one from the Android build tools and not the other way around.
I also highly suggest you update adb at this time. Updating adb can solve a lot of connection and debugging issues.
You should not use a version > 20.0 of the Android build tools. Anything higher than 20.0 currently has issues with the AIR packager.
If you use AIR 18+ the build tools have been updated to v20.0.0 and you shouldn't have to update the build tools unless you are using even more modern features (such as the android support v13 lib).
Reference: http://airnativeextensions.com/knowledgebase/tutorial/5
I am trying to deploy a Qt app to an Android device, though I receive the error about missing stdlib.h. I found out that this library is actually inside sub directory tr1 of includes. I modified the include<stdlib.h> to include<tr1/stdlib.h>. After this I encountered the error for locale.h. This files doesn't seem to be present anywhere in the NDK.
The app works fine if build for Desktop as the Linux GCC has all files in proper hierarchy.
Any fixes?
Finally, I resolved the issue. It was just the wrong Android NDK build I downloaded. My system architecture is x86_64 and the Android architecture is x86. The build I downloaded was that x86_64 Android. Make sure when downloading the target platform is your Android architecture.
Also, one might find several solutions recommending to create stand-alone build using make-standalone-toolchain.sh script and setting CXX home to this build and as well as set "sysroot". Please do not do it. It's not at all required. Just set the NDK path from Android option from Qt itself. That shall be enough.
I am currently in the process of updating our project OpenSSL to 1.0.1i using http://wiki.openssl.org/index.php/Android.
Looking in the config file I found that OpenSSL has 2 Android build options: android-armv7 and android-x86.
I have been able to build the armv7 configuration and it appears to be working correctly on a Nexus 5 and a Kindle Fire 1st Gen.
What I am wondering is would my current library work if it were in the armeabi directory instead of the armeabi-v7a directory? I was not able to find sufficient information as to whether it matters if the OpenSSL is built with armv7 but my project libraries are built with older arm in mind.
Note: My minimum API level is 8.
What I am wondering is would my current library work if it were in the armeabi directory instead of the armeabi-v7a directory?
I think there are a couple questions here. First, can you put libssl and libcrypto in armeabi/. That's an Android question (not an OpenSSL question). I seem to recall Brian talking about this on the NDK mailing list (but I can't find it at the moment). I believe the idea is armeabi/ is a fallback if a more specific library is not found in, for example, armeabi-v7a/.
Second is, can you run ARMv7a version of libssl and libcrypto on other platforms. I believe ARMv7a added a few hypervisor extensions over ARMv7, so you should be OK since OpenSSL does not use them. However, you might find yourself in trouble if running on an older device with ARMv6 or ARMv5.
In this case, you might want to download an older version of the Android NDK that builds for ARMv5, and then place ARMv5 version of libssl and libcrypto in armeabi/. You can find older versions of the NDK at Android NDK about a third of the way down the page.
To be more specific, Android 2.2 is API 8, and it was released around May 2010. So you might want to fetch and build with Android NDK Revision 3 from March 2010. NDK R3 only supported armeabi and targeted ARMv5TE (from the CPU-ARCH-ABIS.TXT file). The download is http://dl.google.com/android/ndk/android-ndk-r3-linux-x86.zip.
OpenSSL does not follow the instructions at Standalone Toolchain for ARMv7a. Its missing the -mfloat-abi=softfp flag. You might have trouble calling a function that passes a float to the library from Java. There are not many of them, but one is RAND_add. The entropy estimate is passed as a float and after the incompatibility, your estimate will likely be 0.0f. See Hard-float and JNI on the NDK mailing list and [Bug #3080]: Android NEON and CFLAGS options.
Here's a note from the README's that you should also be aware of:
III.3. Automatic extraction of native code at install time:
-----------------------------------------------------------
When installing an application, the package manager service will scan
the .apk and look for any shared library of the form:
lib/<abi>/lib<name>.so
If one is found, then it is copied under $APPDIR/lib/lib<name>.so,
where $APPDIR corresponds to the application's specific data directory.
If you update the APK and nothing changes, then be sure to delete anything under lib\ or delte the APK first (they have a tendency to become "sticky").
Another issue you will likely encounter is building and compiling against 1.0.1. Be sure you provide a wrapper shared object with a different name. Otherwise, you will likely link against 0.9.8 at runtime, and not the 1.0.1 gear in your APK. That's because Zygote loads Android's version of OpenSSL, and that version is 0.9.8. Later, when Zygote forks to create your process, the link-loader will not map-in your version of OpenSSL because its already present from Zygote.
OpenSSL has 2 Android build options: android-armv7 and android-x86
I added android-x86 to the script in June 2014. I was able to get through the build with one patch: [Bug #3398] PATCH: fix broken compile on android-x86 with no-comp configure option. I don't have an x86 Android device, so I was not able to run the self tests on a device. Feedback is welcomed.