I have a feeling I know the answer to this question, but I figure I would see what SO had to say.
I'm hoping to create a console app that can take an .apk file and extract metadata (such as version name/version number). I'm able to use PackageManager.getPackageArchiveInfo() from my Android app just fine, but I'd need to be able to call it from the command line. However, the classes in the android.jar appear to just be stubs, so it doesn't end up working.
Does anyone know of a way to do that?
For apks for which you do not have the signing certificate, you cannot access the contents of the apk beyond seeing that the contents exist.
As you noted, the android.jar is stubs. This is because the android system relies on native code which is designed to run on ARM processors and (probably) wouldn't run on your system. So, they package stub versions of all the java code and the only way to 'run' the actual library is to be executing in a vm with a full version of the android.jar, which would be an ARM environment ( a real handset or a emulator).
There could be ways to setup a 'console' app to do this, but it would have to be communicating with an Android VM to get a working version of the android.jar. I'm guessing that might be more effort than you'd want to sink into this.
I was able to open the .apk file and view it's contents (including AndroidManifest.xml) with WinZip...
'Hope that helps...
Related
I have been working with standard android for some time. Recently I have been building android sdk for windows and find some interesting things in Android build env. There is a command called lunch which can be used to list all available targets to build. However, it does not list sdk and its variants,even though they are valid options.
Does anyone know why is that the case?
Also can I build any specific module in Android sdk without building the whole sdk. (It could be a great help as I dont wanna build the whole sdk, if I gonna do a small change in one component.)
Thanks
Under the hood, lunch uses make, so if some pieces of SDK do not change, they won't be rebuilt.
My speculation about your first question: rebuilding SDK was never considered a major task of lunch. It is most often used to port or mod the system and produce an installable system image, and receive the ADK as by-product. Later, people realized that often (with root access to the device) you can iterate over one component without need to reinstall the whole system image.
Is there some way to get the android SDK build process to do partial updates on the actual device? Whenever I make a change it has to rebuild the apk file and deploy it, which seems wasteful, and is slow (especially with the dex defect).
The copying to the device isn't an issue here, it is fast enough. So the emulator doesn't appear to solve my problem. Is there perhaps a way to test the code without producing the APK file for the emulator?
What you want is Test Driven Development (TDD). This article will start you off right :
http://pivotal.github.com/robolectric/
Is there some way to get the android SDK build process to do partial updates on the actual device?
Not presently. It's something they are considering for a future overhaul of the build system, though I think there are other capabilities that are considered to be higher priority..
Is there perhaps a way to test the code without producing the APK file for the emulator?
Not with standard Java-based Android development. Any sort of compiled environment pretty much needs the code to be compiled in order for it to be run.
I have built an Android app that worked fine on Android 2.3.* and 4.0.*. However, after upgrading my device to Jelly Bean (4.1.1), I found my app does not work properly (crashes, ANRs, etc.) any more.
As a temporary workaround, I am wondering if it is possible to pack an earlier version (say Android 2.3) of the Android framework JAR into my APK and force all my code to use classes/APIs in that JAR?
I think including the JAR in my APK should be easier. But I have no idea how I could force my code to use classes/APIs in the JAR during run-time.
I know it is not a decent fix (hacking, package size, legal issue, etc.) even it will work. But I am just curious whether it is feasible.
Any suggestions or hints would be appreciated!
(Edit)
I have tried the following:
Extracted the /system/framework/framework.odex from an Android 2.3 ROM;
Deodexed it and converted it into a JAR file (say framework.jar);
I verified framework.jar and it contains the actual framework code, not stub methods;
Put framework.jar into the libs folder of my project and built out the APK;
I verified the result APK and the android framework classes are indeed included.
However, it seems my code is still using the classes/APIs of the actual version of SDK installed in the Android device. :(
(Edit)
It seems all the framework/core classes are already pre-loaded from the device (/system/framework/framework.odex) by Zygote during system boot-up time, for performance reason. So even I have included those classes in our APK, the pre-loaded ones will still be instantiated instead.
This sounds like a dead end to me... :(
As a temporary workaround, I am wondering if it is possible to pack an earlier version (say Android 2.3) of the Android framework JAR into my APK and force all my code to use classes/APIs in that JAR?
That is not possible, sorry. What you think of as "the Android framework JAR" has no code -- it is merely stub implementations of the classes and methods exposed in the Android SDK. The real Android framework resides in the firmware, and you cannot replace it.
I'm developping a android's aplication using some shared
libraries written by me and compiled with ndk-r5b. The application works,
y and the calls to the libraries works too, but I detected some errors,
segmentations faults, and I need to debug it, but, I don't know how debug
native code from android and I don't know if I can generate core dumps,
as in linux, for debug my libraries.
Any idea?
The ndk comes with ndk-gdb, which supposedly allows you to debug native applications. Also, if you download the whole andriod open source project, they also have some version of gdb used for debugging. Look in the docs/ folder of the ndk to learn about using it. This tutorial might also prove helpful: http://vilimpoc.org/blog/2010/09/23/hello-gdbserver-a-debuggable-jni-example-for-android/
However, as shown in a recent question I asked: Running ndk-gdb with package not found error on motorola phone I still can't get it to work.
Edit: You said in the comments you were using a Samsung Device: Samsung decide to wreck havoc on some of the crucial internals required for native debugging, but it's easily fixable if you have root access to the device. If you use the --verbose flag, you'll probably find that the error is different than that, a package unknown error. That's because it's looking in /data/system/packages.list, but samsung renamed that file to /dbdata/system/packages.list. So if you make a symlink to that file in /data/system/packages.list, (requires root access) it should work. Or at least so claims the ndk mailing list: http://osdir.com/ml/android-ndk/2011-03/msg00036.html
I need to edit the original Android Apps from packages
in terms make my own distro/mod..
I want to make changes to the In Call screen, lock screen, contacts, calendar etc..
I understand that for doing this I will have to build everything from
source,
however I need to edit the source and to do so I need to open the OS provided apps as
eclipse projects,
When I did I saw that there are
missing imports which are hidden in the SDK (or missing)
hidden parameters within the classes..
I don't want to use reflection since the whole code is here and
available, but how do you build a platform development kit..
or PDK ?:)
Can any one help?
You start by reading the documentation.
EDIT:
If you are trying to download some single project from AOSP and compile it using the SDK, odds are very strong that it will not work, and that you will encounter problems like the ones you cite. You do not build Android by building individual apps; you build Android ("my own distro/mod") by building the entire firmware. Most AOSP applications are not designed to be compiled by the SDK, but need the whole firmware.
Please check Using eclipse to browse and edit AOSP. You can atleast edit your code using eclipse, but you will have to use AOSP build system to build your distro.
You might also check Debugging Android Java Framework services as that would help debug your changes.
Just open Eclipse,
then go to "window" +"preferences" +"android"
there you will get sdk location,then give the appropriate path of the android sdk for proper run...