I have at last a working 2.3.5 Android on my U8800 Pro. But, I want to clean up the bundled applications that I do not need. In order to do so, I want to find out which apks as well as what other changes I need to do in order to clean up those apps. I know that this is in the http://forum.xda-developers.com/showthread.php?t=1420728 thread, but I want more details for more applications.
What I want to know is:
I suppose that it is not just enough to remove the apk file from the /system/apps/<appname>.apk , is it? If not, what other actions must I perform?
Should I remove the relevant lines from the /system/filelist.lst file?
Where are the application's temporary/user data stored? In /data/data? Should I remove them too?
If I move the /system/app/<file>.apk to /data/app/<file>.apk, how can I stop the application from starting during boot-up in the first place?
Important note: I will not root the phone. Everything will be performed from the pink screen and the mounting of /dev/sd?{12,13} on my Linux box.
In my B521 setup the APKs that I need your help in order to understand what applications or services/widgets are represent, are:
OMACP.apk
ApkBatchInstall.apk
GenieWidget.apk
DeskClock.apk
DownloadProvider.apk
DownloadProviderUI.apk
HwOUC.apk
MagicSmokeWallpapers.apk
MyCalendar.apk
MyRichpad.apk
RichPad.apk
Service-MultiSNS.apk
SocialExt.apk
SmartcardService.apk
RichPad.apk
UpdaterSolutionEx.apk
What information I am looking for is something like this:
Gallery3D.apk: The image gallery application.
PicoTts.apk: Pico Text-to-Speech
Please for your help. After that list is completed, I will write a list of all applications (apks) that are bundled and how to remove them, I promise
I have used apktool to extract the smali files for ReaderRMSDK.apk for my Nook ST with glow.
Nook recently updated to version 1.2
edited the fonts sizes that are hard coded in /smali/com/bn/nook/reader/commonui/ReaderCommonUIConstants$3.smali
and then used apktool to backsmali
Then signed the new ReaderRMSDK.apk using drag2sign
I renamed the original apk to .apk.bak
rebooted
I then copy the new apk into /system/app/ReaderRMSDK.apk
rebooted
But the apk will not work.
Any suggestions as to what could be going wrong?
Can you elaborate on "will not work"?
Can you post a logcat from when it fails? A zipped full logcat is best as apk's are scanned at startup and sometimes produce useful error messages.
I thought we had this covered already once, but I can't seem to find it.
I'm not familiar with "drag2sign".
Have you re-signed your whole system or does "drag2sign" miraculously sign with the B&N signature?
Renate NST said:
I thought we had this covered already once, but I can't seem to find it.
I'm not familiar with "drag2sign".
Have you re-signed your whole system or does "drag2sign" miraculously sign with the B&N signature?
Click to expand...
Click to collapse
I haven't resigned the whole system - that is beyond me!
drag2sign uses framework-jar to sign the apk
Hello!
Can anybody tell me which .apk files I am safe to delete? My setup:
-NookManager
-GApps
-Kindle
-Will not be using *any* B&N Apps (however removing them using NookManager stops the Market from working)
The only GApp I am really interested in is the Market - Is it possible to side load this *only*? It's just lots of other stuff is installed as part of GApp which I have no need for... But there are so many .apk files in system/app and I'm concerned removing some may cause instabilities.
Thanks.
LavaChild0809 said:
Hello!
Can anybody tell me which .apk files I am safe to delete? My setup:
-NookManager
-GApps
-Kindle
-Will not be using *any* B&N Apps (however removing them using NookManager stops the Market from working)
The only GApp I am really interested in is the Market - Is it possible to side load this *only*? It's just lots of other stuff is installed as part of GApp which I have no need for... But there are so many .apk files in system/app and I'm concerned removing some may cause instabilities.
Thanks.
Click to expand...
Click to collapse
No you can't install just the Market. The Market is dependent on the Google Talk and other backend apks. There are patches to system files to get Android setup to work to activate the market. Better to install NTGAppsAttack and then delete what you don't need. After installing NTGappsAttack you can probably remove GenieWidget.apk, Calculator.apk, Calendar.apk, Gmail.apk and Talk.apk. These are all frontends so they shouldn't cause trouble. Before you do this you probably want to use Gmail to get into account and sync settings to turn off mail, calendar and contacts sync. Then you can try removing some of the backend stuff - GmailProvider.apk, CalendarProvider.apk, ContactsProvider.apk and GoogleContactsSyncAdapter.apk. I would start with renaming these apk's and seeing how it goes then if all is well you can delete them. Everything else I would leave alone.
Read through the NookManager and NTGAppsAttack threads. There is a discussion there somewhere about the disabling of B&N apps and the affect on the market.
I have a rooted NST running relaunch. I like the keyboard. I like the left and right arrows that allow me to position the cursor easily. Is there any way to extract the apk for the keyboard? I want to use it on an Onyx ereader.
I remember finding here on this forum a while back a post with a zip that contained all the NST apk files.
Pajamaman said:
I have a rooted NST running relaunch. I like the keyboard. I like the left and right arrows that allow me to position the cursor easily. Is there any way to extract the apk for the keyboard? I want to use it on an Onyx ereader.
I remember finding here on this forum a while back a post with a zip that contained all the NST apk files.
Click to expand...
Click to collapse
Here you go. It may not work on other devices or have need of missing library files. It may not run as a user app.
nmyshkin said:
Here you go. It may not work on other devices or have need of missing library files. It may not run as a user app.
Click to expand...
Click to collapse
Many thanks!
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.