I need to run my busybox from a Java Android app. To do this, I included a tar archive with busybox in apk res and unpack it to /data/data/com.exeample.test/files with permissions 755. But I can't run it from this location (permisiion denied).
The question arises, how to install binary files through the apk package in general? The question is very interesting due to the very thoughtful security of Android.
I will be very grateful for your help.
Ready-made binary executables are distributed only inside the apk package in the apk /lib/<ABI> directories (Taken from https://dvelopers.android.com). Otherwise, it will be at least very difficult to execute native code in Android. In the apk package, the /lib/<ABI> directories can contain files with different extensions, this is not limited. In order for the files to be unpacked when installing the apk package, you must set android:extractNativeLibs=true in the manifest (https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs).
For Android Studio users, you can create directories
app/src/main/jniLibs/<ABI> - for *.so files
app/src/main/resources/lib/<ABI> - for all other files including *.so.*
then they will be packaged in the /lib/<ABI> directories of the apk package.
From an android application, the path to the native library dir can be obtained by calling getApplicationInfo().nativeLibraryDir.
Related
I want to distribute my game for android, linux and windows in a single apk. So, I want to add linux and windows executables in the outermost folder in apk (so that users can easily reach them). Is that possible? They need not to be installed when somebody installs the app in android.
An APK is a zip file so you can add new files to it using a tool like 7-zip.
To avoid them being installed you can exclude them using the gradle script:
See this question for more info: Gradle How to exclude files from apk
In 3d party APK files I notice there are folders for different architectures - armv7, arm64, x86, mips - so a single APK works for multiple architectures, supported by Android.
However, I don't seem to find a way to do that with Qt projects. I have a project that targets multiple architectures, but I can only produce an APK for an architecture at a time, only for the currently active project kit.
Is it possible to produce such a muti-arch APK for a Qt projects?
I have found a work-around for this problem. I came across this problem when my Qt application had to comply to Google's requirement of providing 64 binaries for 64 bit architecture. Although this process is not totally automated but it works.
1- Build your APKs for different architectures(in my case armeabi-v7a and arm64-v8a)
2- Open all APKs for editing with any compression/decompression software(I used the default provided by Ubuntu. On windows you can use WinRaR)
3- Go to "lib" folder and copy the folder named with the architecture (arm64-v8a, armeabi-v7a, etc.)
4- Consolidate all the copied folders from step#3 into the lib folder of any one APK. Now we will use this APK to move forward
5- Go to the folder named "META-INF" on APK root and delete files *.RSA and *.SF
6- Now close the APK file.
7- Go to https://github.com/patrickfav/uber-apk-signer and download the Jar file. You can use this tool to zipalign and sign your package again. Use the jar as follows.
java -jar uber-apk-signer-1.0.0.jar --apks ./android-build-release-signed.apk --ks android_release.keystore --ksAlias your_certificate_alias
Now you can publish the final APK to Google Play. Cheers!
Is there a way to manually repackage an apk (that will successfully run on a real device). While we can use any zip tool to unpack our apk files, the reverse is not possible (due to some app signing issues and such ) so I'm wondering how to go about doing this. I don't want to build an apk (which would involve compling Java classes , resources etc). I just want to be able to create an apk file ( that will run on a device) manually (command line is ok), provided that I already have all the necessary files.
Thank you
I have an APK generated from eclipse which contains a native library packaged inside the APK.
I start a service when BOOT_COMPLETED is received. Normal version of SO file and APK runs fine.
I had setup the debug environment and tried to debug this app and native code.
Now the problem is if i install this through ADB install my.pack.age.app it gets copied to data/app and then i dont get the BOOT_COMPLETED Intent.
When i manually put this apk to system/app folder i get unsatisfied linker error as library not found. It is searching in path data/data/my.pack.age.app/lib.
I have the debug version of native library generated with gdbserver file and other gdb.setup and other things are setup properly for debugging.
How can i debug this apk while installing in the /system/app folder?
PS: Modifying the Packages.xml and packages.list by hand and changing the path of native library is not in my option as it would require every time to modify that file & may get corrupt installation.
I found the problem, For system APKs that are bundled with Device from OEM,
You have to put the library in System/lib folder for all the APk in system/app folder.
I was putting it packaged inside the APK.
How can I store a normal tree of files inside an Android .apk without all the weirdness of the Ressource or Asset concepts? It seems I have to do some akward thing to use Files from current path like any non-Android Java application do?
"use Files from current path" and "store... inside an Android .apk file" have nothing to do with each other.
Since, statistically speaking, you are likely familiar with Windows, let's draw some analogies.
"store... inside an Android .apk file" on Windows would be "store... inside a Windows .exe file". This is reasonably uncommon on Windows, at least the last I checked.
"use Files from current path" on Windows would refer to files that perhaps exist in the app's Program Files directory or the equivalent. On Android, this works fairly conventionally -- use getFilesDir() and Java file I/O.
What exists in Windows and does not exist in Android is the concept of packaging files to be installed at install time via an installer package, such as a .msi file.
Since you declined to tell us what the "normal tree of files" is and why you think it should be "inside an Android .apk", it is impossible to give you advice on how to avoid whatever "weirdness" you think exist in the "Ressource [sic] or Asset concepts". All I can tell you is that the equivalent on other OSes to bake files into the executable would likely be similarly "weird".
Okay, I haven't tested this, but a solution could be to add extra files to the APK before signing. You could automate this from the command line:
$ ant release
$ zip -r bin/MyApp-unsigned.apk <custom_folder>
$ jarsigner -verbose -keystore <keystore> -storepass <password> bin/MyApp-unsigned.apk <alias>
$ zipalign -v 4 bin/MyApp-unsigned.apk bin/MyApp-signed.apk
And then, in your activity, open the APK with ZipFile to access your custom folder:
ZipFile apk = new ZipFile(getApplicationInfo().sourceDir);
I'm not sure how the Android Market would react to this non-standard APK though.
With assets you can have a file tree in an APK, which can be accessed by using the AssetManager returned by getAssets().
The whole point of this mechanism is saving space. The files are not extracted to the file system when the app gets installed. When you read the content of an asset, it is uncompressed (unzipped) on the fly from the APK. It does make sense. Saving space is important on Android devices.
But nothing forbids you to extract the assets tree into the file system when your application is first launched, if you need that.
One approach that might work for you is to open the APK using ZipFile and ZipEntry, as this gives you access very similar to a conventional read-only directory structure.
Alternatively, you may be able to use getResourceAsStream to work with a traditional file structure - you might find this bug report useful if you go with this approach - it shows some perils of working with getResourceAsStream on android.
I should add that you shouldn't think of an APK as something gets extracted - files inside the APK are not on the filesystem, they're like resources inside a JAR file in a J2ME or J2SE environment (or the WAR/EAR for J2EE).
Hope this helps,
Phil Lello