Related
The last time I looked, the only dump for the Captivate on xda was a JF6 version, posted a few weeks ago, and the OP had taken out a few AT&T apps prior to doing it, making it not a true stock. This morning I decided to rip out the content out of the factoryrfs.rfs files from each of the three firmwares we have. I am planning to poke around in these a bit and try my hand at some deodexing, but I have also uploaded them for anyone else to play with them, or to restore any files they might have inadvertently deleted:
Here are the links:
JF6
JH2
JH3
JH7
rajendra82 said:
The last time I looked, the only dump for the Captivate on xda was a JF6 version, posted a few weeks ago, and the OP had taken out a few AT&T apps prior to doing it, making it not a true stock. This morning I decided to rip out the content out of the factoryrfs.rfs files from each of the three firmwares we have. I am planning to poke around in these a bit and try my hand at some deodexing, but I have also uploaded them for anyone else to play with them, or to restore any files they might have inadvertantly deleted:
Here are the links:
JF6
JH2
JH3
Click to expand...
Click to collapse
What do JF and JH stand for?
freedonkey said:
What do JF and JH stand for?
Click to expand...
Click to collapse
They relate to the month in which they were built. F means june, h is august. Both of the jh roms are test roms and unfinished, but functional and snappier than the stock jf6 rom.
Sent from my Samsung SGH-i987
Thanks for this.
Aye... Thanx for the system dumps.
Anyone seen these for the i9000?
alphadog00 said:
Anyone seen these for the i9000?
Click to expand...
Click to collapse
Easy to get the files out yourself. Extract the factoryrfs.rfs file out of the firmware tar file, boot into linux and do:
sudo mount -o loop factoryrfs.rfs <any_directory_of_your_choice>
Then copy the files from the mounted location to another, and you have the raw system dump.
Pardon my ignorance but what do these dumps do/provide? How are they different from the firmware from Samsung Firmware?
glio1337 said:
Pardon my ignorance but what do these dumps do/provide? How are they different from the firmware from Samsung Firmware?
Click to expand...
Click to collapse
The firmware from Samsung Firmware contains the applications and default configuration settings packed into a factoryrfs.rfs (which itself is then inside a .tar file). That format is suitable for Odin to flash onto the phone, but you can't access the individual files inside the .rfs. What I did was to unpack the .rfs file, so that the individual files inside are available for whatever you want to do with them. These are not suitable for flashing on the phone as a whole, but someone could take something, modify it and push it to their phone, or make a custom ROM out of it. A simple example is the circle battery indicator mod, where someone modified the framework-res.apk to show percentage, and then made a custom ROM update.zip with it. Without access to the original file, this would not have been possible. Everyone has these files on the phone in one version or another (unless they manually edit or delete them). I just wanted all versions of the files ever released or leaked.
I dont know if this is the place to ask but how we can extract particular app to be able to install it as .apk
here is what i need
http://forum.xda-developers.com/showthread.php?t=776739
zagorka said:
I dont know if this is the place to ask but how we can extract particular app to be able to install it as .apk
here is what i need
http://forum.xda-developers.com/showthread.php?t=776739
Click to expand...
Click to collapse
All the apks are inside the zip files, stored the same way they would normally reside on your phone. I am pretty sure the stock Clock widget is a touchwiz widget, and will not work on your wife's Aria. Hell it won't even work on our own phone if you switch to a different launcher.
rajendra82 said:
All the apks are inside the zip files, stored the same way they would normally reside on your phone. I am pretty sure the stock Clock widget is a touchwiz widget, and will not work on your wife's Aria. Hell it won't even work on our own phone if you switch to a different launcher.
Click to expand...
Click to collapse
I am talking about ClockPackage not SamsungWidget_CalendarClock or SamsungWidget_StockClock. It's the one in applications not the widgets.
zagorka said:
I am talking about ClockPackage not SamsungWidget_CalendarClock or SamsungWidget_StockClock. It's the one in applications not the widgets.
Click to expand...
Click to collapse
Clockpackage is in the zip files. Here is the JH3 version for you. Not sure if it'll install. When I try to push to the Android 2.1 Emulator, I get:
adb install ClockPackage.apk
1404 KB/s (0 bytes in 2921292.002s)
pkg: /data/local/tmp/ClockPackage.apk
Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]
Which tells me that the package is probably dependant on TouchWiz 3.0 or some other library already installed on the phone.
rajendra82 said:
Clockpackage is in the zip files. Here is the JH3 version for you. Not sure if it'll install. When I try to push to the Android 2.1 Emulator, I get:
adb install ClockPackage.apk
1404 KB/s (0 bytes in 2921292.002s)
pkg: /data/local/tmp/ClockPackage.apk
Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]
Which tells me that the package is probably dependant on TouchWiz 3.0 or some other library already installed on the phone.
Click to expand...
Click to collapse
Yes, I was able to extract the .apk and .odex files but couldnt install them.
Probably you are right it is too much trouble. I'll look for some alternative.
Thank you
I think he zipaligned the system apk's too
designgears said:
I think he zipaligned the system apk's too
Click to expand...
Click to collapse
I am very new to android, so I am not sure of the implications of this. After further investigation, there is a newer version of the bat files (Auto_Deodexer_2.3), but that version does not do any zipaligning. I added my own bat file to do this after the deodexing, but is what the older version did (zip align every apk in the app directory) bad, and why? If that is the case, which of the apk files should I not zipalign?
On a similar note, the newer bat file asks me to give a bootclasspath. When I give it the values in the init.rc, it skipped deodexing few of the apks in the app directory. When I added twframework.jar to the bootclasspath ahead of framework.jar, it skipped fewer files. I am sure that the older version was buggy, and made mistakes. What should the proper bootclasspath be to not skip deodexing the following files, and to properly deodex the others:
BluetoothOPP.apk+odex
Camera.apk.odex
FactoryTest.apk+odex
MiniDIary.apk+odex
TouchwizCalendar.apk+odex
Figured out the bootclasspath to use. OP and the JH3 file updated. If you downloaded the deodexed JH3 version yesterday, please replace it with the newer version.
What exactly does deodexing and zipaligning do? I understand it makes it faster but how so?
Sent from my SAMSUNG-SGH-I897 using XDA App
frenchtoasted said:
What exactly does deodexing and zipaligning do? I understand it makes it faster but how so?
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
All this is highly theoretical knowlege on my part, so if anyone has better information, feel free to correct me:
Deodexing:
Some of the apks and jar files on the default stock ROM have their code split between apk/odex and jar/odex pairs instead of in a single file. This is done by the developers to supposedly save space, and memory usuage, and to speed up the booting process. Unforunately having separate odex files means that replacing any part of the whole system is much harder. Deodexing the ROM puts the code from the odex files back into the apk and jar files so that every application and jar is self contained and could be replaced with an equivalent.
Zipaligning:
Zipaligning is an optimization of apk files to align all uncompressed data within them on 4-byte boundaries to reduce the memory usage. Since deodexing rebuilt the apks with the code from the odex files, they would have become unaligned. I realigned them to make them optimized again.
This is not necessarily a performance tweak at first, but once you are able to replace the slower parts of the system as a result of it, you should start to get more benefits out of it.
would it be possible to get the allshare package from the deodexed rom? will it work with any other device?
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?
*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.
Hi all,
Mozilla is cleaning out it's archive and intends to remove almost all of the nightly builds for B2G.
UPDATE: Bug being tracked, they will keep the latest of each branch/target combination (based on what I suggested, I hope I'm right!): https://bugzilla.mozilla.org/show_bug.cgi?id=1470575
https://discourse.mozilla.org/t/intent-to-remove-old-builds-on-july-1-2018/28831
As part of a project to clean out obsolete artifacts from archive.mozilla.org, we intend to remove old files from https://archive.mozilla.org/pub/b2g/ on July 1, 2018.
On July 1 we will:
Delete all files under https://archive.mozilla.org/pub/b2g/tinderbox-builds/
Delete everything except latest-mozilla-central* from https://archive.mozilla.org/pub/b2g/nightly/
If removing these files will seriously impact you, please reply back to me and we can hopefully find a way to preserve the files you need while still cleaning up the majority of the old builds there.
Thanks,
Chris
Click to expand...
Click to collapse
I know that in the past some people have found what's in the archive useful for making custom ROMs for normally unsupported devices. I don't if anyone is still using them, however if you are then please reply to the thread in Mozilla Discourse or on the FirefoxOS development mailing list: https://groups.google.com/d/msg/mozilla.dev.fxos/Q68CmQ3lD4g/TY6GMjLnCgAJ.
EDIT: attached ZIP of sitemaps generated from https://www.check-domains.com/sitemap/ to help people navigate this enormous archive.
EDIT 2: Attached an XLSX file to try and help people navigate the archive.
EDIT 3: Add Bugzilla link.
Cheers
Does anyone know what the current size of the repo is?
Perhaps a mirror can be made?
AFAIK it's apparently 23TB, stated on irc.mozilla.org #b2g.
madb1lly said:
AFAIK it's apparently 23TB, stated on irc.mozilla.org #b2g.
Click to expand...
Click to collapse
Yikes, I only have around 1.5TB total in my desktop (shared between 12 hard drives, another terabyte on my laptop, and another in an external drive.
I think that perhaps the DataHoarder subreddit would be a good place to post this (I do not have a Reddit account).
Mozilla have not said they will delete everything, I think they are happy to keep files that people use. The problem is that we don't know what people use, hence why I thought I would spread the word and see if anyone uses any of the files.
OP updated: attached ZIP of sitemaps generated from https://www.check-domains.com/sitemap/ to help people navigate this enormous archive.
OP updated: attached XLSX made from the sitemaps to try and make it easier for people to navigate and identify what they think may be useful.
Has anyone else experienced this? I only have side-loaded books and was thinking of applying @Renate NST's mod for showing metadata for all books when I found that I couldn't get anything with a double-tap. I just get a black screen for a moment and then I'm back where I started. I'm going to have to download a B&N freebie to see if the function is working at all, I guess....
Edit: I can confirm. Even with a B&N book I get a black screen flash on double-tap in the Library. So...either the rooting process in NookManager is not quite right for this FW or something else I've done has rendered this function inoperable Now the "fun" begins.
some additional info and maybe a cause
It turns out there are small discrepancies in the file sizes of three jars often modified, two for NTMM, and one for USB audio microphone recording (and maybe other stuff). The MD5 checksums are different in all three cases between FW 1.2.1 and FW 1.2.2. These are:
android.policy.jar
services.jar
framework.jar
The differences must not be great since the device continues to function in the main, but the issue with needing to resign Opera Mobile and Tasker, along with this new failure of the Library double-tap function suggests all is not quite right "under the hood".
Once upon a time I patched framework.jar myself using files supplied by @Renate NST. I'm guessing I might be able to do that again with the file from the FW 1.2.2. The other two jars would require patching from whatever information can be gathered on the GitHub site where NTMM is documented. Not so sure about that {scratches head and looks woeful}.
The "good" news is that the devices are largely functional and if/when the FW 1.2.2 jars are correctly patched, they can just be copied over without restoring the device to out-of-the-box state and building up (again) from there.
Um... (scratches head).
Is it my Library app that we're talking about?
I don't remember anything else for getting metadata.
I did notice one bug, it will (rarely) not get metadata if the zip is corrupted with different info on the zip global and local headers.
The problem is with the underlying Android zip libraries.
If it's only a single book you can desktop unzip and rezip.
If something is flashing or crashing a logcat will tell us something.
---------- Post added at 07:24 PM ---------- Previous post was at 06:57 PM ----------
I put the latest version Library-1.13.apk up (in the signature).
I made it so that you could dismiss the details with a click (handy if you're using a Glow2 without any soft keys).
Renate NST said:
Um... (scratches head).
Is it my Library app that we're talking about?
I don't remember anything else for getting metadata.
Click to expand...
Click to collapse
No, and so if the patch you have in the 1.2.1 patches zip applies only to meta data showing in your Library app, then at least part of the issue is moot.
I'm in the process of running a back-up even as I type so I can swap out the patched jars for the originals from FW 1.2.2 (one-by-one) to see if that restores the double-tap function in the B&N Library. Probably all three jars should be repatched anyway, but at least this will tell me if I am on the right track.
As for the patching, it's clear what needs to be done with the framework.jar and the audio recording patch you supplied. I've been looking at the patches for NTMM at the GitHub site and those are pretty impenetrable for me. So far.
nmyshkin said:
I've been looking at the patches for NTMM at the GitHub site...
Click to expand...
Click to collapse
Link, please. I've never used or looked at this.
To compare jars, just apktool d them into separate directories and diff them.
You can easily see which classes are different and by looking at the smali exactly what the differences are.
Renate NST said:
Link, please. I've never used or looked at this.
Click to expand...
Click to collapse
https://github.com/doozan/NookTouchPatches
Renate NST said:
To compare jars, just apktool d them into separate directories and diff them.
You can easily see which classes are different and by looking at the smali exactly what the differences are.
Click to expand...
Click to collapse
Yes, I've done this with android.policy.jar from FW 1.2.1 and FW 1.2.2, but I don't see an immediate way to compare them. I come up empty on the "diff" command(?). If I could see the connection between the smali and the info at the NTMM GitHub I guess I might be able to text edit the smali by hand(?) and then recompile the jars? Is that too simple?
windiff is MS's graphical version of the Unix diff command.
You can get it here: https://www.microsoft.com/en-us/download/details.aspx?id=18546
It works on directories or files.
Code:
C:\>windiff thisdir thatdir
Renate NST said:
windiff is MS's graphical version of the Unix diff command.
You can get it here: https://www.microsoft.com/en-us/download/details.aspx?id=18546
It works on directories or files.
Code:
C:\>windiff thisdir thatdir
Click to expand...
Click to collapse
OK, got that. So a quick look at a few smali files from the two firmwares shows only a line number difference. I'm sure there's more as there are about 80 smali files in just android.policy.jar
There are probably more proficient approaches but it seems to me that if I were to compare the original 1.2.1 jars to the patched jars distributed with NookManager I would see the patches pretty clearly. Next, I would have to examine the same smali files in the 1.2.2 jars to find the correct insertion points for the patches. Maybe? Then using something like Notepad++, I do a cut and paste. When all the smali files from the 1.2.2 jars have been patched in the same way as those from 1.2.1, then I baksmali the lot and recompile the jar.
Yes?
It sounds tedious, but I can do tedious and there are only two jars to work on.
Edit: OK, so back at the GitHub for NTMM I examined the patches and made a list of the smali files mentioned in each. Presumably these are the only ones actually patched. That narrows it down a lot! There are only 4 files patched in android.policy.jar and 6 in services.jar
Oh, I'm finally beginning to get what this is all about.
I hadn't ever seen that doozan stuff.
Those patches are difficult because they are diff generated.
There are only two java source files.
The rest of the patches were manually done on smali files which don't seem to be on that GitHub.
It's silly that ModUtils is installed with a patch, you could just copy it over.
My 1.2.1 patches a bunch of stuff which could easily conflict with the doozan patches or even not conflict but make their patches not patch correctly.
They might even conflict with some changes in FW 1.2.2
Renate NST said:
Oh, I'm finally beginning to get what this is all about.
I hadn't ever seen that doozan stuff.
Those patches are difficult because they are diff generated.
There are only two java source files.
The rest of the patches were manually done on smali files which don't seem to be on that GitHub.
It's silly that ModUtils is installed with a patch, you could just copy it over.
My 1.2.1 patches a bunch of stuff which could easily conflict with the doozan patches or even not conflict but make their patches not patch correctly.
They might even conflict with some changes in FW 1.2.2
Click to expand...
Click to collapse
You've given me some good tools (hopefully used correctly) to help see what is going on. Here's what I think I've learned:
I compared the two jars (android.policy.jar and services.jar) from FW 1.2.1 and 1.2.2. They are not completely identical, but the smali files which are to be patched are identical. Next, just to be sure I was correctly interpreting what info I could glean from the GitHub, I compared the original 1.2.1 jars with the patched jars. The only differences were in the smali files I had anticipated.
Unless the situation is more complicated than I think (is that even possible?!), this leads me to conclude that the patched smali files from the 1.2.1 firmware could be copied/added to the 1.2.2 firmware and the lot recompiled (apktool b) to provide patched jars for the 1.2.2 installation of NTMM (from NookManager).
Does that sound right?
nmyshkin said:
Does that sound right?
Click to expand...
Click to collapse
That should do the job.
You still might have to dig down to fix your original problem.
Renate NST said:
That should do the job.
You still might have to dig down to fix your original problem.
Click to expand...
Click to collapse
As usual, you are so right.
I patched the 1.2.2 jars so that NTMM would run and that all seems to have gone OK. But after a hot swap, clearing cache and rebooting (which took an agonizingly long time!), I found no change in the behavior that got me started on this in the first place. Nor was there any difference in the ability to install the few apps that needed resigning before they would install. But...I learned something, and whatever other subtle differences there were in the jars, that is now moot as things are now all updated to 1.2.2
Except framework.jar was not, because I had been lazy and didn't want to repatch for AudioRecord, so I had used the jar from 1.2.1. Since my other work had "no effect" I decided to bite the bullet and patch the framework.jar from 1.2.2 for AudioRecord (your patch). That was, um, fun. And when all that was accomplished and I swapped out that jar and rebooted (another loooooong wait) I still did not have the "fix" for the original issue.
Isn't that interesting? Ugh. Maybe it's a kernal issue. I'm not going there because there are no kernals developed for 1.2.2 and none for even 1.2.1 that have what I want. So I'll keep my kernal for 1.1.5 which does everything I want and hope nothing else shows up wonky. Maybe someday I'll return to an old backup of 1.2.2 before the kernal change and see if that is the issue.
Meanwhile I have a set of patched jars for 1.2.2. Now I need to look at the patches for NTGAppsAttack and try to get those updated, just because.
Thanks for the lesson
Well, you say that a double tap causes action, but not the right action.
(Double tap is kind of unusual, it's usually short vs. long tap.)
If something is dying, it's there in the logcat.
Is an Intent being generated?
B&N uses com.bn.nook.shop.action.show.details
My Library app also covers that. You can try temporarily installing it.
B&N uses a truly goofy Intent style.
This would make it difficult to troubleshoot from the command line with am start -a
It could be that the B&N database is screwed up.
The Intent only tells you to query B&N for the metadata.
Renate NST said:
It could be that the B&N database is screwed up.
The Intent only tells you to query B&N for the metadata.
Click to expand...
Click to collapse
...or, it could be that what's left of my little grey cells are out to lunch
I'm sure if I were to search diligently in this forum I would find myself reminding people about the Law of Unintended Consequences and pointing out exactly this issue IF Shop.apk is disabled. I can now remember that clearly. But I didn't when I started on this wild goose chase
Still, a few new skills, some newly patched jars. Not a bad result overall
Just to clarify:
I meant that it queries on the device the B&N content provider, not over the network to B&N.
Still, you should have seen something on logcat.
Renate NST said:
Just to clarify:
I meant that it queries on the device the B&N content provider, not over the network to B&N.
Still, you should have seen something on logcat.
Click to expand...
Click to collapse
And I did. Something about a missing intent. I think that's what finally nudged my stuck memory loose. BTW, I did do a quick install of your Library prior to remembering about Shop.apk. It cured the "flash to black screen and back" for a double-tap in the B&N Library, resulting in only a suggestion of a screen flicker, but not the desired behavior. Thanks again for all your help.