I have an application that has been exported to an apk. I have stored some .wav music files on /sdcard/audio that are absolutely essential to the application. My question is this:
How do I export the wav files and make sure that they are present on the apk? When I export the project, the size of the apk is something like 23kB. It seems that I should have had the wav files somewhere else, in some other directory. I had added the files to /sdcard/audio by using mkdir + push commands in the adb.
Those type of files should be in /res/raw.
Files in the sdcard will not be pushed into the apk.
Assuming you had the .wav files on your virtual machine: it is essential you understand that this virutal machine had nothing to do with your apk. All the settings, downloads, uploads (like your wav) etc on this machine are just testing.
You could delete it and nothing really matters. Only your code in your project (if you're using eclipse: the code you see there, so your src, res etc dir's) will go in the apk. NOTHING from the emulator.
Now put them in a folder in your project like #macarse says: /res/raw
Related
I didn't find any clear documentation on obb, so I decided to contact here. In general, the apk does not detect an obb file on android. The file is located in the right directory, the apk itself runs normally.
As far as I understand, I don't need to do anything extra with obb in the code and just put it in obb/packagename. Maybe I'm wrong, so I really look forward to your help
upd. Maybe I need to do something in the code? I just put the obb in the right directory and nothing else.
Here is the trick:
step 1. create a folder as same as package name
step 2. copy the obb file into that folder
step 3. rename the obb file to main.BundleVersionCode.packagename.obb
step 4. copy the folder to your Android Phone directory: Android/obb/, or try to copy the folder to sdcard/Android/obb/ if you have external sd card.
Then now you should be able to install the apk.
Some time ago i uploaded to google play an app for my family restaurant which was something like showing the menu, timetable, prices..all that stuff. It's still in the google play and i have access to it by google developers but the problem is that i lost all the code.
Is there any way of recovering the data to add some new info and then update my app?
Thank you a lot.
You'll need a rooted device for this:
Install the app to your device, and then take the apk off of the device using:
Plug your “Rooted” Android device into your computer via the included USB cable.
From your adb command line (usually C:\android-sdk-windows\tools\) type adb shell and press enter
Switch to root user, type su and press enter
type “cd data/app“ and press enter
List all the installed apk files, type ls and press enter (find the one you want to extract)
In another command window, pull one of the files on to your computer by typing:
adb pull /data/app/application.apk name.apk and press enter
Once you have the apk, rename it to whatever.zip and extract it as a zip file. You will now see a bunch of folders. Anything in your assets folder can be recovered now right away. For the java code, you must use dex2jar to convert classes.dex to a .jar file. After that, you can use JD-GUI to read the code from the .jar file.
To extract AndroidManifest.xml and everything in res folder(layout xml files, images etc.) you must use APKTool
Run the following command :
apktool.bat d sampleApp.apk
It also extracts the .smali file of all .class files, but these are difficult to read, and you should use the code from dex2jar instead.
If you Obfusticate your code using progaurd while generating the APK file, then its not possible.
If not, you can decompile the classes some extent and making some changes to the decompiled class and you can get it working... There are few tools to decompile the APJK file
Thanks,
Is there a way in Eclipse ADT to ignore a certain set of files under the Package Explorer when exporting an APK package?
I have a PhoneGap application that reuses a whole bunch of js/css/images with another application, but currently the APK export is including everything under my "assets" directory, inflating the APK size as a result. Ideally, I only want certain js/css/image files under my "assets" directory to be included in the package instead of everything.
I don't think that there is any support in the SDK/API to achieve this directly but you put your shared resources into a directory on to the memory card and refer to them there from your app? Though your next question is how would you 'install' the shared images etc without including them in the .apk file.. which I'm not sure of the answer.
How the .apk installation process works on device? Is the .apk file just copied to some place and kind of installer application extracts the application information, register somehow the application to environment, extract also the icon and put it on the application launch screen? Or the .apk content is extracted and files are copied to various folders and the .apk file itself is deleted?
I am asking to understand if there is any possibility on device to browse the .apk file structure and its content and access in read-only mode directly the assets, res folders, AndroidManifest.xml, the dex file and also used libraries (.jar or .so)?
The reason I am asking is that I am looking for possibility to read into memory .dex, .jar or .so files like arbitrary binary files (e.g. by using the File class) for the purpose of computing a message digest from its content (i.e. using md5 or other hash method)...
BR
STeN
The APK is copied onto the device, usually into the /system/app directory. The APK is not extracted or unzipped until it is used, so if you want to probe the files you'll need to do the decompression and extraction yourself.
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