Modifying android.jar Files on Device (building the aapt, ecj, dx and apksigner packages)

[SDRausty]

Modifying android.jar might better than adding libraries. Hence this issue is devoted to rewriting the android.jar file.

[HemanthJabalpuri]

@SDRausty
android.jar is available at runtime in android os.

So modifications to it may lead problems.
Also it needs root and different versions of android uses different updated android.jar.

So it is not a good idea to modify it.

[SDRausty]

@HemanthJabalpuri do you know the steps to compile and decompile android.jar?

Also it needs root

[09:15~]$ find $PREFIX/ -name android.jar -exec ls -og {} \;
-rw------- 1 3881775 Jul 22 14:39 /data/data/com.termux/files/usr/share/java/android.jar
-rw------- 1 3340986 Jun 19 14:14 /data/data/com.termux/files/usr/share/aapt/android.jar

Why do you state that root is needed?

[SDRausty]

@HemanthJabalpuri can you test https://github.com/BuildAPKs/buildAPKs.samples on device with https://github.com/sp4rkie/debian-on-termux please?

[HemanthJabalpuri]

@SDRausty
Sorry for late reply.

android.jar = /system/framework/framework.[apk & jar] + others too.

We are not compiling android.jar, i.e., we are only including it as classpath assuming that the target device have that in its bootclasspath.
All android devices bootclasspath has framework.jar for executing apps.

So if we want to modify android.jar, we also need to modify framework.jar in device too.

So modifying /system partition needs root.

Also https://github.com/BuildAPKs/buildAPKs.samples app compiled fine without Linux Distribution.

[SDRausty]

including it as classpath

Unifying native artifacts should be a simple solution. File bootclasspath.sh is created to ease inegrating of native libraries that are present on device.

Reference from #2 (comment)

assuming that the target device

MSDKVERSIO="$(getprop ro.build.version.min_supported_target_sdk)" || printf "%s" "signal ro.build.version.min_supported_target_sdk ${0##*/} generated"
 
MSDKVERSION="${MSDKVERSIO:-14}"

TSDKVERSIO="$(getprop ro.build.version.sdk)" || printf "%s" "signal ro.build.version.sdk ${0##*/} generated"

TSDKVERSION="${TSDKVERSIO:-23}"

sed -i "s/minSdkVersion\=\"[0-9]\"/minSdkVersion\=\"$MSDKVERSION\"/g" AndroidManifest.xml 

sed -i "s/minSdkVersion\=\"[0-9][0-9]\"/minSdkVersion\=\"$MSDKVERSION\"/g" AndroidManifest.xml 

sed -i "s/targetSdkVersion\=\"[0-9]\"/targetSdkVersion\=\"$TSDKVERSION\"/g" AndroidManifest.xml 

sed -i "s/targetSdkVersion\=\"[0-9][0-9]\"/targetSdkVersion\=\"$TSDKVERSION\"/g" AndroidManifest.xml

Reference from build.one.bash#L123&#L130

[SDRausty]

Also https://github.com/BuildAPKs/buildAPKs.samples app compiled fine without Linux Distribution.

@HemanthJabalpuri the reason this was requested:

test https://github.com/BuildAPKs/buildAPKs.samples on device with https://github.com/sp4rkie/debian-on-termux please?

Are the errors important? Oh yes, much so.

The BuildAPKs modules/repositories and forks are selected because they compile on device in Termux. Can they compile in a PRoot environment as well as in Termux?

compiled fine without Linux Distribution.

Studying the errors in debian proot has shed a little more light on this subject. I would like to hear your opinion about the errors encountered.

BuildAPKs was recently modified to run after one tap inside a debian proot environment. The script sets up fine, and runs as it should except for the fact that compiling even a single APK is impossible in debian on device. I would like to 👂 hear your opinion about the errors BuildAPKs shows in debian proot on device...

[SDRausty]

@HemanthJabalpuri you mentioned:

All android devices bootclasspath has framework.jar for executing apps.

$ grep -r colorPrimary /system/framework/
Binary file /system/framework/framework-res.apk matches

Referencing Parsing Project Configuration Files #1 issuecomment-534638948:

number of errors / type of error
4813 error: Error: No resource found that matches the given name: attr 'colorPrimary'.

It appears that you are absolutely correct:

$ mkdir tmp
$ cd tmp
$ unzip  -q /system/framework/framework-res.apk
$ grep -r colorPrimary .                                
Binary file ./resources.arsc matches
$ dpkg -S aapt 
.
aapt: /data/data/com.termux/files/usr/share/aapt/android.jar                                                    
.
$ cp /data/data/com.termux/files/usr/share/aapt/android.jar .
$ cp /system/framework/framework-res.apk /data/data/com.termux/files/usr/share/aapt/android.jar

[SDRausty]

Results:

$ grep colorPrimaryDark android.jar 
$ grep colorPrimaryDark /data/data/com.termux/files/usr/share/aapt/android.jar
colorPrimaryDark

$ ~/buildAPKs/build.github.bash google
.
.
.
Running: grep -iC 4 ERROR /data/data/com.termux/files/home/buildAPKs/var/log/stnderr.git.orgs.google.log | tail
res/menu/menu_main.xml:4: error: No resource identifier found for attribute 'orderInCategory' in package 'android'
res/values/styles.xml:4: error: Error retrieving parent for item: No resource found that matches the given name 'Theme.AppCompat.Light.DarkActionBar'.
res/values/styles.xml:8: error: Error: No resource found that matches the given name: attr 'colorAccent'.                                                       
res/values/styles.xml:6: error: Error: No resource found that matches the given name: attr 'colorPrimary'.                                                                                                                                      
res/values/styles.xml:7: error: Error: No resource found that matches the given name: attr 'colorPrimaryDark'.

Any ideas why aapt doesn't add colorPrimaryDark to the build even though colorPrimaryDark is in android.jar?

[SDRausty]

aapt doesn't add colorPrimaryDark to the build even though colorPrimaryDark is in android.jar

This commit e705a9a resolves aapt doesn't add colorPrimaryDark.

[HemanthJabalpuri]

@SDRausty
Since according to your output of grep, you can simply add framework-res.apk to aapt with -I flag of aapt.

[SDRausty]

@HemanthJabalpuri thank you for sharing;
This 29f76de commit adds

framework-res.apk to aapt with -I flag

The verbose output states Including resources from package: /system/framework/framework-res.apk.

However Error: No resource found that matches the given name: attr 'colorPrimaryDark' and similar still persist after further testing.

$ grep -r colorPrimaryDark /system 2>/dev/null | wc -l
76
$ grep colorPrimaryDark /system/framework/framework-res.apk 2>/dev/null | wc -l 
1

[SDRausty]

add framework-res.apk to aapt with -I flag of aapt

Commit 2fec19a adds support for including many artifacts with the -I flag to aapt. The result still appears to be unchanged and the error continues.

[SDRausty]

Notes about jar files used by BuildAPKs:

# Create an android.jar with AndroidManifest.xml and resources.arsc:

• https://github.com/termux/termux-packages/blob/master/packages/aapt/build.sh

# Package classes.dex into jar:

• https://github.com/termux/termux-packages/blob/master/packages/ecj/build.sh

# Dex the rewritten jar file:

• https://github.com/termux/termux-packages/blob/master/packages/dx/build.sh

jar cf apksigner.jar classes.dex

• https://github.com/termux/termux-packages/blob/master/packages/apksigner/build.sh

How feasible is it to create these packages and jar files on device with Termux on the fly?

[github-actions]

Stale issue message