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
Related
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.
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 a webkit plugin apk (just like the sample BrowserPlugin under development/samples). I want to integrate it into the system.img. I build it as the preload apk in /system/app/, but when the phone boot up, the apk is not installed properly.
If I install the apk in /data/app/ manually, it works well.
when the apk in /system/app/, the .so inside the apk can not be extracted to /data/data//lib/
Anyone know how to integrate the webkit plugin as a preload apk on Gingerbread, please kindly help me.
Thanks
.so file should be merged to the system.img separately. If it's a browser plug-in, it should be copied to /system/lib/plugins/<package_name>
It looks like there's no mechanism in android to extract .so file from an apk file that contains .so files if it's integrated with the system.
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
I am facing problem in creating the .apk file using the ant script . The generated .apk named as _unaligned.apk instead of .apk and on installing the _unaligned.apk file to the device I get force-close showing the java.lang.VerifyError exception, but the same apk generated using IDE works fine. I am struck on this for a long time. Can you share the build.xml file that generates the .apk file?
this Bloq entry explains all necessary steps. Especially if you want to customize your build script.
If your are looking for the actual build script, just look into your Android SDK folder platforms/android-X/templates. There should be a file called android_rules.xml.
I customized my build script to clean, build, sign and distributing the apk to an attached device. If you like, I can provide you with my script. Just contact me!
You'll need to use zipalign & sign your apk with some key; as long as you're testing the app you can simply use the debug key with ant debug
At least that's what I understand from this page which you may want to read carefully.
What ant command are you running at the command / terminal prompt?
I have been having different problems with manually running ant (Repackage apk file to contain custom assets what build tool to use) and there might be some info on that thread to help you.
Alternatively, remember that one needs to sign the apk file before deploying it (see Joubarc's link).