Apktool b error

When I run the same command but with sudo: sudo apktool b base I get this:
[sudo] password for mm:

I: Using Apktool 2.1.1
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
I: Checking whether sources has changed...
I: Smaling smali_classes2 folder into classes2.dex...
I: Checking whether resources has changed...
I: Building resources...
Exception in thread "main" brut.androlib.AndrolibException: brut.androlib.AndrolibException: brut.common.BrutException: could not exec: [/tmp/brut_util_Jar_2588416753999631477.tmp, p, --forced-package-id, 127, --min-sdk-version, 19, --target-sdk-version, 25, --version-code, 90, --version-name, 2017.20.177.471142, -F, /tmp/APKTOOL7722875278552765767.tmp, -0, arsc, -0, js, -0, bin, -0, arsc, -I, /root/apktool/framework/1.apk, -S, /home/mm/Desktop/Work/workdayMobile/prodWorkday/base/res, -M, /home/mm/Desktop/Work/workdayMobile/prodWorkday/base/AndroidManifest.xml]
	at brut.androlib.Androlib.buildResourcesFull(Androlib.java:437)
	at brut.androlib.Androlib.buildResources(Androlib.java:371)
	at brut.androlib.Androlib.build(Androlib.java:281)
	at brut.androlib.Androlib.build(Androlib.java:254)
	at brut.apktool.Main.cmdBuild(Main.java:224)
	at brut.apktool.Main.main(Main.java:84)
Caused by: brut.androlib.AndrolibException: brut.common.BrutException: could not exec: [/tmp/brut_util_Jar_2588416753999631477.tmp, p, --forced-package-id, 127, --min-sdk-version, 19, --target-sdk-version, 25, --version-code, 90, --version-name, 2017.20.177.471142, -F, /tmp/APKTOOL7722875278552765767.tmp, -0, arsc, -0, js, -0, bin, -0, arsc, -I, /root/apktool/framework/1.apk, -S, /home/mm/Desktop/Work/workdayMobile/prodWorkday/base/res, -M, /home/mm/Desktop/Work/workdayMobile/prodWorkday/base/AndroidManifest.xml]
	at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:436)
	at brut.androlib.Androlib.buildResourcesFull(Androlib.java:423)
	... 5 more
Caused by: brut.common.BrutException: could not exec: [/tmp/brut_util_Jar_2588416753999631477.tmp, p, --forced-package-id, 127, --min-sdk-version, 19, --target-sdk-version, 25, --version-code, 90, --version-name, 2017.20.177.471142, -F, /tmp/APKTOOL7722875278552765767.tmp, -0, arsc, -0, js, -0, bin, -0, arsc, -I, /root/apktool/framework/1.apk, -S, /home/mm/Desktop/Work/workdayMobile/prodWorkday/base/res, -M, /home/mm/Desktop/Work/workdayMobile/prodWorkday/base/AndroidManifest.xml]
	at brut.util.OS.exec(OS.java:97)
	at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:430)
	... 6 more
Caused by: java.io.IOException: Cannot run program "/tmp/brut_util_Jar_2588416753999631477.tmp": error=2, No such file or directory
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
	at brut.util.OS.exec(OS.java:90)
	... 7 more
Caused by: java.io.IOException: error=2, No such file or directory
	at java.lang.UNIXProcess.forkAndExec(Native Method)
	at java.lang.UNIXProcess.<init>(UNIXProcess.java:247)
	at java.lang.ProcessImpl.start(ProcessImpl.java:134)
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
	... 8 more

Introduction

Basic

First lets take a lesson into apk files. Apks are nothing more than a zip file containing resources and assembled java code.
If you were to simply unzip an apk like so, you would be left with files such as classes.dex and resources.arsc.

$ unzip testapp.apk
Archive:  testapp.apk
 inflating: AndroidManifest.xml
 inflating: classes.dex
 extracting: res/drawable-hdpi/ic_launcher.png
 inflating: res/xml/literals.xml
 inflating: res/xml/references.xml
 extracting: resources.arsc

However, at this point you have simply inflated compiled sources. If you tried to view AndroidManifest.xml. You’d be left viewing this.

P4F0fnversionCodeversionNameandroid*http://schemas.android.com/apk/res/androidpackageplatformBuildVersionCodeplatformBuildVersionNamemanifestbrut.apktool.testapp1.021APKTOOL

Obviously, editing or viewing a compiled file is next to impossible. That is where Apktool comes into play.

$ apktool d testapp.apk
I: Using Apktool 2.0.0 on testapp.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: 1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
$

Viewing AndroidManifest.xml again results in something much more human readable

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<manifest xmlns:android="https://schemas.android.com/apk/res/android" package="brut.apktool.testapp"
platformBuildVersionCode="21" platformBuildVersionName="APKTOOL" />

In addition to XMLs, resources such as 9 patch images, layouts, strings and much more are correctly decoded to source form.

Decoding

The decode option on Apktool can be invoked either from d or decode like shown below.

$ apktool d foo.jar
// decodes foo.jar to foo.jar.out folder

$ apktool decode foo.jar
// decodes foo.jar to foo.jar.out folder

$ apktool d bar.apk
// decodes bar.apk to bar folder

$ apktool decode bar.apk
// decodes bar.apk to bar folder

$ apktool d bar.apk -o baz
// decodes bar.apk to baz folder

Building

The build option can be invoked either from b or build like shown below

$ apktool b foo.jar.out
// builds foo.jar.out folder into foo.jar.out/dist/foo.jar file

$ apktool build foo.jar.out
// builds foo.jar.out folder into foo.jar.out/dist/foo.jar file

$ apktool b bar
// builds bar folder into bar/dist/bar.apk file

$ apktool b .
// builds current directory into ./dist

$ apktool b bar -o new_bar.apk
// builds bar folder into new_bar.apk

$ apktool b bar.apk
// WRONG: brut.androlib.AndrolibException: brut.directory.PathNotExist: apktool.yml
// Must use folder, not apk/jar file

Info In order to run a rebuilt application. You must resign the application.
Android documentation can help with this.

Frameworks

Frameworks can be installed either from if or install-framework, in addition two parameters

• -p, --frame-path <dir> — Store framework files into <dir>
• -t, --tag <tag> — Tag frameworks using <tag>

Allow for a finer control over how the files are named and how they are stored.

$ apktool if framework-res.apk
I: Framework installed to: 1.apk 
// pkgId of framework-res.apk determines number (which is 0x01)

$ apktool if com.htc.resources.apk
I: Framework installed to: 2.apk 
// pkgId of com.htc.resources is 0x02

$ apktool if com.htc.resources.apk -t htc
I: Framework installed to: 2-htc.apk 
// pkgId-tag.apk

$ apktool if framework-res.apk -p foo/bar
I: Framework installed to: foo/bar/1.apk

$ apktool if framework-res.apk -t baz -p foo/bar
I: Framework installed to: foo/bar/1-baz.apk

Framework Files

Example

Lets say you want to decode HtcContacts.apk from an HTC device. If you try you will get an error message.

$ apktool d HtcContacts.apk
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: 1.apk
W: Could not decode attr value, using undecoded value instead: ns=android, name=drawable
W: Could not decode attr value, using undecoded value instead: ns=android, name=icon
Can't find framework resources for package of id: 2. You must install proper framework files, see project website for more info.

We must get HTC framework resources before decoding this apk. We pull com.htc.resources.apk from our device and install it

$ apktool if com.htc.resources.apk
I: Framework installed to: 2.apk

Now we will try this decode again.

$ apktool d HtcContacts.apk 
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: /home/brutall/apktool/framework/1.apk
I: Loading resource table from file: /home/brutall/apktool/framework/2.apk
I: Copying assets and libs...

As you can see. Apktool leveraged both 1.apk and 2.apk framework files in order to properly decode this application.

Finding Frameworks

For the most part any apk in /system/framework on a device will be a framework file. On some devices they might reside in
/data/system-framework and even cleverly hidden in /system/app or /system/priv-app. They are usually
named with the naming of «resources», «res» or «framework».

Example HTC has a framework called com.htc.resources.apk, LG has one called lge-res.apk

After you find a framework file you could pull it via adb pull /path/to/file or use a file manager application. After you have the
file locally, pay attention to how Apktool installs it. The number that the framework is named during install corresponds to the pkgId of the
application. These values should range from 1 to 30. Any APK that installs itself as 127 is 0x7F which is an internal pkgId.

Internal Frameworks

Apktool comes with an internal framework like mentioned above. This file is copied to $HOME/apktool/framework/1.apk during use.

Warning Apktool has no knowledge of what version of framework resides there. It will assume its up to date, so delete the file during Apktool upgrades

Managing framework files

Frameworks are stored in different places depending on the OS in question.

• unix — $HOME/.local/share/apktool
• windows — %UserProfile%AppDataLocalapktool
• mac — $HOME/Library/apktool

If these directories are not available it will default to java.io.tmpdir which is usually /tmp.
This is a volatile directory so it would make sense to take advantage of the parameter --frame-path to select an alternative folder for framework files.

Since these locations are in sometimes hidden directories, managing these frameworks becomes a challenge. A simple helper function
(added in v2.2.1) allows you to run apktool empty-framework-dir to empty out frameworks.

Note Apktool has no control over the frameworks once installed, but you are free to manage these files on your own.

Tagging framework files

Frameworks are stored in the naming convention of: <id>-<tag>.apk. They are identified by pkgId and optionally custom tag. Usually tagging frameworks isn’t necessary, but if you work on apps from many different devices and they have incompatible frameworks, you will need some way to easily switch between them.

You could tag frameworks by:

$ apktool if com.htc.resources.apk -t hero
I: Framework installed to: /home/brutall/apktool/framework/2-hero.apk
$ apktool if com.htc.resources.apk -t desire
I: Framework installed to: /home/brutall/apktool/framework/2-desire.apk

Then:

$ apktool d HtcContacts.apk -t hero
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: /home/brutall/apktool/framework/1.apk
I: Loading resource table from file: /home/brutall/apktool/framework/2-hero.apk
I: Copying assets and libs...
$ apktool d HtcContacts.apk -t desire
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: /home/brutall/apktool/framework/1.apk
I: Loading resource table from file: /home/brutall/apktool/framework/2-desire.apk
I: Copying assets and libs...

You don’t have to select a tag when building apk — apktool automatically uses the same tag, as when decoding.

Smali Debugging

Warning SmaliDebugging has been marked as deprecated in 2.0.3, and removed in 2.1. Please check SmaliIdea for a debugger.

9Patch Images

• source — You know this one. You find it in the source of an application or freely available online. These
  are images with a black border around them.
• compiled — The mysterious form found in apk files. There are no borders and the 9patch data is written into
  a binary chunk called npTc. You can’t see or modify it easily, but Android OS can as its quicker to read.

There are problems related to the above two points.

• You can’t move 9patch images between both types without a conversion. If you try and unpack 9patch images from an apk and use it
  in the source of another, you will get errors during build. Also vice versa, you cannot take source 9patch images directly into an apk.
• 9patch binary chunk isn’t recognized by modern image processing tools. So modifying the compiled image will more than likely break the
  npTc chunk, thus breaking the image on the device.

The only solution to this problem is to easily convert between these two types. The encoder (which takes source to compiled) is built into
the aapt tool and is automatically used during build. This means we only need to build a decoder which has been in apktool since v1.3.0
and is automatically ran on all 9patch images during decode.

So if you want to modify 9patch images, don’t do it directly. Use apktool to decode the application (including the 9patch images) and then
modify the images. At that point when you build the application back, the source 9patch images will be compiled.

Other

FAQ

• Apktool builds unsigned apks. This means an entire directory META-INF is missing.
• New aapt binary. Newer versions of apktool contain a newer aapt which optimizes images differently.

These points might have contributed to a smaller than normal apk

There is no META-INF dir in resulting apk. Is this ok?

Yes. META-INF contains apk signatures. After modifying the apk it is no longer signed. You can use -c / --copy-original to retain these signatures. However,
using -c uses the original AndroidManifest.xml file, so changes to it will be lost.

What do you call «magic apks»?

For some reason there are apks that are built using modified build tools. These apks don’t work on a regular AOSP Android build, but usually are accompanied
by a modified system that can read these modified apks. Apktool cannot handle these apks, therefore they are «magic».

Could I integrate apktool into my own tool? Could I modify apktool sources? Do I have to credit you?

Actually the Apache License, which apktool uses, answers all these questions. Yes you can redistribute and/or modify apktool without my permission. However,
if you do it would be nice to add our contributors (brut.all, iBotPeaches and JesusFreke) into your credits but it’s not required.

Where does apktool store its framework files?

• unix —

  $HOME/.local/share/apktool

• mac —

  $HOME/Library/apktool

• windows —

  $HOME/AppData/Local/apktool

Migration Instructions

v2.6.1 -> v2.7.0

• Update apktool to v2.7.0
• apktool empty-framework-dir --force

v2.5.0 -> v2.6.0

• Update apktool to v2.6.0
• apktool empty-framework-dir --force

v2.4.1 -> v2.5.0

• Update apktool to v2.5.0
• apktool empty-framework-dir --force

v2.3.0 -> v2.3.1

• Update apktool to v2.3.1
• apktool empty-framework-dir --force

v2.2.4 -> v2.3.0

• Update apktool to v2.3.0
• apktool empty-framework-dir --force

v2.2.0 -> v2.2.1

• Update apktool to v2.2.1
• apktool empty-framework-dir --force

v2.1.1 -> v2.2.0

• Run the following commands to migrate your framework directory
• Apktool will work fine without running these commands, this will just cleanup abandoned files
• unix —

  mkdir -p ~/.local/share; mv ~/apktool ~/.local/share

• windows —

  move %USERPROFILE%apktool %USERPROFILE%AppDataLocal

v2.0.1 -> v2.0.2

• Update apktool to v2.0.2
• Remove framework file $HOME/apktool/framework/1.apk due to internal API update (Android Marshmallow)

v1.5.x -> v2.0.0

• Java 1.7 is required
• Update apktool to v2.0.0
• aapt is now included inside the apktool binary. It’s not required to maintain your own aapt install under $PATH. (However, features like -a / --aapt are still used and can override the internal aapt)
• The addition of aapt replaces the need for separate aapt download packages. Helper Scripts may be found here
• Remove framework $HOME/apktool/framework/1.apk
• Eagle eyed users will notice resources are now decoded before sources now. This is because we need to know the API version via the manifest for decoding the sources

Parameter Changes

• Smali/baksmali 2.0 are included. This is a big change from 1.4.2. Please read the smali updates here for more information
• -o / --output is now used for the output of apk/directory
• -t / --tag is required for tagging framework files
• -advance / --advanced will launch advance parameters and information on the usage output
• -m / --match-original is a new feature for apk analysis. This retains the apk is nearly original format, but will make rebuild more than likely not work due to ignoring the changes that newer aapt requires
• After [d]ecode, there will be new folders (original / unknown) in the decoded apk folder
• original = META-INF folder / AndroidManifest.xml, which are needed to retain the signature of apks to prevent needing to resign. Used with -c / --copy-original on [b]uild
• unknown = Files / folders that are not part of the standard AOSP build procedure. These files will be injected back into the rebuilt APK.
• apktool.yml collects more information than last version
• SdkInfo — Used to repopulate the sdk information in AndroidManifest.xml since newer aapt requires version information to be passed via parameter
• packageInfo — Used to help support Android 4.2 renamed manifest feature. Automatically detects differences between resource and manifest and performs automatic --rename-manifest-package on [b]uild
• versionInfo — Used to repopulate the version information in AndroidManifest.xml since newer aapt requires version information to be passed via parameter
• compressionType — Used to determine the compression that resources.arsc had on the original apk in order to replicate during [b]uild
• unknownFiles — Used to record name/location of non-standard files in an apk in order to place correctly on rebuilt apk
• sharedLibrary — Used to help support Android 5 shared library feature by automatically detecting shared libraries and using --shared-lib on [b]uild

Examples of new usage in 2.0 vs 1.5.x

v1.4.x -> v1.5.1

• Update apktool to v1.5.1
• Update aapt manually or use package r05-ibot via downloading Mac, Windows or Linux
• Remove framework file $HOME/apktool/framework/1.apk

Options

Utility

Outputs current version. (Ex: 1.5.2)

-v, --verbose

Verbose output. Must be first parameter

-q, --quiet

Quiet output. Must be first parameter

-advance, --advanced

Advance usage output

Empty Framework Dir

Force delete destination directory.

-p, --frame-path <DIR>

The location where framework files are loaded from

List Framework Dir

Info Added in v2.5.0

These are all the options when listing the framework directory.

-p, --frame-path <DIR>

The location where framework files are loaded from

Decode

The numeric api-level of the smali files to generate (defaults to targetSdkVersion)

-b, --no-debug-info

Prevents baksmali from writing out debug info (.local, .param, .line, etc). Preferred to use if you are comparing smali from the same APK of different versions. The line numbers and debug will change among versions, which can make DIFF reports a pain.

-f, --force

Force delete destination directory. Use when trying to decode to a folder that already exists

--force-manifest — v2.3.1 — Used for analysis

Forces decode of AndroidManifest regardless of decoding of resources flag. Will more than likely prevent rebuild as used for static analysis of the manifest.

--keep-broken-res — Advanced

If there is an error like «Invalid Config Flags Detected. Dropping Resources…». This means that APK has a different structure then Apktool can handle. This might be a newer Android version or a random APK that doesn’t match standards. Running this will allow the decode, but then you have to manually fix the folders with -ERR in them.

-m, --match-original — Used for analysis

Matches files closest as possible to original, but prevents rebuild.

--no-assets — v2.3.0

Prevents decoding/copying of unknown asset files.

-o, --output <DIR>

The name of the folder that apk gets written to

--only-main-classes — v2.4.1

Only disasemble dex classes in root (classes[0-9].dex)

-p, --frame-path <DIR>

The folder location where framework files should be stored/read from

-r, --no-res

This will prevent the decompile of resources. This keeps the resources.arsc intact without any decode. If only editing Java (smali) then this is the recommended action for faster decompile & rebuild

-s, --no-src

This will prevent the disassembly of the dex file(s). This keeps the apk dex file(s) and simply moves it during build. If you are only editing the resources. This is the recommended action for faster disassemble & assemble

-t, --frame-tag <TAG>

Uses framework files tagged via <TAG>

Rebuild

Loads aapt from the specified file location, instead of relying on path. Falls back to $PATH loading, if no file found. Unless $PATH references prebuilt custom aapt. This will more than likely not work.

-api, --api-level <API> — v2.4.0

The numeric api-level of the smali files to build against (defaults to minSdkVersion)

-c, --copy-original — Removal — v3.0.0

Copies original AndroidManifest.xml and META-INF folder into built apk. Scheduled for deprecation.

-d, --debug — v2.4.0

Adds debuggable="true" to AndroidManifest file.

-f, --force-all

Overwrites existing files during build, reassembling the resources.arsc file and dex file(s)

-n,--net-sec-conf — v2.6.2

Adds a generic Network Security Configuration file in the output APK.

-nc,--no-crunch — v2.4.0

Disable crunching of resource files during the build step.

-o, --output <FILE>

The name and location of the apk that gets written

-p, --frame-path <DIR>

The location where framework files are loaded from

--use-aapt2 — v2.3.2

Use the aapt2 binary instead of appt

Well, there
are many reasons why but I will show you most common errors. Note, i’m talking
about general apk modding, not system apk/framework modding

Assets.dex issue «Class xxx has already been
interned» and «Not a valid dex magic value»

By default,
apktool try to decompile dex from assets folder which would decompile to
smali_assets on a root directory of decompiled apk, and compiled to assets.dex
upon compiling

This can
cause compiling issues

Solution:

To fix the
problem, decompile APK again with the flag [code]—only-main-classes[/code] to
only decompile on main classes in root (classes[0-9].dex) then you can compile
without any problem

Note:
Only for apktool 2.4.1 and up

You can try
to delete .dex from assets folder or smali_assets/assets.dex but it may cause
problems

If you are
using APK Easy Tool 1.57 and above, you can enable the option «Only
disassemble the main dex classes» under Options -> Apktool. Again, only
for apktool 2.4.1 and up

Error: No resource identifier found for attribute
‘manageSpace’ in package ‘android’

The attribute
does not exist in the framework or it could be fake attribute to prevent compiling

Solution:

Remove android:manageSpace=»true» from AndroidManifest.xml

Error: String types not allowed

Issue: https://github.com/iBotPeaches/Apktool/issues/2462

Solution:

In this case:

This error
tells you which xml an error occured and which line

Open the XML file: E:(PathToDecompiledAPK)resvaluesdrawables.xml

Remove drawable name=»APKTOOL_DUMMY_1c2″ />  at line 5 and save the file

You will get another
error about public symbol. See below

Error: Public symbol XXX declared here is not defined.

Public symbol
does not exist in public.xml

Solution:

In this case:

W: E:(PathToDecompiledAPK)resvaluespublic.xml:1133: error: Public
symbol drawable/APKTOOL_DUMMY_1c2 declared here is not defined.

Open the XML
file: (PathToDecompiledAPK)resvaluespublic.xml

Remove <public type=»drawable»
name=»APKTOOL_DUMMY_1c2″ id=»0x7f0601c2″ /> at
line 1133 and save the file

Resource error (APKTOOL_DUMMY) (Split APK)

If you get
APKTOOL_DUMMY that’s generally because apktool can’t decode some of the
information in the original APK and creates a ‘dummy’ value instead. Because
there’s no things called APKTOOL_DUMMY in public.xml, the APK can’t be
recompiled. It’s likely because you try to compile splitted APK with some
missing infomation

Solution:

Merge split
APKs manually

https://platinmods.com/threads/how-to-turn-a-split-apk-into-a-normal-non-split-apk.76683

Or use the
SAP (Split APK Packer) tool

https://platinmods.com/threads/sap-split-apks-packer-by-kirlif-windows-linux-merge-split-apks-into-single-apk.101798/

Other issues

— APK is
protected, encrypted or obfuscated. Reversing of such files is beyond the
scope, so find out yourself

— Invalid syntax
in smali and xml. You may have done something wrong

You can
search for useful infomation on the following sites.

Report your
issues to them if you feel like to

Apktool: iBotPeaches/Apktool

Smali/baksmali: JesusFreke/smali

Сегодня я использовал apktoool для декомпиляции apk, и когда я скомпилировал его, я сообщил об ошибке и потерпел неудачу. Конкретная ситуация такова.
версия apktool: 2.3.4
Используйте следующую команду для декомпиляции apk:

apktool d dou2.apk -o test

Затем, после завершения изменения, используйте следующую команду, чтобы скомпилировать обратно

cd test
apktool b .

Затем сообщение об ошибке возвращается при компиляции назад:

W: ~/Downloads/dou2/./res/color/a77.xml:4: error: No resource identifier found for attribute 'alpha' in package 'com.xxx'
W:
W:~/Downloads/dou2/./res/color/a77.xml:5: error: No resource identifier found for attribute 'alpha' in package 'com.xxxx'

После прочтения ошибки кажется, что идентификатор ресурса не был найден при компиляции, поэтому я нашел решение в Интернете и, наконец, решил его следующим образом:
Добавить при декомпиляции apk-rПараметры следующие:

apktool -r d dou2.apk -o test

Потому что я не занимаюсь модификацией файлов ресурсов, поэтому добавлю-rПараметр не декомпилирует файл ресурса, поэтому при повторной его упаковке вы не будете сообщать об ошибке, что ресурс не найден.