Related
Attention! The function number below may differ. Better check it by decompiling the whole file before decompiling only the single function.
Part 1 - How to remove 01:02 flip:
I write this manual because I find there are people using wrong way to get rid of this nasty "feature", which will cause clock stuck or Manila starts with 0:00AM. Here I provide a proper way to remove this "feature":
1. Download LuaTool(Thanks Co0kieMonster), and make sure you know how to use Command Line.
2. Grab 5fa4d4b7_manila from Manila Home to the same folder as LuaTool.
3. Open Command Line, input "LuaTool /decompile -f 28 5fa4d4b7_manila"(without the quotes) and enter.
4. Open 5fa4d4b7_manila.lua that just generated by LuaTool, you will find something like this:
Code:
Below comes from Manila_Home_2_5_20111612_0, other versions may differ:
local l_28_0 = _application.Store:GetIntValue(Lifetime_Application, "ShowCacheHomePage")
if l_28_0 == 1 then
if _TickControlForClock:CheckBoundary() then
ClockHelper:DoFlip()
else
ClockHelper:SetTimeInstantly()
end
else
local l_28_1 = _application.Store:GetIntValue(Lifetime_Application, "AnimationForHomeKey")
if l_28_1 == 1 then
if _TickControlForClock:CheckBoundary() then
ClockHelper:DoFlip()
else
ClockHelper:SetTimeInstantly()
end
end
end
Simply replace all those "DoFlip" with "SetTimeInstantly", or you can reconstruct the code structure like below:
Code:
local l_28_0 = _application.Store:GetIntValue(Lifetime_Application, "ShowCacheHomePage")
if l_28_0 == 1 then
ClockHelper:SetTimeInstantly()
else
local l_28_1 = _application.Store:GetIntValue(Lifetime_Application, "AnimationForHomeKey")
if l_28_1 == 1 then
ClockHelper:SetTimeInstantly()
end
end
This can reduce internal operations in Manila.
5. After editing the code, save the file and in the Command Line, input "LuaTool /compile -s -r 28 5fa4d4b7_manila 5fa4d4b7_manila.lua" and enter.
6. Overwrite the original 5fa4d4b7_manila with the edited one.
Part 2 - How to make a CDMA SMS fix for Manila 2.5:
This fix can fix the SIM error when you send a SMS from a CDMA2000 phone in Manila 2.5 Classic Messaging Page. To enable Classic Messaging Page, import these registry keys:
Code:
[HKEY_CURRENT_USER\Software\HTC\Manila]
"Manila://PeopleDetail\\peopleMessageClassic.page.hidden"=dword:0
"Manila://PeopleDetail_SIM\\peopleMessageClassic.page.hidden"=dword:0
"Manila://PeopleDetail\\peopleMessage.page.hidden"=dword:2
"Manila://PeopleDetail_SIM\\peopleMessage.page.hidden"=dword:2
Then let's start making this fix:
1. Download LuaTool(Thanks Co0kieMonster), and make sure you know how to use Command Line.
2. Grab 57a92846_manila from Manila People to the same folder as LuaTool.
3. Open Command Line, input "LuaTool /decompile -f 46 57a92846_manila"(without the quotes) and enter.
4. Open 57a92846_manila.lua that just generated by LuaTool, search for "SIM", and you will find something like this:
Code:
if not l_46_2.bIsSIMPresent then
trace("[peopleMessage.lua] : SIM is not present")
ShowDialog(Locale:GetString("IDS_NOSIMCARD"), Locale:GetString("IDS_NOSIMCARD_DESP"), "OK")
return
end
and this:
Code:
if not l_46_2.bIsSIMReady then
trace("[peopleMessage.lua] : SIM is not ready")
l_46_2:OpenPINCodeDialog()
return
end
Simply delete these two part of code.
5. After editing the code, save the file and in the Command Line, input "LuaTool /compile -s -r 46 57a92846_manila 57a92846_manila.lua" and enter.
6. Overwrite the original 57a92846_manila with the edited one.
Nice post.
Thanks for the info... Does by any change do you know or have you found a fix for the rhodium, that by excess of text looks like the rhodium wants to kill itself lol. or I would say another SMS fix
lion75y said:
Thanks for the info... Does by any change do you know or have you found a fix for the rhodium, that by excess of text looks like the rhodium wants to kill itself lol. or I would say another SMS fix
Click to expand...
Click to collapse
I don't use Rhodium, so I don't know, sorry.
For manila Home 2_5_20161714, the clock flip full decompile then recompile did not work for me. It decompiles at 97%, I make the edits, then recompile. When I do a binary compare of original vs. new, the new has a noticeable amount truncated at the very bottom. If I decompile the edited .lua, the bottom section (l_28) is missing.
When I decompiled only function 28, edited, then recompiled, it worked.
luatool /d -f 28 5fa4d4b7_manila
willysp said:
For manila Home 2_5_20161714, the clock flip full decompile then recompile did not work for me. It decompiles at 97%, I make the edits, then recompile. When I do a binary compare of original vs. new, the new has a noticeable amount truncated at the very bottom. If I decompile the edited .lua, the bottom section (l_28) is missing.
When I decompiled only function 28, edited, then recompiled, it worked.
luatool /d -f 28 5fa4d4b7_manila
Click to expand...
Click to collapse
If you re-read my thread, you will find I use replace function when compile instead of compiling the whole script.
cnzqy1 said:
If you re-read my thread, you will find I use replace function when compile instead of compiling the whole script.
Click to expand...
Click to collapse
With all due respect, please re-read my reply. You and and I compiled the same way. By function replacement.
me: luatool /c -s -r 28 5fa4d4b7_manila 5fa4d4b7_manila.lua
you: LuaTool /compile -s -r n 5fa4d4b7_manila 5fa4d4b7_manila.lua [where you said to substitute 28 for n]
I had to decompile just the single function I wanted instead of the whole file.
me: luatool /d -f 28 5fa4d4b7_manila
you: LuaTool /decompile 57a92846_manila
Decompiling, not compiling, is where your experience and mine differed. Perhaps (likely?) due to a different script structure in 2011 versus 2016.
Also, you said "You may not get 100% sucess rate [decompiling] but that's okay.". I don't think I agree with that from my experience at 97%. If it fails to 100% decompile something that I want to edit, then it stands to reason that "garbage in - garbage out". That's why, when the whole decompile failed at 97%, I decompiled just function 28 - and was happy it was 100%.
Anyway, I'm sorry if you perceived my reply to be critical - it was not.
And, I DID forget to say thank you in my original reply - I did not know about this tool. It seems to be a bit buggy as I read the tool author's post - especially for more complex logic expressions.
lion75y said:
Thanks for the info... Does by any change do you know or have you found a fix for the rhodium, that by excess of text looks like the rhodium wants to kill itself lol. or I would say another SMS fix
Click to expand...
Click to collapse
Sorry? Say again?
willysp said:
With all due respect, please re-read my reply. You and and I compiled the same way. By function replacement.
me: luatool /c -s -r 28 5fa4d4b7_manila 5fa4d4b7_manila.lua
you: LuaTool /compile -s -r n 5fa4d4b7_manila 5fa4d4b7_manila.lua [where you said to substitute 28 for n]
I had to decompile just the single function I wanted instead of the whole file.
me: luatool /d -f 28 5fa4d4b7_manila
you: LuaTool /decompile 57a92846_manila
Decompiling, not compiling, is where your experience and mine differed. Perhaps (likely?) due to a different script structure in 2011 versus 2016.
Also, you said "You may not get 100% sucess rate [decompiling] but that's okay.". I don't think I agree with that from my experience at 97%. If it fails to 100% decompile something that I want to edit, then it stands to reason that "garbage in - garbage out". That's why, when the whole decompile failed at 97%, I decompiled just function 28 - and was happy it was 100%.
Anyway, I'm sorry if you perceived my reply to be critical - it was not.
And, I DID forget to say thank you in my original reply - I did not know about this tool. It seems to be a bit buggy as I read the tool author's post - especially for more complex logic expressions.
Click to expand...
Click to collapse
Oh, I'm so sorry... I did read your post carefully and I didn't think that will make any difference, now I confirmed that quite a part is missing. It's my fault, I didn't fully understand how "-r" switch will work until now. Will modify my post, thanks!
cnzqy1 said:
Oh, I'm so sorry... I did read your post carefully and I didn't think that will make any difference, now I confirmed that quite a part is missing. It's my fault, I didn't fully understand how "-r" switch will work until now. Will modify my post, thanks!
Click to expand...
Click to collapse
Cool - glad I could add some value with my post! Thanks again for your post about the tool!
hey dude,why don't you tell me there have a thread you post....
yeah,it fix my question.thx a lot.see you in dft
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
I'm fairly noobish w.r.t. Android (but rapidly less so!), but long in the tooth with unix and linux.
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
For the life of me, examing the output of mount, I can't figure out what device path to use in the command,
mount -o rw -o remount <device> /
I'm guessing it probably isn't this simple, and there is some convoluted loop config with mount or something as part of the Android security mechanism.
You can mount it as r/w with Root Explorer...
SubnetMask said:
You can mount it as r/w with Root Explorer...
Click to expand...
Click to collapse
ES File explorer will also allow you mount as writable. Under Menu>Settings>Root options.
It's a little flaky though, I have to turn on the root options then shut down the app and restart it to get it to work. It's free and available in the Android Market.
dwallersv said:
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
Click to expand...
Click to collapse
You can remount / as read-write with:
Code:
mount -wo remount rootfs /
and read-only again with:
Code:
mount -ro remount rootfs /
However, the root filesystem is actually a ram disk (initramfs), so any changes to it aren't persistent across reboots. You can modify the initramfs, but it requires rebuilding it and packaging it with a kernel, and flashing the kernel containing the new initramfs.
dwallersv said:
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
Click to expand...
Click to collapse
Can you get away with placing it in /data or even /system? If you can't recompile bash, you'll have to invoke it with "bash --init-file /data/local/.bashrc" or something.
If you're using ConnectBot Local, you can do that automatically with "Post-login automation", e.g., "exec bash --init-file /whatever/.bashrc".
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
DiGi760 said:
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
Click to expand...
Click to collapse
That's for "/system", OP is asking about "/".
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot.
The only way you can accomplish what you want, in this circumstance, is the method listed above, or to modify the initramfs.
Thanks everyone, for all the great information... Man, I love this place!
@mkasick: Crap!! Well, that torpedoes this one.
I've already used the various "workarounds" you cited (use connect automation with ConnectBot, for example). My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
I'm not going to go to all the trouble to rebuild a custom initramfs for just this.
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Once again, mkasick, you are a most helpful fellow around here. I must say -- and it may make you blush -- I am a big fan and admirer of yours, with the things you've found and fixed for the community. You are unique among the devs in my view, given the nature of what you have looked into and fixed. I'm a pretty experienced, knowlegable software guy myself, and fancy learning enough about Android to make contributions in the not-too-distant future like you have.
As I mentioned in another thread, I'm looking at a major driver re-design for the keyboard based on your analysis and patch for the dropped keypress problem... I plan to have some discussions with you (if your interested) sometime in the next few weeks about what I'm planning, just to get your feedback, if nothing else. Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Keep up the good work, friend. You are a uniquely valuable member of this community, in my judgement
-- And that's not to shortchange any of the other devs here, it's just that the nature of your work resonates with me especially, given my own background, career, interests, and past work in software.
Dameon87 said:
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot
Click to expand...
Click to collapse
Spot-on, and very good point. However, there are ways around that:
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Click to expand...
Click to collapse
In fact, in a more generalized sense, this approach can be used to make any changes to the rootfs that "persists" across boots, without the pain of rebuilding initramfs and repackaging the kernel. This is especially messy to track and manage when you take advantage of one of the excellent custom ROMs here (in my case, Bonsai).
FWIW, and maybe helpful to others, I already have organically evolved as "reinstall" framework/process for doing some customizations to the system after installing a new/updated ROM. I use shell scripting for a lot of little things, and keeping this stuff working became a challenge across ROM releases, because necessary components -- like shells, busybox versions, whether busybox of toolbox is being called by the default path, and a bunch of other things (like the ALSA tools) are present in places like the /system filesystem.
All this gets mucked up with each ROM/kernel update. Now, I'm slicing this bologna even thinner by messing with rootfs, so I've got to get things to persist across boots!
I have a simple, one-step process for fixing all this after a new ROM. Nothing fancy -- just a flashable, Edify zip of my stuff that I hit right after a ROM update. Found a template zip with very generic Edify script in it that simply copies the file tree. I keep my custom stuff updated there.
dwallersv said:
My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
Click to expand...
Click to collapse
How about setting BASH_ENV or HOME in telnetd's environment? Or is the environment not preserved?
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only.
Click to expand...
Click to collapse
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
There's also using gscript, maybe Tasker, or another program that hooks ACTION_BOOT_COMPLETED. Those won't run at root privileges, but a tie in to "su -c" should work.
dwallersv said:
You are unique among the devs in my view, given the nature of what you have looked into and fixed.
Click to expand...
Click to collapse
Thanks!
I think of my contributions as complementary though. I don't really have the time or patience for "maintaining stuff" that other folks do here very well.
dwallersv said:
Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Click to expand...
Click to collapse
I suppose discussion elsewhere is appropriate. Sounds ambitious, but a good idea. The existing keyboard driver architecture could be improved for certain. To date though, I've tried to make my kernel changes relatively non-invasive, even if not ideal, for maintenance sake.
In a perfect world, a rewritten driver would make it back to Samsung and that would be the "end of it" for us. Personally, I wouldn't want to expend the effort to do so unless I knew it would be merged. But if that something you feel like attempting, there's no harm in trying and seeing what results.
mkasick said:
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
Click to expand...
Click to collapse
I'm not 100% certain at this point, but from what I've found investigating this, it looks like the "user scripts" /etc/init.d/<scripts> mechanism is a standard part of the Android system. I'll see if I can find where I saw that and post a link.
I have a Nook Simple Touch, BNRV300, and I have successfully modified uRamdisk to gain root shell access with ADB over USB (Thanks Renate!). I am currently on firmware version 1.2.1.
I know this may seem like heresy to some here, but I really do not want or need to root my NST and add a number of apps I won't use anyway. I have a fully rooted Nexus 7 for that sort of thing.
All I would like to be able to do is turn off the need to swipe to unlock when returning from sleep, and modify the text on the screensaver overlay.
I have discovered, by the way, that sqlite3 does not seem to be available on this NST, as when trying to use it via ADB shell, it says "sqlite3: not found".
SO, there we are... I would greatly appreciate any assistance offered.
MildBill
P.S. I have tried Nook Manager, and while it did what I wanted, there were many things added that I just have no need for. And, battery drain seemed to double.So, it had to go.
Regarding SQLite3.
Since the guts of it (libsqlite.so) is already in the Nook, you only need the command line executable (sqlite3).
It's here: http://forum.xda-developers.com/showthread.php?p=50958855#post50958855
Unzip it, stick it in /system/bin, chmod 755 it.
Renate NST said:
Regarding SQLite3.
Since the guts of it (libsqlite.so) is already in the Nook, you only need the command line executable (sqlite3).
It's here: http://forum.xda-developers.com/showthread.php?p=50958855#post50958855
Unzip it, stick it in /system/bin, chmod 755 it.
Click to expand...
Click to collapse
Ahh, once again, thank you Renate. Now if I can get some idea on my main questions...
There are no simple questions here. Even the answers are complicated.
Many people have created solutions and packed them into these "manager" things.
I finally got around to doing my own minimal one.
It's packaged up in nook121patch.zip (in the signature).
Code:
C:\>adb pull /system/framework/android.policy.jar
C:\>apktool d android.policy.jar \AP
C:\>mergesmali /v C:\AP\smali C:\Nook121Patch\KeyguardViewMediator.smali
C:\>apktool b C:\AP android.policy.jar
C:\>adb shell stop
C:\>adb mount -o rw,remount /dev/block/mmcblk0p5 /system
C:\>adb push android.policy.jar /system/framework/
C:\>adb shell chmod 644 /system/framework/android.policy.jar
C:\>adb shell reboot
Renate NST said:
There are no simple questions here. Even the answers are complicated.
Many people have created solutions and packed them into these "manager" things.
I finally got around to doing my own minimal one.
It's packaged up in nook121patch.zip (in the signature).
Click to expand...
Click to collapse
Well Renate, I hate to complicate your answer any more than necessary, but...
On the Temblast page that clicking on your signature takes me to, I do see mergesmali, one of the two tools I will need based on the instructions you gave. I do not see nook121patch.zip, nor apktool, however. Where can I find these?
Also, can you tell me something about what this will do for me?
I hate to be such a noob, I have just enough knowledge to be dangerous. Thanks again for all your help, sorry I have to keep asking for more.
MildBill
Well, I wasn't that clear.
mergesmali is in the signature, nook121patch.zip is on the mergesmali project page too.
Apktool is detailed and linked here: http://forum.xda-developers.com/wiki/Apktool
There are many patches in the nook121patch.zip
You can apply them selectively.
.jar is easy, they don't need signing.
.apk is trickier they must be signed.
System .apk is even trickier, they must be signed with the system signature.
The KeyguardViewMediator.smali will make that your Nook just opens with a push of the power button and no swipe.
Renate NST said:
Well, I wasn't that clear.
mergesmali is in the signature, nook121patch.zip is on the mergesmali project page too.
Apktool is detailed and linked here: http://forum.xda-developers.com/wiki/Apktool
Click to expand...
Click to collapse
Ahh! Well, my bad, I should have tried harder. And, yet again, thanks. Nook users owe you much, Renate!
MildBill
Renate NST said:
Code:
C:\>adb pull /system/framework/android.policy.jar
Click to expand...
Click to collapse
OK so far, and (I think) I have apktool properly installed, then realized I also needed to install the Java Development Kit as well to use it, which I managed to do. But, when I try to do
Code:
C:\>apktool d android.policy.jar \AP
I get
Code:
Input file (\AP) was not found or was not readable.
as a response.
So, I guess I need to return to the magic well of your knowledge for further assistance and/or instruction.
To which I can only add...
HELP!
EDIT: By the way, I am using an adb.exe implementation from another root kit I have installed, not the standard installation from the SDK. Is this perhaps part of my problem?
Well, something goofy is going on there.
Type just apktool and get the usage and version.
\AP in this case is the destination directory.
It should not already exist or else you get a warning.
Maybe the input file (the jar) can't be found, but the error message is wrong?
Code:
C:\>apktool
Apktool v1.5.2 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <[email protected]>
with smali v1.4.1, and baksmali v1.4.1
Code:
C:\>apktool d C:\nook121\system\framework\android.policy.jar \AP
I: Baksmaling...
I: Copying assets and libs...
Code:
C:\>apktool d C:\boguspath \BogusDir
Input file (C:\boguspath) was not found or was not readable.
Renate NST said:
Well, something goofy is going on there.
Type just apktool and get the usage and version.
Click to expand...
Click to collapse
Well, there ya go... I got apktool v2.0.0b9.
I can get 1.5.2, but will it work with Java 7? Oh well, live and learn I guess...
MildBill
Oh, well, then the 2.0 probably uses different args.
"apktool" by itself will tell you the order of arguments.
To run anything on the desktop the Java 7 runtime environment is fine.
To compile an Android application you have to use Java 6.0 SDK.
Renate NST said:
Oh, well, then the 2.0 probably uses different args.
"apktool" by itself will tell you the order of arguments.
To run anything on the desktop the Java 7 runtime environment is fine.
To compile an Android application you have to use Java 6.0 SDK.
Click to expand...
Click to collapse
Well then, since it appears from the changes that 2.0 requires the Java 7 SDK, I guess I'll uninstall it all and get 1.5.2 and Java 6.
I'm running desktop applications:
Code:
C:\>java.exe -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode, sharing)
I'm compiling Android applications with:
Code:
C:\>javac.exe -version
javac 1.6.0_38-ea
apktool runs under the JRE, version 1.7 is fine.
OK, finally got around to completing the instructions as posted, and except for having to add the command 'shell' to the mount statement, everything worked fine. And, it accomplishes exactly what I was after.
Next I may look into trying your library and reader apps.
Thanks again!
MildBill
P.S. You might consider rewriting the readme file included in nook121patch.zip to better describe what each patch does.
The readme is admittedly very old.
That's because I forgot that it's even there!
Each of the individual smali files has comments at the head saying what it does.
I'll make something to compile the individual comments into a single readme.
I can also report, at this point, that unlike an other method I have tried to accomplish this simple task, this one does NOT run thru battery life like it was going out of style.
The next most popular option, NookManager, which uses the NookModManager to do this fix, uses an average of 10% battery life every day, even when in in sleep mode the whole time. Turning the option off (I.E. reinstating the swipe to unlock) again reduces battery drain to a more normal point.
But, the fix by Renate seems to use nomorebattery than the stock reader, whether reading, sleeping, with WiFi on or off. I like it!
Once again, Renate, thank you very much for this, and for all you have done for the Nook community.
MildBill
Greetings, and welcome to the home of a little set of utilities I'm calling "DroidShell".
What it is:
DroidShell is my attempt at bridging the gap between the various android utilities used for ROM modification and the Windows explorer system. It is a series of scripts that are automatically associated with .apk, .jar, and .iso files so that they are automatically decompiled on double-click or enter. Additionally, when a file is decompiled, a corresponding .dcp, dcf, or dci (decompiled package, decompiled framework, decompiled image) file is created, which allows for automatic recompiling, as well as optional cleanup, or resigning.
The goal of this project is pretty simple...to have all the tools needed for ROM work in one place, and have them easily accessible without having to have eighty command windows open or to have to go through a chain of commands to create a usable apk/jarfile.
Features:
One-shot setup. Extract the files, run install/installer.bat, and all of the necessary file associations and paths are created.
Batch terminal integration - provides integration for adb, fastboot, apktool, 7zip, zipalign, oat2dex, unpackbootimg, repackbootimg, baksmali and smali in windows command-line interface from path.
Automagic association with common android filetypes for decompilation.
Custom placeholder files - dcp, dcf, and dci - for packages, framework, and image files. Allows for automatic recompiling, and optional signing and cleanup of decompiled files.
Recompiled apks and jars are automatically repacked with modified files while excluding androidmanifest.xml, meaning signatures are unaffected.
For modifications requiring androidmanifest be changed, you can right-click a .dcp file to recompile with signature.
Auto-detection of framework-res file with prompting to install.
Popup dialogue boxes for errors and alerts.
(NEW) Right-click to decompile to java code. This cannot be recompiled, but is great for researching more complex mods. (Can also be invoked by using the command dj filename.apk)
(NEW) Support for sparse image system -> .img conversion.
(NEW) za command for zipaligning apk's.
(NEW)
Download:
https://github.com/d8ahazard/DroidShell/archive/master.zip
Source:
https://github.com/d8ahazard/DroidShell
Instructions...
You need the Java Runtime Environment (RE). Get it here.
Extract to a folder somewhere. Spaces in the path are probably not good. I put it in C:\DroidShell
Browse to the folder. Go into the install folder. Run installer.bat. (Installer needs admin priveleges. It will prompt for them, but in some cases, you may have to automatically run as admin)
Reboot.
You should now have shell integration. APKs, Jars, and .img files will automagically decompile.
It's late, I've been working on this all weekend...but it should be good to go. Please let me know if you have any thoughts.
CHANGELOG:
Code:
02.02.16 - v2.0
Update smali, baksmal to v. 2.1.1.
Add shell script for oat2dex (not implemented in context menus, just avaialable for now)
Update APKTool to latest version
Add dx.jar - for converting java classfiles to .dex (just available for now)
Add ext4 and ext2 tools - For manually unpacking images if needed. These are GUI based, not my work.
Add rimg2sdat - For converting .img to sparse (Not implemented yet)
Update sdat2img to latest version by xspirit, added python to installer as required.
Add zipalign function (Not implemented, can be called via "za filename.apk"
Add decompile to pure Java:
This utilizes a few tools to take apk's and jarfiles and decompile them to as close of an android package as we can get without having the actual source code. While we cannot at this time recompile these into apk's, it is very useful for analysis when trying to implement other mods. Like...really helpful. This one can be accessed by right-clicking a decompileable package and picking "decompile to java".
01.31.15 - v1.8
Added windows progress bar for file copies in system.img extraction.
Fixed some script errors.
01.29.15 - v1.7
Cleaned up installer, added more verbosity.
Better error checking in image extractor.
Add support for .list files, allowing double-click extraction of system.transfer.list and cm12-style image files.
Added custom language files for notepad++, allows syntax highlighting of .smali and logcat files.
01.27.15 -v1.6
Added support for system images. Requires installation of included OSFMount.
Added file associations for common plaintext android files to notepad++ if installed.
Converted several .bat files to .exe, allows for icons, inclusion of required files, and UAC prompting when needed.
01.26.15 - v1.5
Fixed fatfinger in APKtool detection causing error.
01.26.15 - v1.4
Added zipaligning
Added check to make sure apktool is present
Updated test-keys to latest AOSP version
Compiled batches to .exe with required files for AIO-packages
Fixed: Installer not always associating with files correctly.
Thanks a million
Version 1.5 uploaded.
Added Zipaligning
Check to make sure apktool.jar is found in %DROIDROOT% directory.
Updated signing keys.
Switch from .bat to .exe, allows modularization of functions, cleaner.
Modifications to installer to try and fix some issues with file associations.
Fixed issue between 1.4 and v 1.5 where I fatfingered a check.
Hell yes!
digitalhigh said:
Greetings, and welcome to the home of a little set of utilities I'm calling "DroidShell".
What it is:...
Click to expand...
Click to collapse
So many thanks for this! I'm going to use it like hell!
Excellent Job!
I'm bookmarking this, gona read it thuroughly at breakfas
So I'm curious - has anybody had a chance to give this a try yet?
Testing file association stuff is tricky, because Windows likes to keep track of the "user selected" association too. So, I had to add some extra commands to the installer script to clean up everything appropriately first.
Either way, I've ran it on like three different computers "clean" and had it work like a charm on all of them. I'd like to know how it works with WIndows 7 or XP.
I could be doing something wrong (windows is not my OS of choice, I use kubuntu 14.10 as my daily driver, and as such am mostly illiterate in dos/batch, I'm a sh/bash guy), but the installer bombed out (hung up without confirmation of success) on my windows 7 pro install (on a dell latitude e6400, with a dual core core2 @2.8ghz, quattro 160m graphics, 4gb of ddr2 @800mhz, booting off a 120gb Samsung evo ssd. Wouldn't think its relevant, but just in case).
Steps:
First I decompressed the .zip in the root of my C:\ drive, with 7zip (did not change file name, kept as "DroidShell_1.5").
Next I ran the installer script.
I then granted it admin privileges.
It killed my desktop, explorer.exe. I assume this is normal due to the terminal output:
Code:
SUCCESS: The process "explorer.exe" with PID 3260 has been terminated
Then I got:
Code:
file type 'apk_auto_file' not found or no open command associated with it.
Followed by 4 more identical errors, just replace "apk" with dfc, dcp, dci, img.
A bunch of successful operations.
Then:
Code:
ERROR: Invalid syntax.
Type "REG ADD /?" for usage
A bunch of successful operations.
Then:
Code:
ERROR: The system was unable to find the specified registry key or value.
The above output repeats 17 times.
Then 4 more operation success messages and it hangs, with my desktop killed.
Ctrl+alt+del, logout, log in, and I'm back in business. No noticeable increase in disk space, no newly installed programs (as expected).
I read the op, and from my understanding it doesn't require any dependencies? (Apktool, android SDK, android studio, etc). All the necessary dependencies are built in, right? It's a fresh install of windows 7 pro, with all available updates taken.
EDIT:
It worked perfectly regardless of the errors, see my post on page 2.
thisguysayswht said:
I could be doing something wrong (windows is not my OS of choice, I use kubuntu 14.10 as my daily driver, and as such am mostly illiterate in dos/batch, I'm a sh/bash guy), but the installer bombed out on my windows 7 pro install (on a dell latitude e6400, with a dual core core2 @2.8ghz, quattro 160m graphics, 4gb of ddr2 @800mhz, booting off a 120gb Samsung evo ssd. Wouldn't think its relevant, but just in case).
Steps:
First I decompressed the .zip in the root of my C:\ drive, with 7zip (did not change file name, kept as "DroidShell_1.5").
Next I ran the installer script.
I then granted it admin privileges.
It killed my desktop, explorer.exe. I assume this is normal due to the terminal output:
Code:
SUCCESS: The process "explorer.exe" with PID 3260 has been terminated
Then I got:
Code:
file type 'apk_auto_file' not found or no open command associated with it.
Followed by 4 more identical errors, just replace "apk" with dfc, dcp, dci, img.
A bunch of successful operations.
Then:
Code:
ERROR: Invalid syntax.
Type "REG ADD /?" for usage
A bunch of successful operations.
Then:
Code:
ERROR: The system was unable to find the specified registry key or value.
The above output repeats 17 times.
Then 4 more operation success messages and it hangs, with my desktop killed.
Ctrl+alt+del, logout, log in, and I'm back in business. No noticeable increase in disk space, no newly installed programs (as expected).
I read the op, and from my understanding it doesn't require any dependencies? (Apktool, android SDK, android studio, etc). All the necessary dependencies are built in, right? It's a fresh install of windows 7 pro, with all available updates taken.
Click to expand...
Click to collapse
Bombed out is a rough term. The installer is just writing a bunch of registry keys, and deleting some other ones to make sure other associations don't mess it up. So, some registry operations don't always work - there just there to be sure. I've actually worked on cleaning that up in the next iteration I'm cooking.
And yes, there shouldn't be any more size increase past extracting the original zip. All the files used are enclosed. "Installer" is just telling Windows that "droid shell is at location %CD%" and "use app xxx in %CD% to open file XX". A few extras for the right-click context menus and icons...so forth.
So, to know if it is working is really just a matter of finding an apk or .jar and double-clicking it. You should get a terminal window showing the process and a box confirming success or failure, plus a reason why if failure.
The only dependency is the Java Runtime environment, which is the same common necessity as for any other Apktool environment. You can get it here, and I'll throw that link in the OP in a second.
The next iteration of the installer is going to be a lot cleaner, plus be more verbose so you actually know what it's doing. My first thought in putting it out was just to see how well the decompile/recompile stuff worked.
Bombed out is a rough term. The installer is just writing a bunch of registry keys, and deleting some other ones to make sure other associations don't mess it up. So, some registry operations don't always work - there just there to be sure. I've actually worked on cleaning that up in the next iteration I'm cooking.
And yes, there shouldn't be any more size increase past extracting the original zip. All the files used are enclosed. "Installer" is just telling Windows that "droid shell is at location %CD%" and "use app xxx in %CD% to open file XX". A few extras for the right-click context menus and icons...so forth.
So, to know if it is working is really just a matter of finding an apk or .jar and double-clicking it. You should get a terminal window showing the process and a box confirming success or failure, plus a reason why if failure.
The only dependency is the Java Runtime environment, which is the same common necessity as for any other Apktool environment. You can get it here, and I'll throw that link in the OP in a second.
The next iteration of the installer is going to be a lot cleaner, plus be more verbose so you actually know what it's doing. My first thought in putting it out was just to see how well the decompile/recompile stuff worked.
Click to expand...
Click to collapse
I didn't mean to offend with the term "bombed out", it may have been a bit of a rough term. I just meant the script terminated my desktop and hung up.
It actually succeed regardless of the errors, and is working like a charm. I apologize, I should have actually tested it before posting. I shouldn't have assumed that it didn't work based off of the terminal output/behavior.
Also, I would like to say that I greatly appreciate the work that you put into this, and all your other projects here on xda. I'm running your 4.4.4 gpe port for the verizon m8 as my primary rom, and it is by far the most stable port I have ever had the pleasure of flashing.
Attached are screenshots of DroidShell successfully decompiling and recompiling an apk with a simple right click selection on windows 7 pro. Good stuff.
Thanks! tons
Thanks for the work. very useful.
The compiling and decompiling of apk is perfect on Win 7 pro.
From the OP, i also got the impression it would unpack / pack images, so i tried it with a system.img copied to the droidshell directory.
With the command c:\droidshell\unpackimg system.img, I got the error as shown in screenshot
Am I doing something wrong, or is this not supported yet?
arbit12 said:
Thanks for the work. very useful.
The compiling and decompiling of apk is perfect on Win 7 pro.
From the OP, i also got the impression it would unpack / pack images, so i tried it with a system.img copied to the droidshell directory.
With the command c:\droidshell\unpackimg system.img, I got the error as shown in screenshot
Am I doing something wrong, or is this not supported yet?
Click to expand...
Click to collapse
It only works for boot images at the moment. System images are a different beast.
Sent from my HTC6525LVW using XDA Free mobile app
digitalhigh said:
It only works for boot images at the moment. System images are a different beast.
Sent from my HTC6525LVW using XDA Free mobile app
Click to expand...
Click to collapse
Okay. Thanks for the info.
thisguysayswht said:
I didn't mean to offend with the term "bombed out", it may have been a bit of a rough term. I just meant the script terminated my desktop and hung up.
It actually succeed regardless of the errors, and is working like a charm. I apologize, I should have actually tested it before posting. I shouldn't have assumed that it didn't work based off of the terminal output/behavior.
Also, I would like to say that I greatly appreciate the work that you put into this, and all your other projects here on xda. I'm running your 4.4.4 gpe port for the verizon m8 as my primary rom, and it is by far the most stable port I have ever had the pleasure of flashing.
Attached are screenshots of DroidShell successfully decompiling and recompiling an apk with a simple right click selection on windows 7 pro. Good stuff.
Click to expand...
Click to collapse
Oh, no offense taken.
I came at this project, as I do with most, with the mindset of "OOOH, SHINY THING. I MUST SHOW EVERYONE." So, first thought was putting out the app, despite some of the install stuff being a bit dirty.
However, the next iteration is shaping up to be quite lovely. See below.
arbit12 said:
Okay. Thanks for the info.
Click to expand...
Click to collapse
So, it appears that this question has motivated me to try making that function a reality sooner than later.
However, as far as I can see, the *ONLY* application for windows that currently deals with system images right now is Ext2Explore, which is a bit old and doesn't have command-line support.
Fortunately, there's source code for it, so I'm currently downloading Visual Studio and will see if I can add command line functionality, as well as make it launch with UAC prompting.
If I can make this work, my plan is to make one handler for .img files that works like so:
1. Look at the file passed to it and see if it's a boot image. If it is, extract and exit.
2. If it's not a boot image, try to extract it as a system image. If it is, extract and exit.
3. If it's not a boot or system image - pass it to explorer and mount as usual.
I can do # 1 and #3 already...it's just getting #2 to go.
Also, I've added a check in the installer that looks for the installation of notepad++. If it finds it, it will create additional associations for .xml, .prop, conf, config, .smali, and whatever else I can think of that I could possibly need to edit in a ROM.
Then, lastly, with all these additions, I'd like to make the installer a bit more verbose. Give some options so it's not just an all or nothing install, make it prettier, etc.
digitalhigh said:
Oh, no offense taken.
I came at this project, as I do with most, with the mindset of "OOOH, SHINY THING. I MUST SHOW EVERYONE." So, first thought was putting out the app, despite some of the install stuff being a bit dirty.
However, the next iteration is shaping up to be quite lovely. See below.
So, it appears that this question has motivated me to try making that function a reality sooner than later.
However, as far as I can see, the *ONLY* application for windows that currently deals with system images right now is Ext2Explore, which is a bit old and doesn't have command-line support.
Fortunately, there's source code for it, so I'm currently downloading Visual Studio and will see if I can add command line functionality, as well as make it launch with UAC prompting.
If I can make this work, my plan is to make one handler for .img files that works like so:
1. Look at the file passed to it and see if it's a boot image. If it is, extract and exit.
2. If it's not a boot image, try to extract it as a system image. If it is, extract and exit.
3. If it's not a boot or system image - pass it to explorer and mount as usual.
I can do # 1 and #3 already...it's just getting #2 to go.
Also, I've added a check in the installer that looks for the installation of notepad++. If it finds it, it will create additional associations for .xml, .prop, conf, config, .smali, and whatever else I can think of that I could possibly need to edit in a ROM.
Then, lastly, with all these additions, I'd like to make the installer a bit more verbose. Give some options so it's not just an all or nothing install, make it prettier, etc.
Click to expand...
Click to collapse
Captain_Throwback said:
Click to expand...
Click to collapse
Don't get too excited. I've never touched C++ before, and ext2Explore was done in VisualStudio.net and a WYSIWYG editor called QT. I found updated source for the program from 2012 and have gotten it to import into QT, however, it needs MingW and some other dependencies. I'll be lucky if I can even get it to compile again, let alone work, let alone work with added command-line stuff.
However, that's still the goal.
Also, I want to add wget (windows equivalent) stuff to auto grab and install java and notepad++ while we're at it.
So, I think Ext2Explore is more work than it's worth.
OSFMount, on the other hand, just let me mount a system.img as a removable disk with read-write access. I'm going to go down this road...
Good to hear that. Extracting system.img on windows can be a real pain at times - this would be great.
Hi everyone,
I have a Nook GlowLight 3. I don't like the default screensavers, so I'd like to delete them and (optionally) put in some new ones. Is this possible?
Maybe it's just a matter of getting into the Nook's file system and replacing their image files with my own (with the same filenames)?
This Nook is new. I don't mind voiding the warranty, but I'd rather not unless I know it will be worthwhile. Otherwise, I would try it myself. So I'm hoping some kind soul who has a NGL3 that they have already broken into would be willing to take a look at it for me.
Please let me know if I can help! Thank you!!
Robert
I've got too many Nooks and I'm far removed from stock.
Do you have a directory /data/sleep/
That used to have PNGs for some standby images.
Do you currently have the old, creepy authors?
I have not rooted it or anything yet, just plugged it into my Mac and looked at the default directories it comes with. There is basically nothing there– I even had to research online and experiment how to just create a directory where I could sideload a PDF. So, no, I haven't seen any directory like you mentioned. And I'm not sure what you mean about the old authors(?). The screensavers I have are Symbols and Quotes. In any case, this is my first Nook, and it's less than a week old.
So, do you think there is a good chance I could make changes to the stock screensavers?
The "old, creepy authors" were the screensavers that made the Brontë sisters look like the witches out of Macbeth.
These images are all packed away in /system/priv-app/partner.apk in res/drawable-mdpi-v4/
Code:
artboard_1.png
artboard_2.png
artboard_3.png
artboard_4.png
artboard_5.png
artboard_6.png
artboard_7.png
artboard_8.png
alexander_pope.png
chinese_proverb_00.png
cicero.png
jane_austen.png
john_wilson.png
lady_mary_montagu.png
louisa_alcott.png
robert_southey.png
thomas_jefferson.png
thomas_kempis.png
The list of images is in res/values/arrays.xml in quotes_imgs and symbols_imgs
The actual screensaver mechanism is com.nook.partner.screensaver.ScreenSaver (in partner.apk).
If you repack that all it won't have a B&N signature
I'm not sure how much that will break things.
In worst case you could resign everything.
I think that I'd just rewrite ScreenSaver to fetch PNGs from a directory like /data/sleep
That way, changing the collection would be easier.
Oh, and another thing...
As always, the sloppiness of B&N gets to me.
Those "quote" image files are ten times the size of the "symbol" image files.
Why? Because they have a very subtle dithering to the backgrounds.
It's nothing that you can see even on a regular LCD monitor, let alone on a black & white eInk panel with 16 shades.
So the file is basically trying to compress random noise. That doesn't work out well.
Below is what you get when you use the fill tool (red) in MS Paint on the image.
It leaves holes because the adjacent pixels aren't exactly the same value.
Oh, yes: I remember those goofy portraits.
OK, thank you– I really appreciate your help! I am excited to try this out when I can snag some free time. I will try to post what happened, too.
OK, I was able to pull that partner.apk file to my Mac, and unzip it. The images are there. Awesome!
So, I'm temped to create my own B&W/greyscale pngs, with the same dimensions, and give them the same file names. Then put them in the same locations, rezip (with an apk extension), and push it into place. I know it will have a different file size, etc, but do you think that will be a problem? Normally I'd just try it, but I'm trying to err on the side of caution.
Thanks!
Newtham said:
rezip (with an apk extension), and push it into place.
Click to expand...
Click to collapse
Yes, it should work.
There doesn't seem to be any problem with signatures.
I modified all my images for fun and it didn't break anything.
(Although, I've hacked so much stuff on this that the screensaver never activate. This is not my primary reading device.)
It must have some signature (the originals will do) or it won't be acknowledged as an APK.
Make sure that you keep the original file as a backup.
I'm still new to this, so basic question: what is a signature (in this case) and how do I create or modify it?
Thanks!
Newtham said:
What is a signature...
Click to expand...
Click to collapse
Signatures are the three (or more) files in the META-INF directory in the zip (apk).
If they are there, that's fine.
To learn about apk signing Google it.
@Newtham
Oh! I figured something out. I looked through the code.
If you just want to have one screensaver of your own (which you could manually change).
All you have to do is change some undocumented settings.
File: /data/data/com.nook.partner/shared_prefs/screen_saver_preference.xml
Code:
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
[color=red]<boolean name="pref_key_screen_saver_from_sdcard" value="true" />
<string name="pref_key_screen_saver_from_path">/sdcard/sleep.png</string>[/color]
<boolean name="pref_key_screen_saver_low_power" value="false" />
<int name="key_screensaver_img_index" value="8" />
</map>
OK, awesome, thanks!
About a week ago, I tried just modifying the image files, rezipping & renaming to apk, and pushing into place, but I didn't modify the signatures. So now I'm stuck on the boot screen. (I forced it off in the meantime, but since it's e-ink, its still showing the boot screen.)
I can still see it on the command line via adb, but I no longer have write permission so I can't push the original apk back into place. So that's my next task. I haven't had time to play with it since then. It's fun playing with this, I just wish I had more time.
Newtham said:
I no longer have write permission...
Click to expand...
Click to collapse
Well, you did it once, it's just a question of making /system rw:
Code:
# mount -o rw,remount /system
One of the silly things that B&N did was making the "screensaver" and the "wallpaper" the same thing.
I'll have to write some code to make them separate things.
Lol! As I dived into this I realized that I had been all over this ground before.
The stuff I wrote in https://forum.xda-developers.com/showpost.php?p=79994025&postcount=11 about using settings to disable the B&N wallpaper is true but not necessary.
You can disable all that silliness with:
Code:
# pm disable com.nook.partner/.daydream.DayDream
You can set a simple white wallpaper using my Wallpaper.apk app available in the signature
The wallpaper only appears as a background to a launcher (or any app that has no background).
The Glow3 4.7 & Glow4 5.0 both broke the Wallpaper, you need a separate patch for that, see below.
I had previously made a patch to cycle through user supplied PNGs as a lock screen.
That patch is available in the signature as nook45patch.zip
Code:
C:\> adb pull /system/framework/android.policy.jar
C:\> apktool d android.policy.jar -o AP
C:\> mergesmali /v \AP\smali Screen.smali
C:\> apktool b AP -o android.policy.jar
Then replace android.policy.jar and delete/backup/rename/whatever android.policy.odex
Then stuff your PNGs in /data/sleep
Erm, I think this mostly applies to Glow2 4.5
I'll look more closely at Glow3 4.7
glow45patch.zip works fine on the Glow3 4.7 & Glow4 5.0
So, the nook45patch.zip works fine on the Glow3 4.7
I kind of confused myself, strange things happen if you have no images in data/sleep.
I'll look into that too.
The Glow3 & Glow4 have this problem where B&N stole the functionality of wallpaper for sleep screen.
The background on launchers appears black even though the Wallpaper API changes /data/system/users/0/wallpaper correctly.
I should be able to solve this one too.
There was a minor bug in the old patch.
It would barf if you didn't have any user images.
The new glow45patch.zip is in the signature under mergesmali.
The aforementioned glow45patch.zip is a valid patch for Glow3 4.7 too.
There is also the issue of the black Wallpaper on Glow3 4.7 when using a stock Launcher.
Does anybody else have this/notice it/care?
With 4.7 B&N got rid of /system/priv-app/SystemUI.apk and put it all into /system/priv-app/partner.apk
This necessitated a change in the WallpaperManager since it's all a different package.
The actual ImageWallpaper.DrawableEngine.drawFrame() is a bit complicated.
I couldn't (be bothered to) figure out how it was supposed to work and where it was failing.
To my taste, anything other than solid white wallpaper on an eInk device is just distracting.
I wrote a small patch to make drawFrame() just drawColor() instead of scaling and rotating Wallpapers.
Is there any interest in that?
I have been working on this, but I can't get write access via adb anymore. I have tried everything I can think of, including your suggestion above. I can log in to the adb shell and run as root and make changes there. But anytime I try to push anything with adb, it tells me it is read-only. When I run rootnook.sh, it tells me I'm already rooted, but no superSU found (and then roots again, with no different results). adb root doesn't work, either.
The only major thing that's changed recently is that I installed the latest nook update, which I thought would be a good idea before I start hacking. Maybe that messed it up.
I'm stumped (which is not difficult to do...). Any suggestion on how to get back in there?
Thanks!
You probably de-rooted yourself.
Does adb shell give a # prompt?
Does the shell command "id" tell that you are root?
Does the shell command "mount" tell you that /system is rw?
Does the shell command "getprop ro.secure" say 0 (security is off)?
When in doubt, push to sdcard and then copy (cp) to where it should be.
Thanks! Moving it to sdcard did the trick.
I unpacked the apk with apktool, edited the images directly (didn't change the file names), repacked it with apktool, and then (finally, by using the sdcard directory) got it back to the Nook. And then copied it into place. But I still get the same results: the GUI gets stuck on the boot screen.
So, do you think this has to do with signing the apk file? I did a lot of research on it, but mostly what I found was how to sign your own file, not someone else's. Do you have any tips on how I can do this (if that's what's needed)? Thanks!!
(P.S. Thanks for the info on the glow45patch. I haven't had a chance to look at it too closely yet, but it looks interesting. I'd still like to mod the actual pics, though, if I can.)