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.
Related
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.
I am working on a Java application that will run on an embedded system - a custom android build or modified AOSP. It is built on a linux server.
I would love to use an IDE like Eclipse with all its goodies like code completion, source code checking etc. but it seems very complicated. I looked at Puri's blog here
for one, the build process of our custom android uses Android.mk makefiles.
How can I (Should I?) modify the Eclipse build process to build the custom android build?
You can use either eclipse or studio to maintain a custom, pre-installed application.
In either case, you will not use the IDE to build the actual application image. That will be built as part of the make from the root of the AOSP install(1)
You can, however, create a project whose root is the directory in either /device or /package that contains your app.
Once you've done that, read the Android.mk file to find dependencies. Add them to the project as you would for any other project, for your chosen IDE.
If you go for eclipse, I suggest that you put the build directory somewhere in /out, or outside the AOSP directory altogether. If the root make file finds it, it can be a problem.
When you need to test your app on a device or an emulator, use mm to build only your app.
Better yet, if possible, do most of the development for your app as you would any stand-alone app, so that you can easily install and test it. Only put it in the AOSP directory as part of the release process.
Note, you can use either eclipse or studio to kick off that system
build. In eclipse, use External Tools. Studio provides similar
capabilities
When I install my app on a genymotion simulater device,it can not be installed well,on console I got "INSTALL_FAILED_CPU_ABI_INCOMPATIBLE"
I trid another app,it installed fine.I do not know why.
The application (certainly a game) must be ARM only.
Genymotion is a x86 platform, so compile the application to target x86.
You may be able to install ARM support manually :
http://forum.xda-developers.com/showthread.php?t=2528952
If you are using IntelliJ it may be related to the project's default configuration. IntelliJ will assume, unless otherwise specified, that Native libraries will be stored in the Libs folder. This is usually where developer store their JAR libraries. IntelliJ build process will package up the JAR file into the Native file folder in the APK.
If you experiencing this problem, you can find a good How-to:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE Intellj
This helped to resolve the issue I had.
You might want to check out my answer here:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE on device using intellij
I know it's written for IntelliJ, but you could be running into a similar issue with Eclipse where it thinks that some normal Java files or jar libraries are native code and including it in the compiled APK. A quick way to find out is to open up the final APK (it's just a jar file, so most utilities should be able to decompress it) and make sure that the only things you see are META-INF, res, AndroidManifest.xml, classes.dex, and resources.arsc. It's possible that there are other valid files in a normal Java Android application, but in general if you see anything else in there, particularly a libs folder, it's probably the result of the compilation process thinking that those other things are native libraries (compiled C/C++ code using the JNI).
If this is the case, you'll need to configure Eclipse to not interpret the Java libraries you're using as native code. Now, I don't personally use Eclipse so I don't know where the proper settings would be, but based off of this answer, it looks like Eclipse automatically assumes that the libs folder in the root of your project contains native libraries. The easiest solution may be to move any Java libraries you are using into a different folder (such as libraries).
http://blog.iteedee.com/2014/02/android-install_failed_cpu_abi_incompatible-intellj/
The INSTALL_FAILED_CPU_ABI_INCOMPATIBLE error is generated when you attempt to install an android application on a device with an unsupported CPU architecture. This error is usually related to the native libraries that are not packaged up for the device’s CPU architecture (ie: x86, ARMv6, ARMv7, etc).
Now, if you have an application that doesn’t use any native libraries or *.so file you might be scratching your head on this one. If you use IntelliJ IDEA IDE for your android development it might be packaging all of your related .JAR file in to the Native Library file location in your APK.
The cause of the same problem was different in my case.
I had added some dependency jars in /libs directory of my Android app project. One of these jars had exported library in jar format; i.e. a jar within a jar file. I've noticed that the apk created using jars with such structure are incompatible with x86 based devices (don't know why).
I want to assemble ".smali" and make new ".apk" in an Android application. I don't have so much time to do this so I have to use some source code that already exists.
There is an Apktool project which can build on Windows/Mac OS X/Linux, but I want to build it on Android.
I also tried to include the "apktool.jar" as an external library in an Android Application Project in Eclipse, but it failed.
After some research, it seems more clear that I need only the following two projects running on Android:
Smali (independent project)
JarSigner (from OpenJDK)
And, Apktool is not necessary.
This project has what I need:
https://code.google.com/p/java-ide-droid/
Requirements
JRE 1.6 (Java Runtime Environment)
aapt command in a PATH
basic knowledge of what is SDK, aapt, PATH, smali and Google search engine may be useful
This is from the apktools official website. Because it needs aapt, it seems quite hard to use apktools in an Android app. But if you can get the source code and compiled in an aosp environment, it could possibly make it run on the Android side.
Yes, there is a program also named apktool, but which runs on Android! Just have a look at http://code.google.com/p/apktool.
As of 2022, Yes there is a mobile version of Apktool, it is however not developed by iBotPeaches it's developed by Maximoff.
It's called Apktool M, you can grab the latest stable version from the link below.
https://maximoff.su/apktool/?lang=en
As far as stability goes it's definitely stable for Android 12 as far as I've tested.
Because I'm also a security freak, I ran it through about 7 different AV scanners to make sure I wasn't installing some hogwash virus masquerading as a legit app, and all of the scan results returned nothing malicious.
As far as usage goes it definitely decompiles APK's like Apktool as far as I've tested, however I don't expect it to work on every APK though.
According to the documentation,
Apktool M uses the following open source projects:
Apktool-android
aapt, aapt2
Commons IO
Apktool
antlr4
apksig
smali, baksmali, dexlib2
guava
jadx
textwarrior
axml
unapkm
imagetracerandroid
ZipAligner-for-Android
Dex2Jar_Android_2x
AndroidX
AndroidSVG
PhotoView
I want to make some changes to the stock Mms Android application and install it on my device. However, I have problems with compiling the code checkout obtained from git. I have created a new Eclipse Android project with "use existing sources", setting the target framework to 2.1. However, Eclipse does not find some needed framework classes, e.g. android.telephony.SmsManager.
I have the whole Android toolchain set up and working (make finished without errors), Eclipse is running on Sun Jdk 1.5.
Perhaps my mistake was that I did not copy the .classpath file into the new project, I will check this. Never the less, should I succeed, will I be able to install this .apk into a non-rooted device?
The stock Android applications are not designed to be built using the Android SDK, mostly because many of them predate that SDK. Right now, they can only be compiled as part of the firmware.
Even if you wind up with an APK, you will not be able to install it separately from a replacement firmware, unless you change the package in the manifest. You cannot have two applications on the device at the same time with the same package, and since you will not be signing your APK with the digital signature used by the firmware, yours will not be able to overwrite the existing one.
If you have a device that supports replaceable firmware (e.g., ADP2, Nexus One), you may be able to create, sign, and install your own firmware, then replace that APK in the future without replacing all of firmware a second time -- I don't know how well that works.