The following article explains the folders and the files that you would get from decompiled APK file. The decompiled APK folder structure is totally different from unzipped APK folder though you can find a couple of existence of same folder.
This folder is the same assets folder used in Android project. Files found in this folder are internal resources like data files, fonts, tools and images. Files of assets folder are accessed using URI via AssetManager as follows.
AssetManager assetManager = getAssets();
InputStream inputStream = assetManager.open("img/image1.png");
This folder contains metadata of Kotlin classes which are mapped to the existing types on the JVM platform. We have nothing to do with these files when it comes to app modification. We better leave it as-is.
All the native libraries goes in this folder. If your APK uses native functions created in C++ then it must be there in this folder as SO files where SO stands for shared objects. If app developer wants a fast performance or hide something from the modder's eye, then native libraries are their choice. The native files are difficult to reverse but not impossible.
The APK is actually following JAR (Java Archive) format which is just a compressed file of all the resources / files used to execute the application. The zip file also contains an additional file called MANIFEST.MF in META-INF folder. When it’s being executed, the manifest file is used to know about the resources that the zip file contains and their metadata. The manifest file will be automatically created when you sign the APK build.
The is the same res folder that you find in Android Project. It has layouts, images, raw files, colors, styles, texts and values. If you want to change the app’s appearance, then this is the folder that you have look into. As long as you do simple modification like changing texts or colors, you are good to go ahead without worrying other things. But if you add anything new or delete any existing item, then you have to make sure that you are making the changes in the other associated files too. For example if you are adding UI component in a layout file then you have add the component id in both public.xml and ids.xml files too. Like that, if you deleted any widget from layout, you need to remove the id from those files.
This folder has the decompiled byte codes. You can find the smali version of all the classes that are included either directly or indirectly in the app. If the app was created with proguard enabled, then the names of classes, methods and variables should have been obfuscated. You can find only alphabets instead of conventional names. If you want to modify the app flow, add any new screen or change existing screen, then this is the folder that you need to do it. Analyse the smali files and have good understanding of how they are referenced with each other before making any changes.
If the app is multidex enabled, then you can find this type of folders in the decompiled resources. Basically, a smali (smali_classes) folder is created for each dex file exist in the APK build. If you are looking forward to app modification, then you need pay attention to the smali files exists in these folders too.
This folder contains files / folders that are not part of the standard AOSP (Android Open Source Project) build procedure. These files will be injected back into the rebuilt APK.
This folder is used by apktool when you rebuild the app from the decompiled files. Make sure you clear this folder when you do rebuild otherwise your modified resource shall not reflect on the new apk.
This folder has your rebuilt APK file. I recommend to remove the APK file from this folder before rebuilding one.
Decoded AndroidManifest file
This file contains the metadata of decoded APK build.