Related
I've been looking for a way to do this for the past couple days with no luck. Just to get any suspicions out of the way, I am not using this to steal someone else's work, it's for a workaround for a game that I'm trying to accomplish using two save files. I've tried going into the android manifest, editing the package name, and then resigning the apk with no luck (i just get parsing errors when I try to install). Is there any way that this can be done? or am I missing something?
It is not a simple matter.
APKs are managed by package name, not by file name, but you can't simply change the package name in the manifest of a compiled APK.
Even assuming you manage to do it without messing up the file, which is not a simple task, there will still be code referring to the package name, so the app will crash.
To put it simply, you would be better off getting your device rooted (if you don't already have root) and playing with the application data files if you want to cheat at some game.
Here is a bit of why I wrote this manual:
Back at December 2010 Paul from modaco found how to enable sip over 3g for the gingerbread native client, his original thread is here:
http://android.modaco.com/topic/327770-using-gingerbread-internet-calling-sip-without-wifi/
For chefs it is probably straight forward how to use this tip, but for me I always begged for cookers to include this in their roms usually they didn't even replay to my request, so I investigated this, and here is very easy way to enable this feature.
This guide assumes you are a little familiar with changing files on your ROM.
*I take no responsibility for this guide, use it at your own risk
So, what we are doing is modifying the framework-res.apk from from our framework directory.
We need:
apktools from here: http://code.google.com/p/android-apktool/
Two files are needed, this: http://code.google.com/p/android-apktool/downloads/detail?name=apktool1.4.1.tar.bz2&can=2&q=
And this: http://code.google.com/p/android-apktool/downloads/detail?name=apktool-install-windows-r04-brut1.tar.bz2&can=2&q=
(You can also do this for Linux and Mac, this guide will use windows)
Take the framework-res.apk from your ROMS zip file inside /system/framework directory.
How its done:
Extract both files that you downloaded to c:\apktools (can be any dir...)
You should have 3 files.
Copy the framework-res.apk to the same directory: c:\apktools
start --> run --> cmd
c:
cd \apktools
apktools d framework-res.apk temp
Now a folder named temp will appear named temp
inside temp, edit the file: C:\apktools\temp\res\values\bools.xml
I use notepad++, search for a line:
<bool name="config_sip_wifi_only">true</bool>th
change in the line the "true" into "false"
save the file.
go back to cmd
c:
cd \apktools
apktools b temp temp.apk
Now rename your original framework-res.apk to framework-res.apk.zip
open it with winrar/winzip/7zip it will open like regular archive.
take the file that was created by the build process:
C:\apktools\temp\build\apk\resources.arsc
Use this file to replace the file inside the archive of framerwork-res.apk.zip (overwriting the original, inside the zip)
rename the file back to framework-res.apk
And now you have a sip over 3g enabled framework-res.apk.
There are few options to push this file, easiest is just replace it in your ROM zip and flush the ROM, you need to wipe cache and dalvik cache.
There are other ways to push this to your rom but I won't discuss them here.
I used this on stock roms, AOSP roms, MIUI roms and Sense roms, worked for me on all, if you find a roms it doesn't work on please report.
Thats it, its actually quite easy.
You are Awesome! Thank you for posting this. I just setup my phone with this and it works great.
Great Process, a few little remarks
Shalom,
This is a great process tutorial and within 15 minutes I flashed my HTC Sensation to support Internet calls on 3G/4G, while before it was WiFi ONLY.
So now, no need to have any cellular minutes purchased, have DATA have LIFE.
Remarks:
1. Have only 2 files. You mentioned 1 download and then 2 more. The 1st is duplicated withing the 2.
2. The BAT file is apktool.bat and not apktools.bat.
Other then that, SWEEET.
Toda Raba.
Easy
---------- Post added at 04:29 AM ---------- Previous post was at 04:11 AM ----------
HTC Sensation T-Mobile.
Forgot to mention earlier.
Thanks.
HI
tryed not working stoped at temp file cretion is showing an eror cant go further plz help
Does this change your phone to use 3g to make calls? If so that is excellent.
Sent from my Sabotaged Droid Incredible 2.
Thanks, but why don't we use SIP third-party such as Sipdroid, 3CXPhone...? I think they are easy to use.
Nice work , What about Xperia Lines, will there appear 3G video calling button ?
I tried on Wet Dreams 1.3.0 for Atrig 4G and didn't works (Didn't show SIP Calling option)... maybe my mistake or isn't working with Moto's 2.3.6 build. But I asked to be added by the chef! Thanks for this tip!
If SIP options are not present in your Settings.APK it may have been disabled by the carrier.
The solution is to place the proper permissions file into /system/etc/permissions/ which will enable SIP overall on your device, then of course to this fix as well.
Solution found in various other places, just thought I'd add it to this thread since the thread is linked from the homepage.
Nice, surprisingly easy, almost to much so lol
lotherius said:
If SIP options are not present in your Settings.APK it may have been disabled by the carrier.
The solution is to place the proper permissions file into /system/etc/permissions/ which will enable SIP overall on your device, then of course to this fix as well.
Solution found in various other places, just thought I'd add it to this thread since the thread is linked from the homepage.
Click to expand...
Click to collapse
Thanx.
But it didnt work for me, and still not seeing sip settings.
I plased the attached file in system/etc/permissions, rebooted.
Also tried to fix permissions, and still didnt work.
Please Help
Verizon Motorola Droid 3
Stock deodexed Rom, Android 2.3.4
BTLINU said:
Thanx.
But it didnt work for me, and still not seeing sip settings.
I plased the attached file in system/etc/permissions, rebooted.
Also tried to fix permissions, and still didnt work.
Please Help
Verizon Motorola Droid 3
Stock deodexed Rom, Android 2.3.4
Click to expand...
Click to collapse
Then the options probably just aren't there in your carrier's Rom. They were present in my LG Rom, after I pushed the permissions file. However, when I tried to use SIP, it would force close as soon as the call connected... something else missing.
In my case and yours, the answer is to use SipDroid from the market.
Pls any guide on how to do this in ICC ROMs
Hi Folks,
Overview
There is a mechanism in Android to override the resources and resource-id values within the framework-res.apk with "Vendor" Specified values. All of this is done transparently at runtime and leaves the original framework-res.apk intact and on the device.
CAUTION - ALWAYS HAVE A BACKUP HANDY. NORMAL OPERATION SHOULD BE FINE BUT WHILE PLAYING AROUND AND SEEING WHAT WAS POSSIBLE THE DEVICE DID CLEAR THE ACCOUNTS DATABASE A COUPLE OF TIMES
Background
While doing some research into how the resources.arsc file are handled internally on Android I came across a Document in the AOSP sources ( frameworks/native/libs/utils/README )
Along with a general overview of resource management, it contained a couple of interesting sections.
The resource overlay extension
------------------------------
The resource overlay mechanism aims to (partly) shadow and extend
existing resources with new values for defined and new configurations.
Technically, this is achieved by adding resource-only packages (called
overlay packages) to existing resource namespaces
...
The use of overlay resources is completely transparent to
applications; no additional resource identifiers are introduced, only
configuration/value pairs. Any number of overlay packages may be loaded
at a time; overlay packages are agnostic to what they target -- both
system and application resources are fair game.
The package targeted by an overlay package is called the target or
original package.
Resource overlay operates on symbolic resources names. Hence, to
override the string/str1 resources in a package, the overlay package
would include a resource also named string/str1. The end user does not
have to worry about the numeric resources IDs assigned by aapt, as this
is resolved automatically by the system.
As of this writing, the use of resource overlay has not been fully
explored. Until it has, only OEMs are trusted to use resource overlay.
For this reason, overlay packages must reside in /system/overlay.
Click to expand...
Click to collapse
What this essentially means is you can create a resource only apk which you place at /vendor/overlay/framework/framework-res.apk.
This file only needs to contain the resources you want to override, the document goes on to explain how the idmap is created in the resources-cache
Note the path is different from the readme file which suggests using /system/overlay, this is not referenced by the source and will do nothing.
Resource ID mapping
~~~~~~~~~~~~~~~~~~~
Resource identifiers must be coherent within the same namespace (i.e
PackageGroup in ResourceTypes.cpp). Calling applications will refer to
resources using the IDs defined in the original package, but there is no
guarantee aapt has assigned the same ID to the corresponding resource in
an overlay package. To translate between the two, a resource ID mapping
{original ID -> overlay ID} is created during package installation
(PackageManagerService.java) and used during resource lookup. The
mapping is stored in /data/resource-cache, with a @idmap file name
suffix.
The idmap file format is documented in a separate section, below.
Creating overlay packages
-------------------------
Overlay packages should contain no code, define (some) resources with
the same type and name as in the original package, and be compiled with
the -o flag passed to aapt.
The aapt -o flag instructs aapt to create an overlay package.
Technically, this means the package will be assigned package id 0x00.
There are no restrictions on overlay packages names, though the naming
convention <original.package.name>.overlay.<name> is recommended.
Example overlay package
~~~~~~~~~~~~~~~~~~~~~~~
To overlay the resource bool/b in package com.foo.bar, to be applied
when the display is in landscape mode, create a new package with
no source code and a single .xml file under res/values-land, with
an entry for bool/b. Compile with aapt -o and place the results in
/system/overlay by adding the following to Android.mk:
LOCAL_AAPT_FLAGS := -o com.foo.bar
LOCAL_MODULE_PATH := $(TARGET_OUT)/overlay
Click to expand...
Click to collapse
All this may sound very familiar to those who have built any AOSP Rom for a device as it is the same concept as the overlay tree which is contained in the device specified directories of the tree. Only this method executes at runtime instead of compile time. There are other differences. Mainly the runtime version only handles the drawables and resources which are included in the resources.arsc of framework-res ( at the moment ) where as the device overlay will handle any file you throw at it. You cannot unfortunately update compressed resources ( i.e the ones in the xml, raw, menu etc ).
The AOSP Tree also contained a test directory for this functionality . /frameworks/base/core/tests/overlaytests and contain an example implementation in the OverlayTestOverlay directory and a runtests.sh shell scripts which highlights that symlinking packages with custom names to framework-res is valid.
Summary
I think this will help modders out and has benefits over the currently widely used method of pulling a devices full framework-res and using apktool to unpack, making the changes and then repacking and resigning ( or using 7z replace, if you're lazy like me ) It will also help with applying/merging multiple mods from different sources as the files only need the include the very basic of the patch.
I don't know how long this functionality has existed but I have never seen it used by any oem and a search of Xda Didn't seem to show any "prior art" of the behaviour. I'd be interested on people thoughts on this, especially if you have seen a rom in the wild that uses it. It's maybe something that could be extended by "us" if google don't have any major plans for it possibly applied to other apks.
KNOWN ISSUES AND WORKAROUNDS
There is a bug in the /frameworks/base/libs/androidfw/AssetManager.cpp. It appears that a umask is set incorrectly when creating the idmap file from the overlay package, as such only the system user had access to it resulting in a failure to apply the overlayed values.
I chmod'd 666 /data/resource-cache/* and reboot to fix this. You can find further details in this google groups post. There is a patch attached the Post which I don't think will apply correctly as the source tree has been Refactored since the patch was created.
See below a workaround
Well this is fascinating. I am going to read the files this afternoon .
That is quite a cool find. Thanks for the tip.
Trevd, I gotta try this. I finally had time to read it carefully. I am going to make a simple one tomorrow. Have you had time to give it a whirl?
Oh, the Google groups link is wrong, I think. It only took me to the Google groups home page.
mateorod said:
Trevd, I gotta try this. I finally had time to read it carefully. I am going to make a simple one tomorrow. Have you had time to give it a whirl?
Oh, the Google groups link is wrong, I think. It only took me to the Google groups home page.
Click to expand...
Click to collapse
Fixed That google link for you, I'll attach some examples and try and put together some more resources on this. I'm going to test it on a couple of different devices. I can however confirm that the functionality is in the ICS code tree and I'm give it a test on CM9 on my HTC Sensations to make sure it functions as expected
Hello Again.
I've done something further research into "weaponizing" this mod so it can be used in anger. The Incorrect Permission Issue highlighted in the first post is pretty much a show-stopper if you want to use this in a flashable zip update for example.
Problem: The idmap is successfully created but cannot be used as the file the world readable file permission is not set.
Solution 1: Patch the AssetManager to create the file with the correct permissions.
This would work but results in the extra overhead of changing core android libraries and would more than likely break Stock OTA Updates because the file hashes won't match.
Solution 1a: Patch the AssetManager to create the file with the correct permissions, Submit the patch to the AOSP project so it is upstream for future releases.
The Patch in the google groups post does not seem to have been submitted as the issue is still there in the latest master branch ( 4.2.1 ) of the AOSP Project. I held off submitting it myself because it is basically someone else's work, However if no-one else is going to do it I suppose someone should . Obviously this solution is still dependent on google actually accepting the patch, carriers including it future roms and numerous other unknown factors which are out of your direct control.
Solution 2: Add a empty idmap in /data/resource-cache folder with the correct permission at the same time as adding the custom overlay.
Although a work around this does solve the issue. This is not as simple as just creating a placeholder zero byte file. The asset manager will reject the file when checking for stale cache files at startup. We need to actually create an empty idmap. Referring back to the original readme file (/frameworks/native/libs/utils/README), google explain the idmap file format
The ID map (idmap) file format
------------------------------
The idmap format is designed for lookup performance. However, leading
and trailing undefined overlay values are discarded to reduce the memory
footprint.
idmap grammar
~~~~~~~~~~~~~
All atoms (names in square brackets) are uint32_t integers. The
idmap-magic constant spells "idmp" in ASCII. Offsets are given relative
to the data_header, not to the beginning of the file.
map := header data
header := idmap-magic <crc32-original-pkg> <crc32-overlay-pkg>
idmap-magic := <0x706d6469>
data := data_header type_block+
data_header := <m> header_block{m}
header_block := <0> | <type_block_offset>
type_block := <n> <id_offset> entry{n}
entry := <resource_id_in_target_package>
Click to expand...
Click to collapse
They also go on to give an example.
idmap example
~~~~~~~~~~~~~
Given a pair of target and overlay packages with CRC sums 0x216a8fe2
and 0x6b9beaec, each defining the following resources
....
the corresponding resource map is
0x706d6469 0x216a8fe2 0x6b9beaec 0x00000003 \
0x00000004 0x00000000 0x00000009 0x00000003 \
0x00000001 0x7f010000 0x00000000 0x7f010001 \
0x00000001 0x00000000 0x7f020000
or, formatted differently
0x706d6469 # magic: all idmap files begin with this constant
0x216a8fe2 # CRC32 of the resources.arsc file in the original package
0x6b9beaec # CRC32 of the resources.arsc file in the overlay package
0x00000003 # header; three types (string, bool, integer) in the target package
0x00000004 # header_block for type 0 (string) is located at offset 4
0x00000000 # no bool type exists in overlay package -> no header_block
0x00000009 # header_block for type 2 (integer) is located at offset 9
Click to expand...
Click to collapse
Further analysis of the asset manager code suggests that although aapt won't create an empty overlay apk it is possible create an idmap file which just contains the file magic along with the original and overlay resources.arsc CRC32 which can be set at zero. Assuming little endian byte ording, these are those magic twelve bytes you need in the /data/resource-cache/[email protected]@[email protected]@idmap
Code:
69 64 6d 70 00 00 00 00 00 00 00 00
The file value will then be updated rather than created when a new overlay apk is provided.
[ EXAMPLES TO FOLLOW ]
So I don't know if anyone has done any follow-up with this, but we have a situation with the Xperia V (and T, more or less the same device in many respects) that makes it impossible to flash or push a modified framework-res.apk. Specifically, the resource-id's inside resources.arsc (public.xml) are getting mangled during recompile and while apktool doesn't show any errors (this is a known, reported issue), the apk is unusable and causes bootloops.
What you've presented here seems like a light at the end of the tunnel. But while I'm confident in my ability to follow directions, I'm afraid I'm too much of a noob to foresee possible reasons for this not working, which is basically what I'm requesting feedback on. Here's what I have in mind, please feel free to point out the holes in my plan...
1. Create the overlay, with the config.xml containing the proper resource-id's as found in public-xml.
2. Push the overlay. It seems to me that with an unmodified framework-res.apk in place, the overlay will simply replace the values from resources.arsc with identical values, thereby having no effect on the system. Any problems at this stage, then, would be from errors on my part, and naturally I would rather weed them out before the next step...
3. Push a modded framework-res.apk and hope that with the overlay in place and doing its business, the corrupted resource-id's will be quarantined and unable to wreak havoc on the system.
It sounds easy, so I'm sure I've missed something. I appreciate any feedback, scathing or otherwise.
shockwaverider said:
So I don't know if anyone has done any follow-up with this, but we have a situation with the Xperia V (and T, more or less the same device in many respects) that makes it impossible to flash or push a modified framework-res.apk. Specifically, the resource-id's inside resources.arsc (public.xml) are getting mangled during recompile and while apktool doesn't show any errors (this is a known, reported issue), the apk is unusable and causes bootloops.
What you've presented here seems like a light at the end of the tunnel. But while I'm confident in my ability to follow directions, I'm afraid I'm too much of a noob to foresee possible reasons for this not working, which is basically what I'm requesting feedback on. Here's what I have in mind, please feel free to point out the holes in my plan...
1. Create the overlay, with the config.xml containing the proper resource-id's as found in public-xml.
2. Push the overlay. It seems to me that with an unmodified framework-res.apk in place, the overlay will simply replace the values from resources.arsc with identical values, thereby having no effect on the system. Any problems at this stage, then, would be from errors on my part, and naturally I would rather weed them out before the next step...
3. Push a modded framework-res.apk and hope that with the overlay in place and doing its business, the corrupted resource-id's will be quarantined and unable to wreak havoc on the system.
It sounds easy, so I'm sure I've missed something. I appreciate any feedback, scathing or otherwise.
Click to expand...
Click to collapse
Hi There.
It's sound's plausible. I will say that I was attempting to implement this "trick" on a Samsung Galaxy Note 10.1 which had a TouchWiz Rom installed without any luck. In that case it wasn't retaining the correct permissions for the resource-cache directory. I didn't go as far as patching the init binary... yet!!! I think that will probably sort it out with if you have control of the device so there is still hope on that one.
I've also not tested it with anything other than settings found in the config.xml I suppose if it gets compiled into the resources.arsc it should be alright.
Have you tried recompiling the using aapt instead? I'm afraid I'm no expert on aapt and it's many switches so I'm afraid you're are on your own as far a making the apk goes if you are trying this outside of the AOSP source tree!
Good Luck
trevd said:
Hi There.
It's sound's plausible. I will say that I was attempting to implement this "trick" on a Samsung Galaxy Note 10.1 which had a TouchWiz Rom installed without any luck. In that case it wasn't retaining the correct permissions for the resource-cache directory. I didn't go as far as patching the init binary... yet!!! I think that will probably sort it out with if you have control of the device so there is still hope on that one.
I've also not tested it with anything other than settings found in the config.xml I suppose if it gets compiled into the resources.arsc it should be alright.
Have you tried recompiling the using aapt instead? I'm afraid I'm no expert on aapt and it's many switches so I'm afraid you're are on your own as far a making the apk goes if you are trying this outside of the AOSP source tree!
Good Luck
Click to expand...
Click to collapse
Thanks for the input! I haven't tried compiling using aapt, I'm afraid that I'm working way beyond my abilities here due to a mix of frustration and determination. I ended up here after somebody pointed to barrykr's thread HERE, so I suppose the first thing to do is try out his method and see what comes of it. If it's not successful, then I'll try to sort through all the big words and smart-people talk and figure out how to get it to work.
Hey mate... just noticed this thread of yours. This is awesome... I wonder why it didn't draw more attention.
Anyway... you've probably seen my mods thread over at Rootzwiki, right? I was wondering if this "overlay" thing would actually work for SystemUI too?
shockwaverider said:
So I don't know if anyone has done any follow-up with this, but we have a situation with the Xperia V (and T, more or less the same device in many respects) that makes it impossible to flash or push a modified framework-res.apk. Specifically, the resource-id's inside resources.arsc (public.xml) are getting mangled during recompile and while apktool doesn't show any errors (this is a known, reported issue), the apk is unusable and causes bootloops.
[...]
Click to expand...
Click to collapse
Hi there! Just wanted to let you know that I have successfully made an overlay.apk which overrides the framework-res.apk default 'settings'. I have a Xperia S with the same problem with framework-res.apk. For my example I used the showNavigationBar boolean value and edited it, and the navigation bar showed after boot :victory: :victory:
@trevd I have not time to test this now, but do you know if it is possible to make an overlay.apk, only with images instead of the resource file? Thanks, I'm quite exited now
edit. Yes it is possible with images. ****. I'm in heaven right now. Everything will be soooo much easier.
skifyr123 said:
Hi there! Just wanted to let you know that I have successfully made an overlay.apk which overrides the framework-res.apk default 'settings'. I have a Xperia S with the same problem with framework-res.apk. For my example I used the showNavigationBar boolean value and edited it, and the navigation bar showed after boot :victory: :victory:
@trevd I have not time to test this now, but do you know if it is possible to make an overlay.apk, only with images instead of the resource file? Thanks, I'm quite exited now
Click to expand...
Click to collapse
@skifyr123 That's a pleasant surprise, I was under the belief that it had stopped working... maybe I was doing my own mod wrong ..
The example in the aosp includes images. http://androidxref.com/4.2_r1/xref/...ytests/OverlayTestOverlay/res/drawable-nodpi/ . I don't know whether you can exclude resources, however that shouldn't be an issue as you can "override" a resource that doesn't exist so won't effect anything. I suspect you probably can excluded them...... as we say in the trade "Try it yourself"
@Kookie_Monster : No , I'm fairly certain that it won't the code only handles framework-res... however there a comment in the code that is quite interesting http://androidxref.com/4.2_r1/xref/frameworks/base/libs/androidfw/AssetManager.cpp#198 Line 198. "apps are handled by the Java Package Manager", I'll have to look deeper into that one
Images worked Do you know if this is any different from Xposed engine (http://forum.xda-developers.com/showthread.php?t=1574401).. At least in this you don't have to install anything extra.
skifyr123 said:
Images worked Do you know if this is any different from Xposed engine (http://forum.xda-developers.com/showthread.php?t=1574401).. At least in this you don't have to install anything extra.
Click to expand...
Click to collapse
Hi
I keep hearing things about the Xposed engine, It's looks a very cool project although not something I'd ever use.
Yes this is completely different It's part of Android core platform source code and is implemented by the asset manager http://androidxref.com/4.2_r1/xref/frameworks/base/libs/androidfw/AssetManager.cpp I believe it's been in there since day 1 ( or close enough ). The main difference is Xposed will let you code where as this is limit to certain types of resources.
I'm GUESSING that this was the original method for vendor overlays but possibly not picked up by HTC ( and others ) in Android's early days so the Idea was abandoned, the way the README in the AOSP reads it was fully intended to extend much more than the framework-res. With all that in mind I also wouldn't be surprised if it suddenly disappeared one day because there's no oem's ( that I know of ) using it
skifyr123 said:
Hi there! Just wanted to let you know that I have successfully made an overlay.apk which overrides the framework-res.apk default 'settings'. I have a Xperia S with the same problem with framework-res.apk. For my example I used the showNavigationBar boolean value and edited it, and the navigation bar showed after boot :victory: :victory:
@trevd I have not time to test this now, but do you know if it is possible to make an overlay.apk, only with images instead of the resource file? Thanks, I'm quite exited now
edit. Yes it is possible with images. ****. I'm in heaven right now. Everything will be soooo much easier.
Click to expand...
Click to collapse
You, sir, are my hero!! :good: :good: :good:
Thank You.
trevd said:
Hi Folks,
Overview
There is a mechanism in Android to override the resources and resource-id values within the framework-res.apk with "Vendor" Specified values. All of this is done transparently at runtime and leaves the original framework-res.apk intact and on the device.
CAUTION - ALWAYS HAVE A BACKUP HANDY. NORMAL OPERATION SHOULD BE FINE BUT WHILE PLAYING AROUND AND SEEING WHAT WAS POSSIBLE THE DEVICE DID CLEAR THE ACCOUNTS DATABASE A COUPLE OF TIMES
Background
While doing some research into how the resources.arsc file are handled internally on Android I came across a Document in the AOSP sources ( frameworks/native/libs/utils/README )
Along with a general overview of resource management, it contained a couple of interesting sections.
What this essentially means is you can create a resource only apk which you place at /vendor/overlay/framework/framework-res.apk.
This file only needs to contain the resources you want to override, the document goes on to explain how the idmap is created in the resources-cache
Note the path is different from the readme file which suggests using /system/overlay, this is not referenced by the source and will do nothing.
All this may sound very familiar to those who have built any AOSP Rom for a device as it is the same concept as the overlay tree which is contained in the device specified directories of the tree. Only this method executes at runtime instead of compile time. There are other differences. Mainly the runtime version only handles the drawables and resources which are included in the resources.arsc of framework-res ( at the moment ) where as the device overlay will handle any file you throw at it. You cannot unfortunately update compressed resources ( i.e the ones in the xml, raw, menu etc ).
The AOSP Tree also contained a test directory for this functionality . /frameworks/base/core/tests/overlaytests and contain an example implementation in the OverlayTestOverlay directory and a runtests.sh shell scripts which highlights that symlinking packages with custom names to framework-res is valid.
Summary
I think this will help modders out and has benefits over the currently widely used method of pulling a devices full framework-res and using apktool to unpack, making the changes and then repacking and resigning ( or using 7z replace, if you're lazy like me ) It will also help with applying/merging multiple mods from different sources as the files only need the include the very basic of the patch.
I don't know how long this functionality has existed but I have never seen it used by any oem and a search of Xda Didn't seem to show any "prior art" of the behaviour. I'd be interested on people thoughts on this, especially if you have seen a rom in the wild that uses it. It's maybe something that could be extended by "us" if google don't have any major plans for it possibly applied to other apks.
KNOWN ISSUES AND WORKAROUNDS
There is a bug in the /frameworks/base/libs/androidfw/AssetManager.cpp. It appears that a umask is set incorrectly when creating the idmap file from the overlay package, as such only the system user had access to it resulting in a failure to apply the overlayed values.
I chmod'd 666 /data/resource-cache/* and reboot to fix this. You can find further details in this google groups post. There is a patch attached the Post which I don't think will apply correctly as the source tree has been Refactored since the patch was created.
See below a workaround
Click to expand...
Click to collapse
is't possible to use vendor overlay to add/ change a value in build.prop file ?
Can someone solve this? I tried to make an overlays to my rom by placing the overlays to /system/vendor/overlays. It works. But when I try to changing to other themes, my overlays gone, I tried to reapply stock theme but didn't worked. Must I try another folder like /system/overlays?
Hey guys.
Having some difficulty here with modifying system APKs without leaving them 'corrupt'.
Specifically with SecSettings and SamsungCamera6.
Only looking to simply modify the qmg icons for the time being.
Ticklemyandroid didn't really want to know with SecSettings. Tried using apktool manually after installing the framework-res.apk and still doesn't seem quite right. Also tried apk multi took. Even went as far as simply trying to past the qmg files into the existing APK with winrar but that really broke things.
I believe my issue is partly that things aren't decompiling properly, but also that I'm a little unclear of the correct procedure to recompile them afterwards without any errors or corruption if tapping on them to install (I'm not actually trying to install them this way, but I'm looking to get to package conflicts rather than package corrupt).
Edit: NVM. Seems like some kind of protection to prevent you from modifying and installing said APKS
*edit* deleted thread. Unfortunately this doesn't fix it. QFIL then flashing EUI ROM 14s and then upgrading to a newer EUI ROM or device firmware update then custom ROM is the only true fix.
Sadly, it doesn´t work for mine, maybe you can help me?
Greetings.
Iceee44 said:
Sadly, it doesn´t work for mine, maybe you can help me?
Greetings.
Click to expand...
Click to collapse
Heyyo, hmm darn that's unfortunate... Well, I have a test build of LineageOS 15.1 for the Le Max 2 with the calibration fixes in place and same with the upcoming official weekly build of LineageOS 14.1 for the X2 this Saturday. It's up to you which you would want to try. Hopefully one of them will work for you.
If not? I'm unsure what else could be causing the issue then hmm...
Hey thanks for reply!
I don't why, but something worked!
I got the splitscreen bug, then I flashed the recovery to the newest twrp (the blue one, don't know which version, but I will look it up). Then I wiped everything and install your fix. Result = bricked. Another try with one flash 2.0 and no error from flash. Fastboot recovery flash and everything was perfect.
I think it was luck, but my leeco le max 2 is repaired :victory:
Wow that's lucky! Congrats on fixing it!
May I please ask what happened to cause the brick? I've heard of device bricking but haven't seen an exact answer as to what unfortunately caused it.
It was totally my fault... I Format my data...and no image on storage... And one flash did the screen problem, maybe the program doesn't decompress a file finally... I decompressed the qfil data two times... The first time I got an error, after full decompressed everything...
Ah if you format data without any ROM on the device you can always use a PC and USB cable to do this...
adb push NameOfROM.zip /sdcard
Which will copy the zip file to the root of your data storage. Same can be repeated for Gapps or Magisk, etc.
I tried to push a 1,8GB file...
But after 2 hours it wasn't transferred, so I found the software and this is much easier.
Could you explain what exactly the "Unbricked devices split screen" bug is?
So from understanding the changes, does this mean that the 4 profiles in the Display -> Colour mode menu won't actually activate for people with the issue? (So if they do change then you don't have the bug?)
I'm guessing that editing those xml files could help with this problem? https://forum.xda-developers.com/le-max-2/how-to/le-max-2-black-crush-survey-t3744594
Or are there other places where those parameters are set?
ThE_MarD said:
Heyyo, this is a TWRP flashable zip file to replace the broken formatting on the qdcm calibration xml files for the display panels used in the LeEco Le Max 2
Click to expand...
Click to collapse
Which bug your fix is intended to fix? Do you mean this: https://youtu.be/3yXnrkfsJMI - I have never seen it on my device.
Or you mean color calibration, which is currently terrible by default (too much yellowish)
oneNight1 said:
Could you explain what exactly the "Unbricked devices split screen" bug is?
So from understanding the changes, does this mean that the 4 profiles in the Display -> Colour mode menu won't actually activate for people with the issue? (So if they do change then you don't have the bug?)
I'm guessing that editing those xml files could help with this problem? https://forum.xda-developers.com/le-max-2/how-to/le-max-2-black-crush-survey-t3744594
Or are there other places where those parameters are set?
Click to expand...
Click to collapse
For both of these questions the hopes is that the main issue with most people who unbrick their devices having screen issues is due to calibration settings being lost which this in theory should restore as it would have XML files with proper formatting unlike before where stock EUI ROM for the Le Max 2 had broken calibration XML files.
In theory if the black crush issue is also a calibration issue there's a chance this could also fix it... But still, I haven't really looked into that as I was mainly looking for a better solution for those unfortunate people suffering from unbrick device woes. If it fixes it? Cool... If not? Then I'm not too sure. Calibration files could potentially be modified to fix black crush if the issue is in there that LeEco never addressed.
giaur said:
Which bug your fix is intended to fix? Do you mean this:
- I have never seen it on my device.
Or you mean color calibration, which is currently terrible by default (too much yellowish)
Click to expand...
Click to collapse
How do i view the config files and transfer them to my computer to compare them to yours? I enabled usb debugging, thinking that would let me see everything but when i connect to my computer with MTP mode i can only see standard files, not all the linux config files etc.
(edit: I tried using adb shell and i could view the root directory but it wouldn't let me access the config folder - permission denied. Do i need root access? If so, how do i get it temporarily and then remove it once i have transferred the files? I can't just run adb as root because you need root on the phone apparently).
Also i did a search of the available EUI x829 source (http://opensource.le.com/ or http://opensource.le.com/ or https://forum.xda-developers.com/le-max-2/how-to/source-code-available-t3482334 )and i couldn't find those xml files. Are they generated by the OS or something?
To me it seems like the files are probably already formatted correctly on my particular phone as changing the colour mode does appear to function. However they obviously seem to be not calibrated properly (or intentionally calibrated very badly).
I wonder if it only reads these files on boot? Otherwise i guess an application could be made to interactively adjust them.
I wonder if KCAL uses these files.
However from looking at how large the data is and also the mention of LUTs (lookup tables), it would seem that this is actually more advanced than kcal? And could potentially give proper screen calibration if using a colourimeter etc?
Of course, more than one profile would be necessary for different brightness levels though.
But anything is better than nothing.
It is definitely to do with the eui colour mode settings because if you go to google translate and translate the names in for each profile, they match up with colour mode options.
These are part of EUI ROM as I did mention the XML formatting is broken on all the EUI ROM versions I looked at.
You can use an Android ROM extractor like this to open up EUI ROM and see the files yourself if you'd like.
https://forum.xda-developers.com/android/help/extract-dat-marshmallow-lollipop-easily-t3334117
I found this https://usermanual.wiki/Pdf/KBA160907024936QDCMPCToolDebugGuide.968066270 which implies that the xml file is used directly.
Have you considered that <Calib_Data /> just means that the Calib_Data section is empty deliberately and that the colour profile and LUT sections were never intended to be within the calibration data tag?
We do not have the specification of the QDCM xml file that the tool generates.
It would be beneficial if the QDCM tool could be somehow leaked or obtained, then the end user could calibrate their phones. Or at least a specification of the file format of the QDCM xml files so correct data could be generated.
I suggest this should be brought up to the wider android community as it applies to all recent qualcomm phones.
Then we can compare with the QDCM xml files distributed with their handsets. Maybe some handsets even contain the same panels and therefore maybe we could attempt to use their profile / calibration settings. Of course it won't give perfect results because screens should be calibrated on an individual basis but it might be a lot better than the awfullness i currently have.
I wonder, do Le Eco calibrate each handset individually because if they do and then CFW overwrites the calibration with a "random" one then i can understand how that would cause issues. However my display has been bad before i loaded CFW... (unless the seller tampered with the FW but i don't know how you are meant to tell that).
I am not saying you are wrong but you have not given sources for your findings and to me, the individual colour profiles are working it's just that the overall calibration (or all of the profiles themselves) is extremely awful with huge black crush.
That tools seems to be for looking at backup images? But i want to view what is on my phone currently. Do you have to root your phone to do so? If so how can i root and then unroot it after i'm done?
Thanks
oneNight1 said:
I found this https://usermanual.wiki/Pdf/KBA160907024936QDCMPCToolDebugGuide.968066270 which implies that the xml file is used directly.
Have you considered that <Calib_Data /> just means that the Calib_Data section is empty deliberately and that the colour profile and LUT sections were never intended to be within the calibration data tag?
We do not have the specification of the QDCM xml file that the tool generates.
The way the XML formatting is? Calib_Data is supposed to house the entire XML file to let QDCM know where the calibration data starts and ends... So on the broken EUI ROM XML files it only has an end and never loads the calibration data.
It would be beneficial if the QDCM tool could be somehow leaked or obtained, then the end user could calibrate their phones. Or at least a specification of the file format of the QDCM xml files so correct data could be generated.
I suggest this should be brought up to the wider android community as it applies to all recent qualcomm phones.
Then we can compare with the QDCM xml files distributed with their handsets. Maybe some handsets even contain the same panels and therefore maybe we could attempt to use their profile / calibration settings. Of course it won't give perfect results because screens should be calibrated on an individual basis but it might be a lot better than the awfullness i currently have.
I wonder, do Le Eco calibrate each handset individually because if they do and then CFW overwrites the calibration with a "random" one then i can understand how that would cause issues. However my display has been bad before i loaded CFW... (unless the seller tampered with the FW but i don't know how you are meant to tell that).
I am not saying you are wrong but you have not given sources for your findings and to me, the individual colour profiles are working it's just that the overall calibration (or all of the profiles themselves) is extremely awful with huge black crush.
That tools seems to be for looking at backup images? But i want to view what is on my phone currently. Do you have to root your phone to do so? If so how can i root and then unroot it after i'm done?
Thanks
Click to expand...
Click to collapse
Heyyo, it's definitely a formatting error. XML standard has open and close brackets.
For example, the OnePlus 5T
https://github.com/TheMuppets/propr...b_data_samsung_s6e3fc1_cmd_mode_dsi_panel.xml
Or the Xiaomi Mi5 (Gemini)
https://github.com/TheMuppets/propr...calib_data_sharp_fhd_cmd_incell_dsi_panel.xml
As for viewing the files on your phone? Yes you would need root and a root file explorer.
Magisk, SuperSU, KingRoot or such all work for root but some versions of EUI ROM have issues.
For root enabled file browser? Amaze works... Amazing. Just get it from the Play store and then in settings enable root explorer.
For uninstalling root please Google the uninstall method to whichever root method you use as they are all different.
That's not true, XML tags can close themselves. If you don't believe me look here: https://www.w3schools.com/xml/xml_elements.asp (scroll down to empty xml elements)
How they had formatted their tags was valid xml.
Code:
<Calib_Data />
is just an element with nothing in it, the same thing as:
Code:
<Calib_Data> </Calib_Data>
However what you showed me from the other xml files for other phones make it look like it should be the way you have changed it
Okay i will have a look and let you know. I have small eui installed atm. So if you just flash an su to your system and then once you uninstall the app root is completely gone? I never would have thought it would be that simple.
It seems when you have root you can use an adb shell as root so i might try that rather than bothering to install anything on the phone.
Is there a way also to view what it was in the backup of my original fw without restoring it? (i used this guide for backup https://forum.xda-developers.com/le-max-2/how-to/protocol-backup-stock-rom-flash-stock-t3517151 ).
How can i find out which of the 3 display types my device is using? (Preferrably via adb).
I will be really surprised if it's wrong in mine because the colour modes work which will be very weird if that xml file isn't being used - they must do it another way too if that's the case :S
It's also weird how those xml files have been hand tampered with!
Thanks!
oneNight1 said:
That's not true, XML tags can close themselves. If you don't believe me look here: https://www.w3schools.com/xml/xml_elements.asp (scroll down to empty xml elements)
How they had formatted their tags was valid xml.
Code:
<Calib_Data />
is just an element with nothing in it, the same thing as:
Code:
<Calib_Data> </Calib_Data>
However what you showed me from the other xml files for other phones make it look like it should be the way you have changed it
Okay i will have a look and let you know. I have small eui installed atm. So if you just flash an su to your system and then once you uninstall the app root is completely gone? I never would have thought it would be that simple.
It seems when you have root you can use an adb shell as root so i might try that rather than bothering to install anything on the phone.
Is there a way also to view what it was in the backup of my original fw without restoring it? (i used this guide for backup https://forum.xda-developers.com/le-max-2/how-to/protocol-backup-stock-rom-flash-stock-t3517151 ).
How can i find out which of the 3 display types my device is using? (Preferrably via adb).
I will be really surprised if it's wrong in mine because the colour modes work which will be very weird if that xml file isn't being used - they must do it another way too if that's the case :S
It's also weird how those xml files have been hand tampered with!
Thanks!
Click to expand...
Click to collapse
Write this in the terminal.
Code:
cat /sys/devices/virtual/graphics/fb0/msm_fb_panel_info | grep panel_name
Thanks Sergio, so my device is running:
Code:
le_x2_mdss_dsi_truly_qhd_dualdsi_cmd_pvt
Hmm it seems that SmallEUI ( https://forum.xda-developers.com/le-max-2/development/rom-small-eui-5-9-aurel-battery-t3524531 ) wiped the configs folder. It looks the same through both ADB --> shell ---> su ---> cd config as it does through the Amaze app on the phone itself - empty.
I am pretty sure that I have root properly, supersu seems to be installed.
For some reason though, if i try and get ADB to get root, it says:
Code:
adbd cannot run as root in production builds
I don't have a folder named configs, only one called "config" and it is completely empty.
Is there any way to view the files that were in my TWRP backup of my stock X829 FW without reflashing it?
I have lots of data.ext4.win000 files etc. Which archive would it be in? System? Data? EFS? Boot? And how do i browse the archives?
Thanks
oneNight1 said:
Thanks Sergio, so my device is running:
Code:
le_x2_mdss_dsi_truly_qhd_dualdsi_cmd_pvt
Hmm it seems that SmallEUI ( https://forum.xda-developers.com/le-max-2/development/rom-small-eui-5-9-aurel-battery-t3524531 ) wiped the configs folder. It looks the same through both ADB --> shell ---> su ---> cd config as it does through the Amaze app on the phone itself - empty.
I am pretty sure that I have root properly, supersu seems to be installed.
For some reason though, if i try and get ADB to get root, it says:
Code:
adbd cannot run as root in production builds
I don't have a folder named configs, only one called "config" and it is completely empty.
Is there any way to view the files that were in my TWRP backup of my stock X829 FW without reflashing it?
I have lots of data.ext4.win000 files etc. Which archive would it be in? System? Data? EFS? Boot? And how do i browse the archives?
Thanks
Click to expand...
Click to collapse
You should notice this does not work, garbage screen is there even with this fix applied. I have it all the time on latest Lineage 15.1.
Okay I checked in
Code:
system/etc
and I do have the files. They are formatted as
Code:
<Calib_Data />
too.
Why does your github page say that they should be in
Code:
config/qcdm
???
Anyway, I flashed your zip to see if it would make a difference but it didn't help with the black crush sadly.
Although maybe modifying the calibration data would - but of course we would need to understand the format.
I checked my TWRP backup image (you can just browse them with 7zip) and they have the same empty tag too.