Hello,
i installed an application that uses png images files...now i want to replace some of them with mine. I can extract thoose pngs from the apk in windows with winrar fine. So i know the file name, but when i search for thoose files in Android they are not there. So where do my installed apps go in the Android file system? Do they stay in the apk? Can i modify them there? I tried modifying the apk before installing it wich resulted in a failed installation
Can i manually deodex the framework and apps by deleting each individual .odex file?
Smonic said:
Can i manually deodex the framework and apps by deleting each individual .odex file?
Click to expand...
Click to collapse
No, u need some soft to do so. Deodexing add the .odex content files into your compressed .apk (correct me if i'm wrong ^^)
Zipalign deodex files make them reading faster by your OS
All of your apps on your device are packaged as .apk files; these files are compiled from google source code and can interchangeably be viewed/thought of as a compressed folder (like a .zip or a .rar); and all of your framework components (well most…) are packaged as .jar files which literally stands for Java Archive (so again this can be compared to a .zip or a .rar).
When the android OS want’s to run your apps or utilize its framework components, it has to parse (read/interpret) the compressed data held within your .apk and/or.jar files. What the odex file structure aims to do, is to expedited this process by utilizing another file (.odex file) to compliment every.apk file (and .jar file); the odex file, includes the most critical data in an uncompressed format so the android os can quickly interpret that important information before parsing through the rest of the data held within the compressed .apk files (and .jar files). So subsequently, in an .odex file structure the .apk & .jar files don’t include all of the applications/framework-components data; Essentially, two files are acting as one; for your apps there are .apk files + their corresponding .odex file and for your framework components there are .jar files + their corresponding .odex file. This works nicely as an optimized file structure, except in the circumstance when the user want’s to theme; theming requires a modification to your .apks; the image files (.pngs) held within the pngs are replaced with different ones. However it is impossible to theme an application if it exists as two files. So that is why it is said you need to be DeOdexed in order to theme; DeOdexing is the process of re-bundling that uncompressed critical data (.odex files) back into your compressed .apk (& .jar) files, so that now all of the data is included in the .apk files necessary to run your applications without the presence of .odex files; in addition all the data is now included within the .jar files necessary to utilize your framework components without .odex files. In a DeOdexed file structure, there are no odex files present.
Click to expand...
Click to collapse
Source : http://www.wugfresh.com/guides/deodex/
I don't think so.... but if yes, then it'll be very hard!
Hi,
anyone know how to manully update an installed classes.dex file in /data/dalvik-cache? The original classes.dex of the apk differs from the installed one. Android seems to process/modify it first before placing in dalvik-cache.
Anyone know how to do that manually? It would be a lot faster to just replace the dex file instead of the whole apk if you frequently have to change it.
Decompile the dex file using baksmali/smali scripts if you need to make an edit to classes.dex. then copy then over to where they need to go.
If that makes sense
sent from my T989 full of CM awesomeness and a touch of Venom from the Darkside!!
That doesn't work. Like i said above it differs from the apk one and i cannot just extract and replace it in dalvik-cache.
DexOpt: expected optimized DEX, found unoptimized
Click to expand...
Click to collapse
I tried to use 'dexopt' manually but it looks like its not intended to be run at shell level and 'dexopt-wrapper' wants the apk (to odex). That wouldn't lead to any speed benefits.
Any ideas?
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider. I've used the latest apktool (2.3.4) to unpack and repack the apk. I'm replacing it from TWRP and I checked that it has the same owner and rights. And after rebooting the device never finishes booting up (stuck at Samsung logo and blue led).
If I boot back to recovery and put back the original framework-res.apk the system boots fine.
What else do I need to do to make it accept the modified framework?
hey
Are you ONLY modifying the apk?
I would say there is a lot of things to check. It could be that the apk is being rejected by your handling of it. Compare both versions by 7zip lz4 without extracting. Try and use the best tools during the process.
Also more than likely you're conflicting with a service or permission that a perfect apk can't fix.
Have you tried a search in your ROM to see if any files might be associated with the result you want?
Stuff like...
com.android.location.provider.jar
com.android.location.provider.odex
com.android.location.provider.xml
Try doing all the work from your phone without any windows apps. FX explorer and symlink the apk.
Now that everything I said was probably wrong, someone else can tell you how. I'd try fx and symlink, though. It may just align the planets for you
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
@wirespot - Did you ever solve the problem you described in this thread?
Not really. My last attempt was to use Runtime Resource Overlays (RROs) to override certain framework values in order to allow org.microg.nlp to run side by side with Google's service.
I will provide them below but it ultimately didn't work. The RRO apk was installed correctly, I could access the NLP settings in the system settings but the main app still could not detect or connect to the service and none of the apps that use location would work.
If anybody else wants to build or use the RRO apk I'm attaching the relevant files as well as the apk. Please note that the built apk only has "org.microg.nlp" as service in arrays.xml (but I provide an arrays.xml with all three services).
apktool.yml is provided as txt file because it wouldn't let me upload it otherwise, remove the .txt. It's used if you build the package with apktool. Remember that you'll also have to generate your own certificate and sign the package in order to install it.
Also some links that may help:
https://forum.xda-developers.com/t/guide-how-to-make-gsis-overlay-file-for-your-phone.3878974/
https://github.com/ReinhardStrauch/framework-res-overlay-sample
https://android.stackexchange.com/questions/110927/how-to-mount-system-rewritable-or-read-only-rw-ro
https://source.android.com/devices/architecture/rros#configuring-overlays
https://source.android.com/devices/automotive/hmi/car_ui/appendix
https://source.android.com/devices/automotive/hmi/car_ui/rro#step_6_dump_the_idmap
https://dzone.com/articles/customizing-android-devices-using-the-runtime-reso
https://dzone.com/articles/android-solution-install-parse-1
https://stackoverflow.com/questions...s-not-recognized-internal-or-external-command
https://github.com/lineageos4microg/android_prebuilts_prebuiltapks/issues/22
wirespot said:
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Click to expand...
Click to collapse
For decompiling and building Android Oreo, I prefer version 2.3.1 of APKTool to other versions of APKTools.
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
...
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
wirespot said:
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider.
What else do I need to do to make it accept the modified framework?
Click to expand...
Click to collapse
I have not tried modifying framework-res.apk of a Samsung Android Oreo nor have I particularly tried the location services mod you are attempting (though I might get around to trying it someday) and do not know if it is valid to to accomplish what you want with it, but believe that the process should be similar to modding the file on LG Android Oreo. I shall try to guide you to how to prepare a framework-res.apk that is proper.
To answer your question about expecting a certain key. The answer to that is that that is usually the case. The signing scheme checks on system apps; however is usually not as thorough as non-system apps. framework-res.apk is also special in that it is not a running app and is instead used as a cache of system resources and system meta information. In the past, before Android Oreo, a rebuilt framework-res.apk may be made to work simply by including original signature files (META-INF) and corresponding AndroidManfest.xml file from the original framework-res.apk into the rebuilt fraemwork-res.apk file. The system would evaluate these files, and pass a check for valid platform signature. With Android Oreo, it appears that there is an additional check that was not present in the past; my best guess is that the system is checking for the V2 signing scheme signing block within the V2 Signing Scheme APK file structure. The check does not, however, thoroughly validate the signing block information.
Your mod seems rather simple and, given your previous posts, would only involve a modification to framework-res.apk "resources.arsc" member file (which contains the compiled "res/values/arrays.xml" file). If the rebuilt "resources.arsc" can be used to update ("Update" is an actual ZIP archive operation) the original framework-res.apk's member file, the updated framework-res.apk should work (and remained zip-aligned if originally zip-aligned), so long as the packed file size of the updated member file is less than or equal to the packed size of the original member file, plus up to 4 bytes depending on proximity to the next member file data if original framework-res.apk is zip-aligned as expected. If the packed modified member file(s) are larger, the original APK file structure would likely not be preserved, and a different method might have to be used. Also note that 7-Zip is not reasonable software to use for this, despite it being included with many tools on XDA to modify APK files; the software has had a history of rearranging unnecessarily zip file table entries when a change is made to an archive. Use a different tool that does not do this, such as WinRAR (I have tested version 5.61).
For normal apps, one may not copy over "resources.arsc" or resources from two different app builds and have things work correctly when the app runs; one would also need to make corresponding changes in the *.dex APK member files. framework-res.apk, not being an app the runs, has no corresponding *.dex files, and one need not worry about corrupting the relationship between the *.dex files and the resource files because none exists to corrupt.
****Your warranty now void***
I am not responsible for crashing of apps or of bootlooping of your device, be sure you know how to get your device recovered using recovery(obviously custom one like twrp)
Hello guys, i am a new user here (not dev lol) and I have a old android device (codename:lettuce) and people like me who have low storage phones suffer problem due to apps getting bigger and bigger everyday.
No more stupids talks lets get to work.
Info: I recommend you to reduce the size of those user apps which you do not update frequently as after every update they will get replace by new one. And I definitely recommend to use app reduction on system integrated apps as it will allow you to move user apps into system on generated free space
Prerequisites:
1. Root Explorer app
2. ZArchiever app
3. Little knowledge of file managing
There are two independent methods to reduce size of any apk or bundled apk. You can either follow both or one or none
Method 1: Compressing APK's "resources.arsc" ( it is present inside apk you can see it using any archive app, i recommend ZArchiver)
Steps:
1. Search for apps which have >=10MB of "resources.arsc" file in the apk or bundled apk files and mark them for the operation.
2. Copy the apk into a dedicated folder in local storage of your device.
3.Open ZArchiver and open the apk's contents using "view" button
4.Extract "resources.arsc" and then again open the same apk.
5. Now tap on add button located in lower right corner and use file icon.
6.Now select the extracted "resources.arsc" file, check the compression level to fastest and add
7.Magic happened, apk size reduced
8.Move and replace the newly compressed apk or bundle apk with the installed one (make sure you force close the corresponding app first) and change the apk permission to 644.
Tips:
1.Do not compress files at ultra as it will slow down loading of images, icons, and other stuffs.
2. Settings have >=30MB of resources
Method 2: Removing "lib" folder inside those apps' apk or bundled apk which extract "lib" folder during installation like Youtube, Maps, Hangouts and many more. Highly recommended for system integrated apps, It is my advice to do not use this method on user apps.
Info:
1.This method should not be applied on Play Store and Google Play Services.
Steps.
1. ***Very Important*** Only for those apps which are installed either as system or user. Applying this method on backed-up apks will corrupt them. Do not touch these "lib" folders "/system/(app or priv-app)/*app_name*/lib" and "/data/app/*app_name/lib"
2.Copy the apk which fulfill condition for this method and extract lib folder using ZArchiver.
3. Here comes boring task, open any file manager you prefer then create and replace all ".so" files present in "lib" and its child folders with blank files ".so" with ***EXTACT SAME NAME*** nothing change in name or neither absence of any filename..
4. You may choose big ".so" files only greater than ~1MB only and leave others untouched.
5.Now after replacing the lib files with blank one, get back to ZArchiver,.open the apk from which u extracted lib folder then tap "add" button in lower right corner, tap upper file icon and then select the extracted and edited lib folder by tapping its icon, change compression level to ultra and tap add.
6.Now you have a apk file with fake lib files.
7.Force stop the app and replace apk file with edited one and set permission to 644.
8.Enjoy
Screenshots
https://photos.app.goo.gl/6dybtLkwu6mscXJ18