Can I use AAPT to add a version code to an APK? - android

I have been told that there is a way to use aapt's --version-code option to add/insert a version code into an APK whose manifest doesn't define one. However, I haven't found any examples of people doing this (except for https://groups.google.com/forum/#!msg/adt-dev/XjehZDzfXhk/g2sWBC37_I4J, which links to a dead page and isn't even the same thing I am trying to do) if indeed it is possible to do.
Currently aapt d badging example.apk run on the apk in question returns something like
package: name='com.example.core' versionCode='' versionName='1.0.0'
sdkVersion:'8'
In my manifest I currently have the versionName defined as a string in an xml file, so I can pull it in with something like android:versionName="#string/app_version_name" (inside the manifest tag). However, if I try this with the version code it doesn't seem to want to resolve the reference. It tries to literally set the version code to the path I enter and then fails as it isn't an integer.
I've tried to do something like aapt p --version-code 100 example.apk but it seems to want to package up a whole project and expects a directory of files as input, not an apk file. (I assume that is the default behavior of aapt p[ackage])
Is it possible to set the version code of an APK after it has been built using the aapt tool? If so, what is the correct syntax?

This solution will not use aapt directly, but it will behind the scenes.
You can use Android APKTool to open you APK, alter the AndroidManifest.xml file, adding the version info; and then use APKTool again to repack. That tool is opensource and uses aapt. Thus you can look at its code to figure out how to do it using aapt directly.

Related

Specifying the element uses-sdk in AndroidManifest makes the manifest unparsable at runtime, when AAPT is used

I observe a real weird problem: I build .apk package using base tools as aapt, d8 and so on.
The manifest file has the following line:
<uses-sdk android:minSdkVersion="24" android:targetSdkVersion="32"/>
If I try to deploy the .apk , then the following problem reported by the packageinstaller:
2022-05-07 11:45:07.491 5998-5998/com.google.android.packageinstaller W/PackageInstaller: Parse error when parsing manifest. Discontinuing installation
And a user see the following message:
But if I remove the element "uses-sdk" from the manifest, then the app gets installed without a problem and works. But it looks like it considers a very low target number. What did I do wrong?
Note: the build procedure doesn't use Gradle, it uses 7Bee. I can provide github link to the app, if you are interested in.
When I looked in an addressing the issue, I found the following:
AAPT is discontinued
AAPT2 has to be used now
AAPT2 a gets version information as parameters of a run
AAPT2 produced result has to be signed using the apksigner SDK tool
APK has to be prepared by the ApkBuilderMain SDK tool
The ApkBuilderMain needs to be patched because not allows META-INF directory in APK content
After addressing all these items, APK got normally packaged and works.

How to define v7 appcompat dependency correctly?

I'm trying to get an (inherited) Android project to build. I'm using Ant & command line tools (and IDEA).
In styles.xml, there are references that cannot be resolved such as:
<style name="AppBaseTheme" parent="#style/Theme.AppCompat.Light">
This is the original error I ran into:
[...]/res/values/styles.xml:8: error: Error retrieving parent for item:
No resource found that matches the given name '#style/Theme.AppCompat.Light'.
I then noticed that project.properties has this appcompat reference which is broken on my (OS X) machine:
target=android-18
android.library.reference.1=../../../../adt-bundle-linux-x86_64/sdk/extras/android/support/v7/appcompat
I tried to fix that by making the reference relative to ${sdk.dir}:
android.library.reference.1=${sdk.dir}/extras/android/support/v7/appcompat
So now that path should be correct. But now when I run ant debug:
BUILD FAILED
/opt/android-sdk-macosx/tools/ant/build.xml:573:
/opt/android-sdk-macosx/extras/android/support/v7/appcompat resolve to a
path with no project.properties file for project /Users/joka/devel/project/
So, any ideas? What's the simplest way to get this project built?
(Please note that Ecplise-specific advice won't be useful to me.)
Edit: The Android SDK installation looks like this:
As Jay indicated, only relative paths will work on Unix/Mac.
For the Ant build to work, I also needed to generate build.xml for the appcompat project, using the command android update project -p <dir>, in my case:
/opt/android-sdk-macosx/tools/android update project
-p /opt/android-sdk-macosx-r22.0.1/extras/android/support/v7/appcompat
The exact config for me was:
android.library.reference.1=../../../../../../../opt/android-sdk-macosx/extras/‌​android/support/v7/appcompat
(This also works in local.properties, which I think is a better place since the same path won't work for all developers.)
I merely promoted my comment from 6 months ago into an answer as someone suggested.
By the way, now that I actually know something about Android development, I'd urge anyone who has the chance to ditch Ant and look into the new Gradle-based build system which is totally sweet in comprarison. It is CI-friendly and makes it easy to automate useful things (like using different package name and app icon for different build types). Stack Overflow will help when you run into problems.
Using the support libraries with Gradle, you'd skip all the above hassle and simply do:
dependencies {
compile "com.android.support:appcompat-v7:18.0.+"
}
I ran into the same problem, so I tried using a relative path and that fixed the problem for me. It looks like only relative paths work with android.library.reference. I did a quick search to verify this, and came across this stackoverflow link which indicates that absolute paths will work with android.library.reference on Windows, but not on Unix or Mac.
Peace.
Your path seems to be wrong (you are missing the 'compatibility' part).
The v7-appcompat library is at
{sdkpath}/extras/android/compatibility/v7/appcompat
for me (SDK Tools version 22.0.5 on Max OS X 10.7.5)

where does aapt look for resource identifiers

I am trying to build an android application from the command line (the one described at "Minimal" source files to create Android app using Eclipse + ADT ) and aapt is failing with some errors.The errors look like:
AndroidManifest.xml:1: error: No resource identifier found for
attribute 'versionCode' in package 'android'and are repeated once
for each attribute in AndroidManifest.xml.
The command I am running is:aapt package -M AndroidManifest.xml -S res -J genSo I think I am somhow failing to define for aapt where to look for resource identifiers. Is this correct?How do I tell aapt where to look for resource identifiers?I am running Android Asset Packaging Tool, v0.2.
Thanks, Jim.
edit:I should have included a link to the page with the source I copied:http://stackoverflow.com/questions/11888398/minimal-source-files-to-create-android-app-using-eclipse-adt
The Best example I found on Internet so far to create android app is https://geosoft.no/development/android.html also in case if you are using support libraries app theme, it would be difficult to figure out how to create R.java classes, I would suggest you to use this reference answerHow to compile an Android app with aapt2 without using any build tools? by which you will be able to use android.jar's general theme without any dependency on any support library.

Javah cannot find specified lib for jni/android-ndk

So, I have tried everything that I know of possible. I ran an export CLASSPATH=/path/to/bin/classes, and it still isn't able to find the output. I've tried running the command from $PWD/bin/classes, the project's root, and STILL am having troubles getting this to work properly. I have the latest version of the ndk (r8-1 at the time of this writing) and the sdk as well. Generating header files via command line, etc.
So far, I've seen Javah error while using Jni, as well as another question which specified the same problem and received the same answers.
I'm running Arch Linux (Archbang, specifically) in x86_64.
Here's my invocation and output (executed from $PROJECT_ROOT/bin/classes):
javah -d ../../jni com.example.fibonnacinative.libfib
Error: Could not find class file for 'com.example.fibonnacinative.libfib'
I've tried with the -classpath, -verbose, etc. flags and neither appear to help. -classpath just spits out the same error, and -verbose does not give me any information apart from the output I've posted.
Halp?
Yup! It was based on my stupidity.
I should have followed casing conventions for LibFib by typing com.example.fibonnacinative.LibFib as opposed to libfib.
Note: the class itself is typically camel case, whereas the rest of the package directive is lowercase. These are just conventions, mind you.
Sorry folks.

Why does Python fail to run ant build?

If I run ant release in the shell in my dir proj it works fine, however, when I try to execute it from python, it fails, why?
/Users/hunterp/proj
Buildfile: /Users/hunterp/proj/build.xml
BUILD FAILED
/Users/hunterp/proj/build.xml:46: sdk.dir is missing. Make sure to generate local.properties using 'android update project'
It is difficult to answer this question without more information about your setup or the code you are using. Particularly the parts that are generating the error since we don't know what your code looks like (either in build.xml or in your python script).
An easy thing to start with, as indicated by #Mark, is to <echo>${basedir}</echo> in your release task to see where exactly it thinks it is running from. My guess is that you are trying to load a properties file or some such and it isn't finding it in an earlier step.
What you can do if the location of ${basedir} looks different when run from within the directory versus within your python script is use a reference to where your build.xml file lives and reference from there:
<dirname property="project.basedir" file="${ant.file.project_name}"/>
Then use use ${project.basedir} instead of ${basedir}.
All of this assuming, of course, that your ${basedir} appears differently between the two. Otherwise I'd need to know more in order to diagnose the issue.

Categories

Resources