Hi there,
The same application of mine is running on non-phone Android (2.1) based devices, and collecting data (stored in an embedded SQLite DB).
I have to retrieve these data without using networking / bluetooth, USB only. This desktop application is pure Java, running on a unique PC, each device is plugged once at a time, backuped and so on.
I thougth about using adb to get an SQLite shell and SELECT / dump data, but I'll have to map adb and SQLite calls and sockets in my java code. And it's pretty ugly, too.
Do you see another solution? If not, do you know about an adb wrapper in pure Java, or stuff like that?
Thanks in advance
Anyone? Need more info?
Last up? Any suggestion is welcome.
Put the device un USB storage mode and copy the file in your code.
zephirus said:
Put the device un USB storage mode and copy the file in your code.
Click to expand...
Click to collapse
I don't think that would work; databases are saved in the root:data/data folder, even if the app has been 'moved to SD card', which you need SU permissions to access.
To the OP: Maybe you can look at the "Terminal Emulator" program? It comes packaged with some ROMs, like the Froyd Villain ROM for the HTC Hero, and lets you run ADB commands from on your phone, so it might give you some inspiration about how to do that. I don't know if it's open source though.
Thanks for your replies.
@zephirus : I've tried this way, except that I use ADB to retrieve the DB file. That's one ADB call to map onto the Java code, but using mass storage will be a pain on windows (access/mount device by letter). Seems to work well for now.
@Steven__ : As previously said, no problem using ADB to retrieve the file. I'll have a look on Terminal Emulator, wich I don't know.
Hey everyone...I can't seem to find any help on creating a keystore. I created my first live wallpaper and have the apk, but I cant upload to the market until I create a keystore and sign the apk. I don't know how to do this. I have the jdk and sdk installed, along with Eclipse, but all the tutorials out there are way above my head.I don't know anything about java code and all tutorials assume that I do. Is anyone willing to help walk me through this? I don't even know how to get my apk file into Eclipse properly to start. Any help is appreciated.
* to make key
enter this into cmd prompt: cd C:\Program Files\Java\jre1.6.0_01\bin
and then this: keytool -genkey -v -keystore C:\Program Files\Java\jdk1.6.0_23\bin\keystore1.keystore -alias (your name) -keyalg RSA -validity 10000
*then to sign apk
(this is how I do it)
1.copy/paste the apk onto your desktop
2. change the extension to .zip
3. open the now .zip file
4. delete the "META-INF" folder
5. convert it back to .apk
6. open cmd prompt
7. paste this in (without quotes): "cd C:\Program Files\Java\jdk1.6.0_23\bin " (change the path if you have to first)
8. then paste this: "jarsigner -verbose -keystore (pathway to key file) C:\Users\(name of user)\Desktop\(appname).apk (name of key)"
*that is to sign it, not sure if that will work or if your key saved properly when you tried, let me know
It took me about 8 hours to figure it out when I first started too
yeah, or you could just use eclipse
go to file -> export project
and then it'll walk you through the whole process
it takes like 30 seconds
it still amazes me the number of people who do not know this
it's about 500 times easier if you just do it in eclipse
you can spend 8 hours trying to figure it out like hyperbyte did
or you can just use eclipse and be done in a few minutes
smaskell said:
yeah, or you could just use eclipse
go to file -> export project
and then it'll walk you through the whole process
it takes like 30 seconds
it still amazes me the number of people who do not know this
it's about 500 times easier if you just do it in eclipse
you can spend 8 hours trying to figure it out like hyperbyte did
or you can just use eclipse and be done in a few minutes
Click to expand...
Click to collapse
WOW really!? Why the heck didn't anyone else tell me that!? LOL I'm gonna try it now. Thanks for quick responses.
StoopidNoob said:
WOW really!? Why the heck didn't anyone else tell me that!? LOL I'm gonna try it now. Thanks for quick responses.
Click to expand...
Click to collapse
You can also right click on the project and go to Android Tools > Export signed application package
hyperbyteX's method also doesnt zipalign the package which the export wizard does and is reccommended.
http://developer.android.com/resources/articles/zipalign.html
Eventually advanced users would want to use an ant build script (and possibly proguard to optimize) but the export tool is fine for most stuff.
alostpacket said:
hyperbyteX's method also doesnt zipalign the package which the export wizard does and is reccommended.
http://developer.android.com/resources/articles/zipalign.html
Eventually advanced users would want to use an ant build script (and possibly proguard to optimize) but the export tool is fine for most stuff.
Click to expand...
Click to collapse
alostpacket said:
You can also right click on the project and go to Android Tools > Export signed application package
Click to expand...
Click to collapse
And this is going to let me publish in the market?? For sure?? LOL I'm sorry. Been going in circles with this. I'm completely new to Droid and everything that comes with it.
StoopidNoob said:
And this is going to let me publish in the market?? For sure?? LOL I'm sorry. Been going in circles with this. I'm completely new to Droid and everything that comes with it.
Click to expand...
Click to collapse
My method is just a different menu/way to get you to the same "export wizard" as smaskell reccommended.
And yes, once signed, you should be able to publish to the market.
Ok this is gonna sound even more stoopid...but how do I package the apk? I used a program someone provided and it automatically made the .apk file for me, which I was able to upload and install in my inspire, but I assume there's more to it than just exporting the .apk itself right?
There are basically two keys developers come across when developing.
1) The debug key that comes with the SDK and just allows devs to test their apps
2) Your private personal developer/publisher key (that you generate yourself)
In eclipse whenever you build the project it makes an apk signed with the debug key (you can't use this to install on other devices unless they have debugging enabled and cannot upload to the market with this key). This is just a standard key built into android for debugging.
When you go through the export wizard that we posted, it will save an apk that is signed with your key. You can give this apk to others to sideload and upload to the market. It will also help you generate a key and alias and password if you havent generated one before.
Whatever you do, SAVE your key and and remember your alias and password and do NOT give it out to anyone else.
This is how the market will know that an apk comes from you. If you lose this key, you wont be able to upload new versions under the same package name.
hope that helps.
Also, in your manifest.xml make sure you have
Code:
android:debuggable="false"
in the <application> tag
example:
Code:
<application
android:icon="@drawable/my_icon"
android:label="@string/app_name"
android:debuggable="false" >
<!-- your acitivities, services, and broadcast recivers are here-->
</application>
Hi,
I am currently trying to get into Android Developing and I am following a tutorial book called "Practical Android Projects" however, I have only got so far and I am coming across a problem.
I have installed the Android SDK and required files, and installed ant as per instructions here: http://ant.apache.org/manual/install.html (Under Windows and OS/2 section)
I am getting an error about my /res folder not existing, when it infact does exist, in the directory it specifies?
Please see screenshot at the following link: http://server3.uploadit.org/files/StuMcBill-cmdprompt.jpg
Thanks for any help you can give?
I am running Windows 7 Home Premium x64!
Stewart
I would suggest using eclipse. Especially for beginners it is alot easier than building everything on console.
It has nice plugins and the android emulator from the sdk is integrated.
100% agree with Dark3n.
Ant is a programming language in and of itself. (Well sort of a scripting language but whatever).
No need to try and learn two things at once. I'd suggest wait until your 2nd or 3rd app at least to learn Ant. You really don't need it unless you want to use something like ProGuard. (Which is yet another thing to learn and another thing I'd suggest waiting on).
Oh an for a possible quick fix type
>ant clean
And see if that helps.
EDIT:
Err nevermind -- looked at your screenshot... why are you running ant from the System32 directory? Is your Android project really in that folder?
Usually you set the path environment variable in your system properties in windows to add ant to the list of paths, so you can run ant from any folder.
Then you can open that folder, type cmd in the address bar and open a command prompt in your project directory. You then run ant from there which reads the build.xml file an default.properties and local.properties files in your android project folder.
OK, I will give eclipse a try.
RE system32 and ant: Well the book I am following said to use ant, and I just followed the instructions and it installed the project in System32.
Could I just substitute Eclipse for ant while following the guide?
I do have Ubuntu installed on this computer, would that be better / easier?
Eclipse is available for any OS.
Use the one you are most comftable with.
I think eclipse might even use ANT internally but you don't have to hassle with it.
Working in system32 is not adviseable, you should generally keep out of there .
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.