Looking for a program to convert .JAR to .APK so I can install programs/games on G1
The progam/app at http://www.netmite.com/android/ automatically converts .JAr to apk, but only does so from the Web, and I've tried to direct its url option to a a .JAR I've web hosted and it doesn't do anything, doesn't download the file or anything.
The sites that it gives you to choice from under its menu option suck, and don't allow files to be uploaded, most of the files don't support touch screen and don't work well with the G1's front soft keys.
J2ME MIDP Explorer just needs an option to install/ convert from the sd card
I've got a bunch of Java midlets on my PC and I want to get them to my G1 or at least play around with them in the emulator.
Any ideas?
Thanks
Maybe this is in the wrong Forum? Mods any thought?
Thanks
Dalamak said:
Maybe this is in the wrong Forum? Mods any thought?
Thanks
Click to expand...
Click to collapse
You can't just convert a jar to an apk. It has to be compiled for android. Android's java library doesn't have all the swing stuff that's in normal java, so the app most likely would have to be re-written to work on android
JesusFreke said:
You can't just convert a jar to an apk. It has to be compiled for android. Android's java library doesn't have all the swing stuff that's in normal java, so the app most likely would have to be re-written to work on android
Click to expand...
Click to collapse
Pretty sure MIDlets (MIDP jars) don't use Swing or awt. They have a separate user interface api under javax.microedition.lcdui
As for converting MIDP programs to runnable APKs, there is certainly a way. Technically it isn't a conversion but the use of a wrapper around the unconverted MIDlet. This is the approach that Opera Mini for Android uses. More info:
http://labs.opera.com/news/2008/04/10/
From the same article:
"The only major task was to replace the AWT/Swing graphics backend of MicroEmulator with Android specific APIs."
Id quite like this to work with bloover, though the blue tooth support needs to be extended in the g1, headset only. I want to send files!!
JesusFreke said:
From the same article:
"The only major task was to replace the AWT/Swing graphics backend of MicroEmulator with Android specific APIs."
Click to expand...
Click to collapse
Right since MicroEmulator is a J2SE program, it uses Swing/awt classes. Since the heavy lifting of porting MicroEmulator to Android has already been completed, you don't have to worry about it. Theoretically, anyway.
Compiling MicroEmu for Android and running a Sudoku game:
http://microemu.blogspot.com/2008/11/running-java-me-applications-on-android.html
i try to use netmite to conver some jar file frome my web site
there is no garanty to aonverted java file work good in android but all of converted jar file all runing and then maybe it (work/crash/or slow)
Try UpOntek - jar to apk conversion service which includes optimization tips for your app.
veda_sticks said:
Id quite like this to work with bloover, though the blue tooth support needs to be extended in the g1, headset only. I want to send files!!
Click to expand...
Click to collapse
use the program blutooth file transfer
I was thinking last night, that maybe by recreating the entire system.img and userdata.img we can add more files the G1 can read.
but
I guess it will take a long time but if all extreme developers pitch in then we can get it done in no time.
Maybe we can add more than just native file types... this could be an innovation.
What exactly are you asking about?
Running software written in, for example, C?
This is possible right now to a certain extent. Terminal software (i.e. text only) can be cross compiled and run from the terminal. This is not a challenge, or for that matter, even particularly innovative.
What I suspect you are after is more along the lines of running GRAPHICAL software that is compiled for the native hardware. Neat idea, would be ok for now, but this will introduce SEVERE problems once other hardware shows up. Code that is compiled in a native executable format can only run on the same hardware (or sufficiently similar) as that for which it was compiled, so if you had software compiled for one hardware set, it will NOT work on another. That is the reason why the UI is all JAVA.
lbcoder said:
What exactly are you asking about?
Running software written in, for example, C?
This is possible right now to a certain extent. Terminal software (i.e. text only) can be cross compiled and run from the terminal. This is not a challenge, or for that matter, even particularly innovative.
What I suspect you are after is more along the lines of running GRAPHICAL software that is compiled for the native hardware. Neat idea, would be ok for now, but this will introduce SEVERE problems once other hardware shows up. Code that is compiled in a native executable format can only run on the same hardware (or sufficiently similar) as that for which it was compiled, so if you had software compiled for one hardware set, it will NOT work on another. That is the reason why the UI is all JAVA.
Click to expand...
Click to collapse
Hmm, what about if you had an app that compiled the c code(akin to gcc but in apk form) aand executed the app from there? In theory that'd give you a little app launcher from which you could run native apps... plus it should be a lot faster than the java code of apks
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
revxx14 said:
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
Click to expand...
Click to collapse
Compiling desktop apps for ARM using VS 2012 gives an error message, but it can be bypassed. Not sure if the results will run in Windows RT though.
Of course there's no way to find out until Windows RT devices are released to the public, because everyone who has access to one is under NDA. Have some patience.
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Pseudonym117 said:
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Click to expand...
Click to collapse
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
lseidman said:
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
Click to expand...
Click to collapse
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
xanderkaiber said:
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
Click to expand...
Click to collapse
well the simple way would be to sign it. HOW to sign it is a completely different problem... there may be a group policy change or registry edit to turn off signature verification, but i am not familiar with windowsRT at all.
phailyoor said:
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
Click to expand...
Click to collapse
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Windows RT is basically just Win8 recompiled for ARM, with one major exception: EXE files need to be signed by Microsoft before they will run. This means that MS can release desktop apps just fine - they have the signing keys, after all - but third-party software can't run by itself (as a desktop app) and will need to be bundled as an .APPX file (Metro-style app bundle).
If you want to try bypassing the signature check, there are a few things you could attempt. One would be to create your own signing certificate, install the public key in the OSes root code signing cert store (not the per-user store, though it qprobably wouldn't hurt to install it there too), and then sign your test apps with that cert. MS *probably* used certificate pinning - where a specific cert is used, rather than just any cert present in the OS of sufficient trust level - but they may not have, too. Alternatively, you could try looking for some legacy or debug functionality to disable the code-signing. Finally, you coul try using a built-in program, rundll, to invoke your applications.
I can't test any of this right now, because I don't have an RT device. There's a lot of research on them that I want to do, though.
Quote from one very old MS Windows 8 document, from those times when windows RT was called "woa" (2011). Everything could have changed from those days.
Description of the change:
WOA platforms will require that all desktop binary images be signed with a trusted Microsoft certificate. Any unsigned code will fail to load. This document describes the technical steps required to enable unsigned test, development, or manufacturing applications to run. This document does not cover Metro Style applications for which there is a separately documented signing requirement and developer licensing.
Action required
In order for any test binary or tool to run on WOA platforms you must do one of the following:
· Register the install location of your test binaries as an exclusion path, OR
· Attach a Kernel Debugger and disable checking by setting the appropriate registry value
...cut...
2. Scripts - Scripts will be allowed to run if the script host (e.g. cscript.exe, cmd.exe, etc.) is Microsoft signed or is run under an exclusion path.
...cut...
How to register your test binaries in an exclusion path
...cut...
Exclusion paths are listed in the following registry key in REG_MULTI_SZ format:
Key: HKLM\SYSTEM\CurrentControlSet\Control\CI\TRSData
Value: TestPath
Paths added to this key should be in one of two formats:
1. Path (recursive): \Program Files\TestAutomationPath
2. Binary (specific): \Program Files\TestAutomationPath\mybinary.exe
Note: Do not include the drive letter of the volume. Each path will be excluded across all volumes.
...cut...
The following paths are restricted and cannot be added as an exclusion:
1. \
2. \Windows
3. \Windows\System32
4. \Program Files
...cut...
How to disable signature verification with an attached Kernel Debugger
To disable signing verification when a Kernel Debugger is attached the “DebugFlags” value must be deleted from the “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI” registry key and the system must be rebooted. After this Signing Verification will not take place.
This can be scripted by putting the following in a .cmd script and executing with admin privilege:
cmd /c reg delete "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI" /v DebugFlags /f
shutdown -r -t 0
...cut...
Note: Enabling Kernel Debug will not be allowed by default on machines with Secure Boot enabled. Either Secure Boot will need to be disabled, or during boot the F8 menu selection to EnableDebugging must be chosen.
...cut...
At a later point, changes will be made to Windows 8 builds which will enforce that only machines configured as “Debug System” will support exclusion paths.
A “Debug System” is will initially be identified by the presence of the Microsoft Test Signing CA in the UEFI signature database (“db”).
...cut...
Note: If there is a need to run unsigned tools, the system can be configured as a “Debug System” during manufacturing but there must be a step in the production process that removes the Microsoft Test CA.
Production machines must not ship with the Microsoft Test CA in the db.
Click to expand...
Click to collapse
First we need to get hands on ARM device. I'd recommend Qualcomm-based, as chinese friends regularly leak their docs/sources. MS Surface is Tegra-based, so don't buy it
And one more thing:
This document “Enabling Debug Mode for Development, Manufacturing, and Support of Windows RT Devices” discusses placing a production device into ‘Debug Mode’ is accomplished by creating a per device Windows Debug Policy using tools provided by Microsoft.
Click to expand...
Click to collapse
Unfortunately I don't have “Enabling Debug Mode...” document, as I don't have access to connect.microsoft.com. Anyway it would not be helpful for us, end-users.
So to turn on a device to debug mode - you'll need a special "something" that is signed for your particular device. Sign is based on 2048-bit key, so you can't bruteforce it. But you can try to hack UEFI. UEFI is partially opensourced, so you can start to study its code now from edk2.sf.net
And one more way. Remember the test signing mode in Win7+. It is still present in Win8. Turn it on via bcdedit on your RT-device, use your own certificate to sign your driver or your program, ..., profit.
But be careful when hacking. There are known problems with BitLocker when test signing mode is on. The OS simply would not boot. Lets hope that we could disable BitLocker on our devices...
Just tried editing the registry to add a testing path. Didnt work
Still asks for certificate
xanderkaiber said:
Just tried editing the registry to add a testing path. Didnt work
Click to expand...
Click to collapse
According to MS document - this would work only on "debug mode"/"debug system" devices.
Can you turn on the test-signing mode:
Code:
In elevated CMD type:
bcdedit.exe /set {globalsettings} testsigning Yes
bcdedit.exe /set {bootmgr} testsigning Yes
bcdedit.exe /set {current} testsigning Yes
and try to sign your app with your own certificate I hope that test signing is still present on WinRT.
But first check that you are not using BitLocker (the "get-bitlockerVolume" command in admin's powershell). According to MS docs the retail device would not boot in this case (this info is taken from windows phone 8 "portico" docs, so may be unrelated to WinRT devices).
danchar4 said:
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Click to expand...
Click to collapse
Theres some info on the web somewhere for a config change to VS2012 that lets it build ARM desktop apps
Not that you can run them due to the signing issues
http://stackoverflow.com/questions/...op-programs-be-built-using-visual-studio-2012
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
xanderkaiber said:
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
Click to expand...
Click to collapse
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
eorsini said:
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
Not a surface, a Qualcomm engineering sample device. But I imagine it would definitely work on the surface also.
xanderkaiber said:
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Click to expand...
Click to collapse
Great news
Seems that turning on the test-sign mode would soon be a must on ARM devices, at least for those of us who need programs like VLC player, DosBox, FAR manager and so on.
As far as I can see, you could port pretty much anything (as long as it's c++) if you can get the source code.
Might give VLC a try now
Doesn't seem like a very good solution to me though.
While it's nice that progress is made, I think that running unsigned apps should be the primary focus - Microsoft could revoke the keys at any time.
(Disclaimer: noob.) As with previous poster, I can't post attachments in the right place, so apologies to people who don't want to read about WinRT ports.
This is vim 7.3. I included in the zip a diff against the 7.3 source tree for anyone wanting to build themselves. These binaries were built with "OPTIMIZE=SPACE" and the patch uses a CRT DLL so the binaries are much smaller than the x86 versions.
For those wishing to run the binary:
1. unzip somewhere
2. unzip /pub/vim/pc/vim73rt.zip from ftp.vim.org into the same location (couldn't include these due to attachment size limits, and can't link due to being a noob)
3. [UPDATED] Remove vim\vim73\libintl.dll. This is included in the vim73rt.zip file, is not compiled for ARM, and is not part of the vim source distribution.
4. run vim\vim73\install.exe. This is a console app that will allow you to configure install locations and settings.
No known bugs, but no extensive testing either Credit to all vim authors, bugs are my fault.
Fantastic, thank you very much! It's great to see stuff like this.
The full URL for the runtime files: ftp://ftp.vim.org/pub/vim/pc/vim73rt.zip
UPDATE: Runs well, except every time it tries to start, it complains (multiple times) about vim\vim73\libintl.dll being "not designed to run on Windows or it contains an error."
Assuming it's not just an unpacker problem, this may be something that should be addressed. However, the programs (vim, gvim, install.exe, etc.) run fine anyhow. I just renaked that file to libintl.dll.bad and now everything runs without the warnings.
GoodDayToDie said:
UPDATE: Runs well, except every time it tries to start, it complains (multiple times) about vim\vim73\libintl.dll being "not designed to run on Windows or it contains an error."
Click to expand...
Click to collapse
Yes, when I prepared the full .zip I deleted this, forgot to include that in the instructions. It's an x86 DLL included in the vim73rt.zip that doesn't seem essential. The applications don't link to it explicitly.
This is fantastic! I was looking at tackling vim but hadn't gotten to it yet... Thanks!
Thanks for your work on this, working great for me.
A couple of quick notes. Is it possible to update vim to 7.4 on my surface or will trying this break it? Or any chance for an updated version to be compiled for Windows RT?
Also I can open the standard vim (not gvim) from the icon on the start screen, but the vim command does not work in the run menu or the command prompt, is this a limitation or a bug?
Mod edit: Not tested and not working, doesn't warrant a development release. Please let us know when you have tested and got it working. Till then - thread is being closed.
Doesn't work, there is no JRE on the Surface.
Pro tip: Java != JavaScript. There is *no* support for Java on the Surface without hacks. Once you do those hacks, there is no need for a special hack to run EXEs (unless they are non-ARM programs, and there are other hacks to run those).
The Dev is a pure.noob
Click to expand...
Click to collapse
.................................
This appears to be a program that was created to bypass execution restrictions placed on laptops distributed by the 'Department of Education and Training' of South Wales.
I have no reason to believe that the OP wrote this, nor that he has any idea what ARM even is. Honestly, I believe he posted it hoping that a few idiots would donate to his paypal.
Looking through the files:
The jar looks innocent enough, except for where it loads the .dll (it kills then restarts Explorer. Odd, yes, but that's hardly malicious in and of itself)
The .dll does a few suspect things like checking for a debugger and running processes under different (restricted?) tokens, and it has an awfully large number of functions in it for what it appears to do. It checks for a debugger, and if it's present skips a whole large block of code then triggers a breakpoint followed by exiting. I believe it's doing that in a vain attempt to thwart reverse engineering tactics.
Note that I haven't actually ran any of these, this is going purely off of decompilations for the JAR (which I can read quite well) and disassemblies for the .dll (My x86 assembly is a bit shaky at best)