I would like to inject a few dynamic resources into the assets folder of the APK. Though I'm having no luck so far.
I was trying to inject some files to the APK as a zip archive using python script using output.packageApplication.doLast, but it doesn't add the files to the APK and generates the usual apk. I've checked whether it does anything with it and surprisingly it does, but it deletes the custom files and leaves only the compiled ones.
Can anybody shed some light?
Related
I have a project with native libraries that I want to use, files with this format: lib<name>.so do get included into apk. But files with <name>.so format does not.
Is there a way to include the later type into apk in lib directory?
If not, is there a way to include the files into a directory inside apk, where I can load it from my native code?
The short answer is "no". The native binaries will only be packed into APK, and extracted to executable files upon installation, if their names follow the lib….so pattern.
Note that these libraries will be extracted to files according to the ABI of the target system. The installer does not check the actual properties of the file. The decision is based on the name of the folder under lib in the APK structure.
If you add the attribute extractNativeLibs=false to the application tag in AndroidManifest.xml of your APK, the installer (on Android Nougat and higher) will not extract the native libraries.
You can trick the system and have files that don't follow the above rule to the lib folder of APK, but there is very little sense in it, because they will never be extracted by the loader (it may also extract file gdbserver if the file is there).
The common practice is to put the arbitrary files in the assets folder of your APK, and extract them programmatically when the app runs for the first time after install. You cannot extract these files to the secured location where the usual native libraries go. You should not extract the native libraries to sdcard (e.g. getExternalFilesDir()), because the system may not allow execution of the files there, regardless of the execute access flag on the file. Make sure that you use the correct ABI flavour.
You can peek at the source code of Nougat native lib loader that can load native libraries from the APK without extraction, and use it to load your custom libraries directly from the assets folder of your APK.
Is there any way to get to .js files with code created with Appcelerator from compiled .apk?
I lost a source coude of one of projects and now have only .apk files and would like not to rewrite the whole code.
Thank in advance
If you would like to do this manually:
In release version of the app, Titanium puts all of the assets into Java class called AssetCryptImpl, you would have to decompile apk and look for that class file in the sources.
AssetCryptImpl file will contain private method called initAssetsBytes, which returns one large chunk of data as CharBuffer, which contains encrypted data for all of the asset files. The other method called initAssets, will contain all of the original asset filenames and also ranges for each of the asset files.
Asset data is encrypted using AES in ECB mode, and last 16 bytes from asset data are the decryption key. Asset decryption method implementation is inside JNI library but its not hard to rewrite. filterDataInRange will call native code to decrypt the resource.
You can easily rewrite filterDataInRange method, with your implementation, which will get the key and decrypt the resource data and write it to file. And write a method which will call readAsset for each filename from HashMap, from initAssets method.
If you want one click solution:
You can use the tool called ti_recover.
Install it with node package manager:
npm install ti_recover
Than use it from terminal/command line:
ti_recover apkfile.apk outputdir
Depends on how the Titanium app was built. If it's an emulator build, then yes, you can get the JavaScript files. If the apk is from a device or dist build, then no.
For device and dist builds, Titanium minifies and encrypts all JavaScript, then injects it into the Java code before compiling it.
So if you have an apk from an emulator build, you can just rename the .apk to .zip and unzip and the JS files will be there.
One thing to note is if your app is an Alloy app, then you'll only get the compiled Alloy code, not the original Alloy code. That means you won't find any .xml views, .tss styles, etc.
This Website might be your best bet. It uses a range of technologies to decompile .apk files.
You can try making a new folder and copy over the .apk file that you want to decode. Rename the extension of this .apk file to .zip (e.g. rename from filename.apk to filename.zip) and save it. After extructing, Now you can access the classes.dex files, etc. Also, in Asset folder you will get the resources. Though you can't get the .js file by following this process. You can use this http://www.javadecompilers.com/apk website. But still it will give you a java dicompilation.
Hi and hope someone may be able to help.
I'm writing an app that is based on some original artwork and I'm wanting to store several large (Adobe Illustrator) files in the same folder as the app's package. Because these files are large I don't want them to be included when I get to the stage of exporting the app to an apk file.
Traditionally I'd use the assets folder for this but the contents of this folder would get compiled into the apk file.
Does anyone have any suggestions for folders that won't get compiled in the export process.
My thanks
I have an enterprise app which I am deploying manually (no Google Play) which uses a number of .so libraries for mapping (ArcGIS). However, the .so files (arm, armv7a, x86) in the libs folder blow the .apk size out from 3mb to 21mb. I dont particularly want to remove one of the .so files (removing support for that architecture), or mess around with one .apk per architecture.
Can anyone think of a way I can update my app without including the .so files in each update .apk?
Yes, you can have the Java portion of your app manually download the appropriate .so files into your app's internal storage folder and mark them executable.
You will then have to load them with System.load() and the full pathname of the .so file, rather than System.loadLibrary() and the trimmed library name.
The biggest issue here is that you are now responsible for matching the ABI's yourself, and more importantly, providing your own protection against being tricked into installing a modified or imposter library which might do something nefarious in the name of your app and using it's permissions.
Of course you have to make sure not to try to call any of the native methods before you have installed them.
You could also consider delivering the .so files as binary assets each in its own skeleton .apk having a shared user id (and matching certificate) as your main .apk
Or you could simply make platform-specific .apk's for each target, containing only one .so, and have your distribution system pick the right ones (though that doesn't help with the upgrade problem).
I want to save all intermediate files (C/C++ files after preprocessing, the .i and .ii) when building Android (compiling the source), but don't know how.
Anybody got some idea?
That is pretty easy, all intermediate files are put in the out folder, which is created when you build. Just copy the out folder somewhere else to save all the intermediate files.
I do this quite frequently when I have to build for different targets (e.g. product and sdk build, which will clean each others intermediate files). By e.g. just copying out to out-sdk, and then I can copy it back when I have to do another sdk build later. Saves quite a bit of time.