I want to make some changes to the stock Mms Android application and install it on my device. However, I have problems with compiling the code checkout obtained from git. I have created a new Eclipse Android project with "use existing sources", setting the target framework to 2.1. However, Eclipse does not find some needed framework classes, e.g. android.telephony.SmsManager.
I have the whole Android toolchain set up and working (make finished without errors), Eclipse is running on Sun Jdk 1.5.
Perhaps my mistake was that I did not copy the .classpath file into the new project, I will check this. Never the less, should I succeed, will I be able to install this .apk into a non-rooted device?
The stock Android applications are not designed to be built using the Android SDK, mostly because many of them predate that SDK. Right now, they can only be compiled as part of the firmware.
Even if you wind up with an APK, you will not be able to install it separately from a replacement firmware, unless you change the package in the manifest. You cannot have two applications on the device at the same time with the same package, and since you will not be signing your APK with the digital signature used by the firmware, yours will not be able to overwrite the existing one.
If you have a device that supports replaceable firmware (e.g., ADP2, Nexus One), you may be able to create, sign, and install your own firmware, then replace that APK in the future without replacing all of firmware a second time -- I don't know how well that works.
Related
Note - I am relatively new to Android and AOSP...
Where can I find the Android SDK in the AOSP? As we know, we build apk files in the android studio using the separately installed SDK. But for some reason, I wish to use the SDK in the AOSP if it is available. I see the source code of SDK in the AOSP; do we need to build it?
Why/How I have arrived at the above question:
I had created an .apk in the AOSP which had JNI files and dependency on some existing Broadcom libs (so). It is a system app. What I noticed is the .apk package does not contain the JNI libs but rather is copied to /system/lib folder separately. Hence I had a doubt how the .apk upgrade will work? Is it possible?
I assumed the .apk upgrade won't work that way and the .apk should be packaged including the JNI libs. Hence I planned to build the .apk in the studio and use the .apk as prebuilt and just sign it in the AOSP (we have the keys). Then I also wanted to allow the developers to build the .apk in AOSP itself by running the Gradle in the command line. I did so by adding the command to the Android.mk. But the point here is, it is still using the SDK installed in /home//Android/Sdk. But there may be build machines which may not have the SDK installed. So I am putting this question - Do we (where?) have the SDK in AOSP? Can I use that instead?
I tried to explain the problem.. in case it's not clear please let me know... Will try to give more details...
OTA update will work. Update with Package Manager - won't. This is normal for system apps with native libraries.
In AOSP applications are built differently depending on their location in build tree. Apps placed in ~/packages/apps and ~/device/some_vendor are system apps and they are handled differently by the system. One of differences is that during build process they are stripped of their native libraries and those libraries are simply copied to the /system/ partition.
Including pre-built apk is a good solution.
Yes you can build sdk yourself from sources. Yes, it's there. But I don't understand why you need that. Are there any changes to the API?
There are other options. For example, you can mangle your build scripts. Say, you can add a global FLAG that would disable lib stripping for system apps.
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.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
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 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...