Develop Reference

Changing the package name

I planned to change the package name through smali(reverse)
when I open up apktool.yml, I saw this
forced-package-id: '127'
I have tried to change it but it crash
why should i do?

Assuming your goal is to rename the package name of the apk, the package names used for the classes are irrelevant. The package name of the apk is mostly unrelated to the package names of any classes in the apk. And there's no reason you need to touch the package id.
I would recommend unpacking the apk with apktool, and then edit the apktool.yml, setting renameManifestPackage to the new package name. Then when you rebuild the apk with apktool, it should use aapt's --rename-manifest-package functionality to change the package name.
After that, just resign the new apk and you should be good to go.
apktool d app.apk
// change "renameManifestPackage: null" in app/apktool.yml
// to "renameManifestPackage: my.new.package"
apktool b app -o new_app.apk
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore ~/my.keystore new_app.apk mykeyname
And just to reiterate, you don't need to modify the package names of any classes.

To my knowledge there are no fast ways to change the package name.
You have to change the package="com.mycompany.myapp" in Manifest.xml and then manually replace all the package name occurrences in smali files (and folders). Finally edit apktool.yml replacing the old package name, with your new package name.
A full detailed tutorial can be found here: http://forum.xda-developers.com/showthread.php?t=2760965

I've tried different approaches but the most reliable for me has been the method described here:
https://forum.xda-developers.com/t/how-to-guide-mod-change-package-names-of-apks.2760965/
These are the steps:
Decode APK (using apktool)
Edit apktool.yml
Edit AndroidManifest.xml
Rename smali subfolders
Search & Replace *.smali (using Notepad++)
Build APK (using apktool)
Sign APK (using apksigner)
Tools needed:
Apktool - https://ibotpeaches.github.io/Apktool/
Notepad++ - https://notepad-plus-plus.org/downloads/
apksigner - https://developer.android.com/studio/command-line/apksigner
Download apktool and wrapper script to C:\apktool.
Let's assume you want to modify from/to as specified here:
From: XVipreSettings.apk (Package name: com.xvipre.settings)
To: ModdedApp.apk (Package name: com.modded.app)
1. Decode APK (using apktool)
apktool.bat d XVipreSettings.apk
2. Edit apktool.yml
apkFileName: XVipreSettings.apk
...
renameManifestPackage: null
is changed to:
apkFileName: ModdedApp.apk
...
renameManifestPackage: 'com.modded.app'
3. Edit AndroidManifest.xml
package="com.xvipre.settings"
is changed to:
package="com.modded.app"
4. Rename smali subfolders
move .\XVipreSettings\smali\com\xvipre\settings .\XVipreSettings\smali\com\xvipre\app
move .\XVipreSettings\smali\com\xvipre .\XVipreSettings\smali\com\modded
5. Search & Replace *.smali
Start Notepad++
Menu > Search > Find in Files... (Ctrl+Shift+F)
Find what : "Lcom/xvipre/settings"
Replace with : "Lcom/modded/app"
Filters : "*.smali"
Directory : "C:\apktool\XVipreSettings\smali\com"
Press Replace in Files (may take a few minutes)
6. Build APK
apktool.bat b XVipreSettings -o ModdedApp.apk
7. Sign APK
(I'm assuming 31.0.0 here yours may be different, also if you don't want to sign using debug certificate you need to modify this step accordingly)
%homedrive%%homepath%\AppData\Local\Android\Sdk\build-tools\31.0.0\apksigner.bat sign --ks %homedrive%%homepath%\.android\debug.keystore --ks-pass pass:android --key-pass pass:android C:\apktool\ModdedApp.apk

Cyrillic app name incorrectly encoded during porting Android app to Blackberry

I have small problem with displaying cyrillic app name on PlayBook and BB10 simulator. Looks like it's incorrectly encoded from russian.
Problem appeared after updating bb eclipse plugin from version 1.3 to 1.5, with plugin v.1.3 it worked just ok.
I'll appreciate any help or ideas.
Here is screenshot from bb10 simulator:

I found workaround myself.
When I got problems with encodding with bb eclipse plugin, I decided to do the same thing with comandline tools.
After tools setup (sing keys, debug tokens, etc), I've tried to repackage my apk file with this command (source apk file was in apk/ folder and destination for bar file was bar/ folder)
./apk2bar apk/ -d bbplaybookdebugtoken.bar -t bar/ -a "zasadnyy" -cg
When I've got .bar file, I've installed it with command:
/batchbar-deploy bar/ 192.168.1.35 mysecretpass
Unfortunatelly result was unsuccsessful, app name was incorrectly encoded again. After first fail I've read documentation a bit more and tried to use this approach: http://developer.blackberry.com/android/documentation/creating_a_custom_manifest_file_2016828_11.htm...
When I unzipped bar file and opened MANIFEST.MS - I've found this line:
Application-Name: –ì–µ—Ä–æ–∏
According to documentation solution should be quite strainforward:
1. Rename MANIFEST.MS to <you apk name>.mf
2. Update incorrect properties, in my case I've changed line from above to "Application-Name: Герои"
3. Put edited manifest file in the same folder as <your apk name>.apk and rerun apk2bar tool with **-m** parameter, e.g.:
./apk2bar apk/ -d bbplaybookdebugtoken.bar -t bar/ -a "zasadnyy" -m -cg
Repackage, deploy, run and ..... and again FAIL. Application name was "–ì–µ—Ä–æ–∏".
After second fail, I decided to make dirty hack, I've edited MANIFEST.MF directly in repackaged bar file (Unzip -> edit manifest -> zip -> change file extension to .bar).
Deploy updated .bar file to playbook and .... YEAH, we've got cyrilic app name!
Conclusion and FIX:
Looks like in 1.5 release if apk2bar tool manifest encoding is misconfigured (in ver. 1.3 it worked just ok)
In oder to FIX issue: Unzip unsigned bar file -> edit manifest -> zip -> change file extension back to .bar

I had the same problem I believe, but the symptoms have been different. I was not even able to install the app on my test device and explicitly running blackberry-signer -verify confronted me with the Invalid signature file digest for Manifest. error.
The MANIFEST.MF file seems to be properly encoded in utf-8 by the apk2bar tool, but the following signing process seems to read this using the platform's default encoding. I added the following java parameter to the blackberry-signer.bat as well as the apk2bar.bat batch file scripts of the command line tools to make it work properly:
-Dfile-encoding=utf-8
(This is for version 1.5.2 of the tools)

How to build i686-linux-android-gfortran for android-ndk8b (x86 arch Android)?

I tried building i686-linux-android-gfortran using build-gcc.sh following this
(it's for androdindk-7b) but I get error about link.h. I added link.h from here, but it gives further more errors.
Has anyone tried enabling i686-linux-android-gfortran for x86 Android?

From https://groups.google.com/forum/#!msg/android-ndk/QR1qiN0jIpE/g0MHkhTd4YMJ as selalerer suggested. I didn't try this, so I'm posting as a community wiki for reference purposes.
Fortran for x86 Android
=================
The guide is based on this one, many thanks to Phil:
Compiling Android NDK with Objective-C-enabled gcc errors
1) Download and unpack Android NDK 'android-ndk-r8c', (the older -r8b NDK won't work due to missing link.h!):
wget http://dl.google.com/android/ndk/android-ndk-r8c-linux-x86.tar.bz2
2) Create somewhere a folder called 'toolchain-src' (e.g. inside the folder android-ndk-r8c),
'cd' to this new folder
3) Make sure to have git installed ('yum install git' or whatever..) and download
the toolchain sources:
git clone https://android.googlesource.com/toolchain/build.git
git clone https://android.googlesource.com/toolchain/gmp.git
git clone https://android.googlesource.com/toolchain/gdb.git
git clone https://android.googlesource.com/toolchain/mpc.git
git clone https://android.googlesource.com/toolchain/mpfr.git
git clone https://android.googlesource.com/toolchain/expat.git
4) Create the folder 'binutils', 'cd' to this directory, unpack
binutils-2.23 there:
wget ftp.gnu.org/gnu/binutils/binutils-2.23.tar.gz
tar -xvzf binutils-2.23.tar.gz
You should now have a folder toolchain-src/binutils/binutils-2.23
5) Change to folder toolchain-src/build, edit the Makefile.in, changing the line:
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
to
--with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran
6) In the file android-ndk-r8c/build/tools/build-mingw64-toolchain.sh change the line:
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++"
to
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++,fortran"
7) In the file android-ndk-r8c/build/tools/build-gcc.sh, change the line:
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-plugin"
to
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin"
8) In the file android-ndk-r8c/build/tools/build-host-gcc.sh, change the line:
ARGS=$ARGS" --enable-languages=c,c++"
to
ARGS=$ARGS" --enable-languages=c,c++,fortran"
And change the line
ARGS=$ARGS" --disable-libquadmath --disable-plugin --disable-libitm --disable-bootstrap"
to
ARGS=$ARGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin --disable-libitm --disable-bootstrap"
9) Build your new toolchain:
/your/path/to/android-ndk-r8c/build/tools/build-gcc.sh -j1 --gmp-version=5.0.5 --mpfr-version=2.4.2 --mpc-version=0.8.1 --binutils-version=2.23 --gdb-version=7.3.x /your/path/to/toolchain-src /your/path/to/android-ndk-r8c x86-4.7
(don't worry about messages like 'expr: warning: unportable BRE:')
10) And go down to your knees in front of the screen, praying to the Lord that somehow these
countless configure scripts doing checks that nobody needs, using an ugly shell language
that cooks your brain with indentation going from right to left, will somehow manage to
compile a zillion of far too small files (so that 10% of the time is spent on compilation
and 90% on starting up GCC), and after an hour of watching progress with
tail -F /tmp/ndk-YourUserName/build/toolchain/config.log
your toolchain will be magically ready. You'll find it in the android-ndk-r8c/toolchains folder.
11) Finally, 'cd' to the folder
'/your/path/to/android-ndk-r8c/toolchains/x86-4.7/prebuilt/linux-x86/i686-linux-android'
and run this command:
ln -s ../libexec libexec
Without this command, it may happen that g++ raises the error message
"g++: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found".
Using strace, I found that g++ looks in the wrong folder, but the link
above lets it find the file liblto_plugin.so nevertheless.
And here are a few lessons learned on the way, so that Google finds this page:
*) To speed up the compilation, you can remove the '-j1'. But only after you got
it to work once, since building in parallel on multiple CPU cores was reported to
cause additional troubles.
*) The error message "Link tests are not allowed after GCC_NO_EXECUTABLES" shows up
when linking fails for x86 (works for ARM). The reason is that GCC does not include
the proper ANDROID_STARTFILE_SPEC and ANDROID_ENDFILE_SPEC from
gcc-4.6.1/gcc/config/linux-android.h. GCC 4.6.1 only specifies them for ARM, but not
for i386, GCC 4.8.0 however does. The GCCs downloaded from Google also do,
so best use Google's GCC.
*) The error message "fatal error: link.h: No such file or directory" also happens
with Google's GCC, and apparently (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50877)
only when you enable additional languages like objc or fortran.
The bug thread is here: http://gcc.gnu.org/ml/gcc-bugs/2012-08/msg00494.html
MIPS has link.h in android-ndk-r8b/platforms/android-9/arch-mips/usr/include
In android-ndk-r8c, link.h is now also present in android-9/arch-x86/usr/include/link.h,
so this bug was fixed.
*) The error message "fatal error: quadmath_weak.h: No such file or directory":
It also happens with the latest gcc-4.8, so we can just continue using Googles GCC 4.7.
Google itself uses --disable-libquadmath, but we additionally need --disable-libquadmathsupport
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648). So this needs to be added in
android-ndk-r8c/build/tools/build-gcc.sh
and
android-ndk-r8c/build/tools/build-host-gcc.sh
*) The error message "error: Pthreads are required to build libatomic"
Happens when building the ARM version of gcc-4.8 downloaded from gnu.org,
better stay with Google's GCCs.
*) The GCC that came with android-ndk-r8c didn't work for me (error message about
libstdc++.so.6 being too old), while the one in android-ndk-r8b worked
without problems. Since the android-ndk should support as many environments
as possible, I'm not sure why the Googlers decided to depend on a newer libstdc++,
but the good news are that building your own toolchain solves the issue.
*) If you get an error while compiling generic-morestack.c, then replace
#ifdef linux
// On Linux, the first two real time signals are used by the NPTL
with
#if defined(GLIBC) && defined(linux)
// On Linux, the first two real time signals are used by the NPTL

android ant build: debug and release targets

According to the 'help' target documentation:
debug: builds the applications and
signs it with a debug key
release; builds the application: the
generated APK file must be signed
before it is published
Here is what I found, which is a bit different than what I expected:
debug: ignores keystore definitions in build.properties whether you specify them or not. Which kesystore file is it using? The same as Eclipse: the default debug.keystore file in your Documents and Settings?
It creates two files:
-debug-unaligned.apk (signed, unaligned)
-debug.apk (signed, aligned)
release: 'help' says it doesn't sign it. It creates these files:
-unsigned.apk (unsigned, unaligned)
The next two are only if you have the values specified in build.properties:
-unaligned.apk (signed, unaligned)
-release.apk (signed, aligned)
Any helpful comments / verifications will be greatly appreciated.

Which kesystore file is it using? The same as Eclipse: the default debug.keystore file in your Documents and Settings?
Yes.

As far as the release target goes, you will get behaviour like this:
If you have lines like:
key.store=c:/users/me/my-release-key.keystore
key.alias=release_alias
key.store.password=myStorePassword
key.alias.password=myAliasPassword
in your build.properties, it will automatically build and sign your apk with no prompting for anything.
If you comment out the last two lines, then it will prompt you for the passwords, then complete a signed build if the passwords are OK.
If you don't have any of the above lines, then it will just build you an unsigned apk with no prompting for anything and end with:
-release-nosign:
[echo] No key.store and key.alias properties found in build.properties.
[echo] Please sign C:\dev\projects\AntBuilds\MyProject\bin\MyProject-unsigned.apk manually
[echo] and run zipalign from the Android SDK tools.
.

This answer works for me, I am using ant to auto-compile android app, it prompts and need password, I wrote one file named password, and using the command ---ant release < passwd,
However, it also prompts that I need input password.
Using the tips here
key.store=c:/users/me/my-release-key.keystore
key.alias=release_alias
key.store.password=myStorePassword
key.alias.password=myAliasPassword
I solved this problem.

How to update digests in Android MANIFEST.MF?

We need to enable our customers to update some components in Android application, like icon/logo, dictionary file etc.
I saw the .APK can be opened like a JAR with 7-zip, and hope files can be edited/replaced there. But it is need to update MANIFEST.MF file in it, containing a digest for each .APK component' like:
Manifest-Version: 1.0
Created-By: 1.0 (Android)
Name: res/raw/icon.png
SHA1-Digest: 6Un2G/VIkYfIGfMxruadIHtDABc=
Name: res/raw/logo.png
SHA1-Digest: zsIQqGWSu9w5m7gsl0jQoziy7JA=
...
How to update these digests?

The SHA1-digest entries are base64-encoded strings of digests computed using SHA1 algorithm. You'll also have to update Cert.rsa and Cert.sf though, the .rsa file contains the actual digital signature. You can start with http://java.sun.com/developer/Books/javaprogramming/JAR/sign/intro.html for more info.