adbgrab.exe - Win32 frame grabber for Android - Android Software/Hacking General [Developers Only]

AdbGrab is a Win32 frame grabber for Android devices.
It previews the grab and allows you to mouse around and read actual Android coordinates.
You can also click on things and the Android gets the clicks.
It also supports various navigation keys.
Because it has to grab frames over ADB it's not spectacularly fast.
If you have a device with a broken screen it could be very useful.
This is a work in progress with features coming.
It uses a mixed command line/GUI interface.
Actual savings of grabs is coming, I'm working on optimizing 565 stuff. Done
Download in the signature.

Provide a link in the post itself. The signature can't be seen in Tapatalk
Source of this exe?

joluke said:
Provide a link in the post itself. The signature can't be seen in Tapatalk
Source of this exe?
Click to expand...
Click to collapse
http://www.temblast.com/android.htm

Ok, already a new version.
Code:
adbgrab foo.png [color=red]<-- just save to the path and exit[/color]
adbgrab [color=red]<-- run interactively with window[/color]
(This also works with pesky RGB565 frame buffers like in Nooks.)

A little newer version is out.
The progress bar is cleaner.
A bug was fixed where it would hang if the device had no screencap capability (like some recoveries).

Related

[AIR]Making/Testing AIR on Eclair

Hey all.
Sony Ericsson have stated quite clearly.. "No Flash on X10". Despite being quite categorical, there is much more to the story... so sit back with a coffee, and allow me to explain;
{disclaimer: i've only had an Android smartphone (Nexus One) since about June, so my experience had been exclusively using Froyo until now}
As far as i'm aware, Flash-Lite ran on certain HTC devices with Android Eclair (2.1) but this was done thru the device's default browser using webkit's plugin permission.
Flash 10.1 on the other hand is designed to run on Froyo (2.2) using a more direct Google plugin to the browser. (possibly an API not reliant on webkit as default, thus allowing other browsers to gain plugin access)
Anyway.. Sony Ericsson, for whatever reason, hasn't included either of these methods in this Eclair release. Conspiracy theorists may point to the coming PSP-phone as one reason to omit Flash.. ie. free multiplayer web-games.
So anyway, that's the bad news! No browser-based Flash unless it gets hacked into X10 by someone, or the bootloader get cracked, etc etc.
Ok, now the good news;
Hardware performance isn't a factor, as X10's Arm7 CPU IS supported by Adobe Flash + Air when running Froyo, as it clearly states X10's compatibility on their developer page.
Even better news for flash aficionados;
Lucky for us, Adobe made an early version of Air (ie. Flash outside the browser) for Android which runs just fine on Eclair. Although it's no longer under development (hasn't been since June) it's therefore unsupported by Adobe, and missing the odd feature such as GPU acceleration.
However, my early tests show it runs pretty well, comparing it to my Nexus One at least.
There are some limitations such as only running newer Actionscript3, (and no multi-touch, ha-ha ;O) ..but i can still see a great opportunity promoting and supporting Air on the X10. More so since every Air app or game i've seen so far only runs on Froyo.
As i see it, there's now a distinct niche supporting Air for Eclair userbase, so i hope some of you will consider helping me to exploit it. I'm here to help however i can, like porting as much stuff as possible to run on our Eclair devices, and ask anyone who's interested to offer support such as testing, designing, coding, or whatever. (PM or post here if interested to help out) I also propose a unique identifier; 'EPX'. The meaning will become obvious later.
To kick things off, i've attached a splash image, the Air Runtime for Eclair, and a sample game to test it. Here are the details about the game;
-------------------------------------
- Called "Code Bummer" made by Jesse Freeman, Dan Wolfe, Sean McCracken. (renamed "Hobo" with new icon, and recompiled to run on Eclair)
- Source code; http://github.com/jessefreeman/codebummer (a very clean example of a flash game for Android!)
- Description; http://www.appbrain.com/app/code-bummer/air.com.gamecook.CodeBummer (members will notice it says "Your device has Android 2.1. However this app is for Android version 2.2 and higher")
- Performance Tip: I find that after starting the game, the responsiveness is a bit slow, so i press back button (out of the game) then reload back into the game, and performance is much more playable.
-------------------------------------
Enjoy!
[UPDATE]
Anyone interested in developing Air for Eclair apps or games (that will also work on the latest Air for Froyo runtime) should stick to ONLY using the June 3rd SDK here...
(AIR25_win_sdk_20100603.zip)
http://www.mediafire.com/?m19cetvay9xqx38
Or the June 3rd CS5 Air Extension here...
(AIRforAndroid_FlashCS5_060310.zxp)
http://www.mediafire.com/?22hewf5kg98u3sd
Both of ^these are for Windows developers only.
We are also looking for the existing Linux and Mac SDK's dated the 3rd of June. If you have one of these, then please let us know, so that we may share it with everyone who needs it.
Cheers!
hi
that`s really good news(?) for us
unfortunately I have no knowledge in these areas but no doubt that I make available to serve as guinea pigs (?)
just hope this idea don`t die young and devs who had the knowlage will help you on this
Air for Android Developer Links
Thanks. It's a big catchup being couple of years behind the java devs, but strength in numbers helps.
Useful links for anyone getting started with Air development on Android;
"Using AIR for Mobile Development" (slideshow) *new*
"How to Add a Splash Screen to Your Air for Android App"
"How to Import MovieClips into a Flash Builder ActionScript Project"
"Optimization Techniques for Air for Android Apps"
"Sample Employee Directory Application using Flex and AIR for Android"
Using The Accelerometer Sensor in ActionScript 3
...
All my knowledge goes to AS3 and that is it. No Java or anything else. But testing wise, I am all here to help.
Is it not possible to port the Plugin from 2.2 to 2.1 or to install HTC Browser?
great it works quite laggy but a great start!
cuddles100 said:
great it works quite laggy but a great start!
Click to expand...
Click to collapse
Glad to hear it.
If you follow the performance tip (written above in red) then it runs as smooth as the original 80's coin arcade classic that it's based on.
http://en.wikipedia.org/wiki/Frogger
Nimche said:
All my knowledge goes to AS3 and that is it. No Java or anything else. But testing wise, I am all here to help.
Click to expand...
Click to collapse
Ahh.. that type of "flash junkie" haha. I thought you meant flashing roms.
Anyway, Air on Android is pure AS3 development, unlike the desktop version which could run Html or Javascript seamlessly...
http://en.wikipedia.org/wiki/Adobe_Integrated_Runtime#JavaScript_frameworks
In fact, coming from Actionscript background, i was impressed enough with it's implementation to switch almost entirely to Javascript coding in the early versions of Adobe Air which were codenamed "Apollo".
So although the desktop version of AIR includes the WebKit HTML rendering engine, this is not supported in Air for Android. (i'm guessing the overhead of running webkit alongside AS3 engine was too heavy for general smartphone use)
However something called "StageWebView" appears to be supported, so i'll look into how that works.
Wolfbreak said:
Is it not possible to port the Plugin from 2.2 to 2.1 or to install HTC Browser?
Click to expand...
Click to collapse
An attempt was made...
http://forum.xda-developers.com/showpost.php?p=6569529&postcount=16
^That whole thread makes excellent reading if you're deep into webkit hacking!
Air for Eclair Source Code
Keeping to the same theme as Code Bummer.. here's a bitmap side-scroller sample by 'theflashbum'...
https://github.com/theflashbum/BitmapScroller/downloads
The size is 9mb cos it includes 29 images. The images are truely funny for any hardcore flash coders, but the side scrolling to way too jumpy to be of any use as is. (...unless you want a migrane as an excuse not to go to work today! lol)
I7redd said:
Glad to hear it.
If you follow the performance tip (written above in red) then it runs as smooth as the original 80's coin arcade classic that it's based on.
Click to expand...
Click to collapse
Didnt read that bit. lol. Yeh the lag pretty much disapears when u do that awesome!
cuddles100 said:
Didnt read that bit. lol. Yeh the lag pretty much disapears when u do that awesome!
Click to expand...
Click to collapse
Thanks for the confirmation. (tip now highlighted)
It does the same on my Nexus running Froyo, so not sure yet what's causing that to happen. We need a few more sample games to see if it happens on Air generally, but for now it's quick fix that works.
I7redd said:
Ahh.. that type of "flash junkie" haha. I thought you meant flashing roms.
Click to expand...
Click to collapse
I did mean both of them. Flash phone and development for AS3. Hope to make something out of this.
Cheers,
Edit> That was nice. OT, how do you pack an apk off flash?
> how do you back an apk off flash?
Not quite sure i understand.
To "back out of flash" means pressing hardware back button. The game suspends, so when you go in again (pressing game icon) it continues where you were, but also plays smoother.
To back up an apk can use normal backup app like Titanium.
I7redd said:
> how do you back an apk off flash?
Not quite sure i understand.
To "back out of flash" means pressing hardware back button. The game suspends, so when you go in again (pressing game icon) it continues where you were, but also plays smoother.
To back up an apk can use normal backup app like Titanium.
Click to expand...
Click to collapse
I fixed it 4 minutes before your post anyways I meant pack an apk. How do you turn air application into android app?
Nimche said:
...development for AS3. Hope to make something out of this.
Click to expand...
Click to collapse
Cool.
These XDA forums have developer sections, thou to me at least, they seems slanted towards rom development, not apps, so I thought i'd start off a topic about testing Air, and see how the response is.
If there are people who are also keen to develop using Air for Eclair, then i'm happy to help get them started, or organize a group project. Will see how it goes.
For myself, i'm using Flash Builder 4, so switching between Froyo or Eclair involves overcopying the respective SDKs in Flash Builder folder..
C:\Program Files\Adobe\Adobe Flash Builder 4\sdks\4.0.A
For Froyo we use latest build [09/30/10] ...but for Eclair we have to use the older SDK dated the same as the Eclair Runtime [06/03/10] that i attached on the first post. I've uploaded (18mb zip) the older "Eclair SDK" for those who want to try compiling something...
http://www.mediafire.com/?m19cetvay9xqx38
Any issues, let me know.
Nimche said:
I fixed it 4 minutes before your post
Click to expand...
Click to collapse
Heh. I didn't reload the page before answering. (also a bit slow typing with a cat on my lap)
Nimche said:
How do you turn air application into android app?
Click to expand...
Click to collapse
After building your SWF file.. use (windows) dos command something like..
adt -package -target apk -storetype pkcs12 -keystore cert.p12 -storepass password my_app.apk my_app.xml my_app.swf
Quick way is to put ^that into a make.bat file.
Then put "adb install -r my_app.apk" into an install.bat file.
Then put "call make.bat & call install.bat" into a run.bat file.
Then double-click run.bat and it's all done in 1 step.
very good stuff! I will glady test stuff for you's
Sent from my X10i using XDA App
I7redd said:
After building your SWF file.. use (windows) dos command something like..
adt -package -target apk -storetype pkcs12 -keystore cert.p12 -storepass password my_app.apk my_app.xml my_app.swf
Quick way is to put ^that into a make.bat file.
Then put "adb install -r my_app.apk" into an install.bat file.
Then put "call make.bat & call install.bat" into a run.bat file.
Then double-click run.bat and it's all done in 1 step.
Click to expand...
Click to collapse
Cool sh*t. I will make some stuff for testing. Happy that AIR works here and I was going to be disappointed but now I have more purpose for using 2.1//

How can I view the source code of an android app?

This is probably a noob question, but how can you view the coding of an android application? I just had a small test app developed for me and I would like to look at the "guts" of it.
I downloaded the emulator but I haven't been able to figure out how to see my app's code using it. Maybe there is another way that's easier? You know, something akin to the "view page source" tab enabled in many browsers that allows you to see an html page's code?
I tried opening it with TextEdit on my Mac but it says its not readable.
What's an easy way to take a look at/edit the code?
Thanks in advance for your help!
Android-apktool
Android-apktool - A tool for reengineering Android apk files ...
http: / / code.google.com/p/android-apktool
It is a tool for reengineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications; it makes possible to debug smali code step by step. Also it makes working with app easier because of project-like files structure and automation of some repetitive tasks like building apk, etc.
It is NOT intended for piracy and other non-legal uses. It could be used for localizing, adding some features or support for custom platforms and other GOOD purposes. Just try to be fair with authors of an app, that you use and probably like.
Click to expand...
Click to collapse
Google "apk manager"
Sent from my DROIDX using XDA App
Thank guys, however it says it can't be found - see this screencast I recorded: screencast.com/t/kII8UcBqE1RQ
Any ideas?
I feel like it can't be that complicated, but there is almost no info about in on Google...

Quake 2 on Windows RT

Only created my account today, so I don't have enough posts to put this in the developer section. Maybe someone can help me out.
I managed to get the Quake2 source from Ids ftp server to build (with a lot of warnings) for ARM in Visual Studio 2012.
I've attached a screen shot and the binaries to this post.
All you need to do is drop the pak0.pak and players folder into baseq2.
Enjoy!
EDIT: should also mention that this is a native port (not .net or winrt) -- props to XDA guys for the hack!
EDIT2: for those with errors, keep in mind you need the pak files and players folder from the quake2 install for this to work (or you can grab them from the demo). Google is your friend! . If you encounter the famous "water crash" then run "sw_waterwarp 0" in the quake console.
EDIT3: For a joke. I've added the OpenGL Quake2 renderer and a software based OpenGL implementation (built from an older version of Mesa3D) as attachments. Given that Windows RT doesn't have support for OpenGL this is probably as good as its going to get without a port that has Direct3D support. While the OpenGL version looks much better, be warned.. it runs __very__ slow. If you want to give it a try, just go into video options and change the 'driver' option to "default opengl". Enjoy!
EDIT4: So.. in an effort to clean up some of the bugs, I stumbled upon KMQuakeII which has an 'unofficial' 3.23 patch for the Quake 2 source. I've managed to compile that version of the source for ARM. I was hoping this would fix the full screen issues, but it didn't. Regardless, there are probably worthwhile bug fixes anyway.. so I'm posting it here. There are also extra video modes in this version (very easy to add btw!) however the 1366x768 mode didn't work correctly on my Surface.
Well done! Link added to the list. Much appreciated...
bfosterjr said:
Only created my account today, so I don't have enough posts to put this in the developer section. Maybe someone can help me out.
I managed to get the Quake2 source from Ids ftp server to build (with a lot of warnings) for ARM in Visual Studio 2012.
I've attached a screen shot and the binaries to this post.
All you need to do is drop the pak0.pak and players folder into baseq2.
Enjoy!
EDIT: should also mention that this is a native port (not .net or winrt) -- props to XDA guys for the hack!
Click to expand...
Click to collapse
cool, seems to run nicely, -just using one core.
At first : Thanks for the work!
But i get an Error :"Couldn't load pics/colormap.pcx
(on Surface Jailbrocken)
I can't manage to open it. It says there is an error.
Another question... I want to do it for Bluestacks. Do you know anyone that could've done this? Thank you.
save_jeff said:
At first : Thanks for the work!
But i get an Error :"Couldn't load pics/colormap.pcx
(on Surface Jailbrocken)
Click to expand...
Click to collapse
Make sure you have the pak files and players folder from your quake2 install in the baseq2 folder. If you don't own quake2 then you can grab these files from the quake2 demo install (google for it). Good luck!
Awesome job!
I got mine working smoothly
There is some issues that often when I load saves the game crashed (quake2.exe has stopped working)
I have no idea. Save game works perfectly and start new game works as well.
Looks like this guy back in 2005 have the same problem (except he is using... Amiga?): ht tp://eab.abime.net/showthread.php?t=17808
Tanks i did not know that ;]
I Will get a Demo right now ans try ist.
Does it work with any Version of quake II ?
---------- Post added at 10:54 PM ---------- Previous post was at 10:29 PM ----------
Okay now it works like a charm! Realy impressiv
shog7n said:
Awesome job!
I got mine working smoothly
There is some issues that often when I load saves the game crashed (quake2.exe has stopped working)
I have no idea. Save game works perfectly and start new game works as well.
Looks like this guy back in 2005 have the same problem (except he is using... Amiga?): ht tp://eab.abime.net/showthread.php?t=17808
Click to expand...
Click to collapse
Yeah, there could be several bugs in it. This is built straight from iD's source. There are many other 'ports' of quake2 that have encountered and (in some cases) fixed various bugs. Still, its extremely playable even with a few annoying bugs!
I cant get mine to go to full screen.... is this usual behaviour?
advancedservers said:
I cant get mine to go to full screen.... is this usual behaviour?
Click to expand...
Click to collapse
Yep. The pure Quake2 source has known issues with full screen on "odd" resolutions. Given the time frame for when Quake2 was developed.. the 1366 x 786 resolution that is common today doesn't make any sense that's why its "not supported". There were some unofficial patches added to Quake2 many years ago to add wide screen support and more resolutions. A lot of people also fixed the problem by just using the OpenGL version (which I could also provide binaries for.. but its _dog_ slow). What I've ported here is the 'software render' which got very little attention once the '3d boom' hit. If I get bored, I may see if I can get full screen working in the software renderer.
Joystick or Xbox Controller?
App is cool and runs well with mouse or keyboard but I have tried joystick and Xbox controller (both recognised by WinRT) and app ignores both. I have turned on Joystick under options.
I didnt get any bugs yet.
But Fullscreen would be nice
Woww this game bring me so many good memories nice work!!!
advancedservers said:
I cant get mine to go to full screen.... is this usual behaviour?
Click to expand...
Click to collapse
Same here. 800x600 is the best resolution to me..
Btw can you load your saves after close the game and restart it?
For what its worth, I've updated the original post with 'newer' binaries and software based OpenGL support. The fullscreen thing is also bothering me so I'll put some effort into that over the next couple days -- hopefully its been fixed in a different Quake2 port and I just need to migrate the code over. Cheers!
If you don't mind me asking where did you get the source files from? I would have done this two days ago but I couldn't open the project files from id's github. I then tried quake 3 and doom 3 but getting those working is a different problem entirely. Those games have inline assembly in them that I don't have the skill to replace.
johnnyfives12 said:
If you don't mind me asking where did you get the source files from? I would have done this two days ago but I couldn't open the project files from id's github. I then tried quake 3 and doom 3 but getting those working is a different problem entirely. Those games have inline assembly in them that I don't have the skill to replace.
Click to expand...
Click to collapse
The source came straight from ftp.idsoftware.com. There is a lot of pain in getting a working vs2012 solution file and convincing the source that Win32 does not imply x86! Many issues with libs and older CRT functions too. Just takes time, patience and good experience with VS & C code.
You're absolutely right about Q3 or Doom3. They will require an overhaul and will need to be ported to Direct3D10+. Sadly I don't have the spare time to get _that_ involved -- though I'm happy to help if someone wants to lead the charge.
Cheers
Game crashes sometimes when I try to load a saved game. Also performance is far from what I expected. I remember playing it on my Nokia n95 with software renderer and it was fluid, on surface higher resolutions cause serious performance degradation. The more I use desktop apps ported to Windows RT(quake, dosbox) the more I think that tegra 3 suck.
bartekxyz said:
Game crashes sometimes when I try to load a saved game. Also performance is far from what I expected. I remember playing it on my Nokia n95 with software renderer and it was fluid, on surface higher resolutions cause serious performance degradation. The more I use desktop apps ported to Windows RT(quake, dosbox) the more I think that tegra 3 suck.
Click to expand...
Click to collapse
Same loading problem here...
But it runs pretty fluid on my Surface...

[app port] [1/23] dosbox with thumb2 dynrec

hi all,
I've updated DOSBOX's dynrec core to take advantage of the THUMB2 ARMv7 instructions that must be supported on Windows RT. Among other things, this includes being able to move immediates to registers without using a PC relative load, 32-bit instructions that allow access to all registers, etc. I also added a PLI instruction to preload a cacheblock into the instruction cache before it is executed, and PLD instructions to prefetch data for a minor speedup.
Testing on doom timedemo, I get 3721 realtics, which is a modest 5% speedup from the standard dynrec core. Probably not having directX is a significant bottleneck on video drawing, this can get fixed once I get a wrapper around directinput working. Hopefully these changes can also help out mamaich's x86 pe loader out a well.
-- old post below--
I managed to get dosbox compiled with mamaich's new updates (see below), so we now have dosbox with the dynamic recompiling core. I also included network support which seems to work.
The dynamic recompiling core does give better performance for newer apps. 3982 realtics vs 18088 realtics on doom timedemo, so about a 5x gain
The next step would be to get a better graphics core. There is an opengl wrapper for DX11 called gl2dx that I'm looking into.
I'm also looking at putting at optimizing dynrec for thumb2, for example, it seems that CBZ might be useful (except it only lets you branch forward!!!)
Hmm, I have to unfortunately note that DOS4GW doesn't seem to work in this build. I'm working on it!
In the mean time, enjoy commander keen 1 -6?...
no2chem said:
Hmm, I have to unfortunately note that DOS4GW doesn't seem to work in this build. I'm working on it!
In the mean time, enjoy commander keen 1 -6?...
Click to expand...
Click to collapse
So in the end, I think the dynamic recompiler has some issues.
I know that the VirtualAlloc function is correctly setting execute permissions on memory pages, but I don't know if FlushInstructionCache is actually flushing the instruction cache. It's also possible that the dynamic recompiler is emitting bad assembly, but inspecting the code... doesn't look like it!
no2chem said:
So in the end, I think the dynamic recompiler has some issues.
Click to expand...
Click to collapse
The same issue for me (but I'm using a bit obsolete DosBox sources, need to update). May be this is due to EABI changes (for example registers are not preserved), as DosBox dynamic core targets Linux.
Regarding DosBox. Look here - http://vogons.zetafleet.com/viewtopic.php?t=31787
This is the ARMv7 optimized dynamic core for DosBox by M-HT. It is not yet integrated into the official DosBox branch.
If you're concerned about FlushInstructionCache not being implemented correctly, let me know. As part of my work to port Chromium, I've learned how to do cache management in ARM a little closer to the metal (moving the relevant values to the coprocessor registers directly) and have both more control (for example, clearing the data cache lines as well) and more precise control over exactly what is done to the cache lines.
However, bear in mind that I haven't been able to properly test this yet, as too much of the Chromium core still doesn't want to compile for me... *sigh*.
GoodDayToDie said:
If you're concerned about FlushInstructionCache not being implemented correctly, let me know.
Click to expand...
Click to collapse
As far as I see - FlushInstructionCache works as expected (flushes icache). DosBox crashes due to some other reason, maybe due to the ARM-THUMB interworking problems (it is just a guess).
Good to know. It would be annoying if the official API were wrong...
I've found whu DosBox dynamic core crashes at random.
All existing dynamic cores use ARM code, even the thumb files are using the ARM prologue. Though our CPUs can run the ARM code, there is a bug (?) in RT that switches ARM code to be executed as a THUMB at random. For example you call an ARM procedure 100000 times, but at 100001 something happens and the code starts to execute as THUMB. Maybe a task switch occurs, or maybe some interrupt happens, and when OS returns to your code - it sets T bit in CPSR, so the code is interpreted as THUMB.
I was able to modify the prologue generator in risc_armv4le-thumb-iw.h so that it generates only THUMB code, and now everything started to work in my project. Attached. Code is ugly and unfinished and uses some dirty C hacks, I'll fix them later as it is deep night now. But you may look on the changes and implement similar things in a DosBox build.
mamaich said:
I've found whu DosBox dynamic core crashes at random.
All existing dynamic cores use ARM code, even the thumb files are using the ARM prologue. Though our CPUs can run the ARM code, there is a bug (?) in RT that switches ARM code to be executed as a THUMB at random. For example you call an ARM procedure 100000 times, but at 100001 something happens and the code starts to execute as THUMB. Maybe a task switch occurs, or maybe some interrupt happens, and when OS returns to your code - it sets T bit in CPSR, so the code is interpreted as THUMB.
I was able to modify the prologue generator in risc_armv4le-thumb-iw.h so that it generates only THUMB code, and now everything started to work in my project. Attached. Code is ugly and unfinished and uses some dirty C hacks, I'll fix them later as it is deep night now. But you may look on the changes and implement similar things in a DosBox build.
Click to expand...
Click to collapse
I'll take a look at getting that implemented in my build.
Edit: Haven't looked into it much, but DosBox crashes whenever I open any 32-bit stuff.
mamaich said:
I've found whu DosBox dynamic core crashes at random.
All existing dynamic cores use ARM code, even the thumb files are using the ARM prologue. Though our CPUs can run the ARM code, there is a bug (?) in RT that switches ARM code to be executed as a THUMB at random. For example you call an ARM procedure 100000 times, but at 100001 something happens and the code starts to execute as THUMB. Maybe a task switch occurs, or maybe some interrupt happens, and when OS returns to your code - it sets T bit in CPSR, so the code is interpreted as THUMB.
I was able to modify the prologue generator in risc_armv4le-thumb-iw.h so that it generates only THUMB code, and now everything started to work in my project. Attached. Code is ugly and unfinished and uses some dirty C hacks, I'll fix them later as it is deep night now. But you may look on the changes and implement similar things in a DosBox build.
Click to expand...
Click to collapse
thanks for figuring that out! its a bit odd though, don't you think - wouldn't normal ARM apps crash if this was the case? I'm sure most stuff is compiled with interworking, maybe ms interworking convention is different?
Anyway, I was thinking, doesn't homm3 use directx? Is your emulation layer also doing conversion of that code? It seems like it would be useful to have native wrappers for old versions of DX so they can take direct advantage of DX11 native. Alas, that's for another day.... Also, mfc would be nice too... (its there... MS just didn't provide the .lib, ordinals are [noname]'d out, and .pdb from debug server seems to be missing some exports....)
no2chem said:
hi all,
I managed to get dosbox compiled with mamaich's new updates (see below), so we now have dosbox with the dynamic recompiling core. I also included network support which seems to work.
The dynamic recompiling core does give better performance for newer apps.
The next step would be to get a better graphics core. There is an opengl wrapper for DX11 called gl2dx that I'm looking into.
I'm also looking at putting at optimizing dynrec for thumb2, for example, it seems that CBZ might be useful (except it only lets you branch forward!!!)
Click to expand...
Click to collapse
How big performance gains are you talking about?
bartekxyz said:
How big performance gains are you talking about?
Click to expand...
Click to collapse
Eh, 3982 realtics vs 18088 realtics on doom timedemo, so about a 5x gain
Nice! That should (eventually) allow quite a few legacy apps, if they're old enough and/or not to performance-sensitive (i.e. not realtime) to run acceptably.
no2chem said:
doesn't homm3 use directx? Is your emulation layer also doing conversion of that code?
Click to expand...
Click to collapse
No conversion, I just pass DX to the native OS libraries with some minimal wrappers. RT provides even DirectX 1.0 interfaces
The only problem is that RT prohibits non 32-bit color modes, though video driver supports them (at least 16 bit color is supported by tegra driver).
no2chem said:
I managed to get dosbox compiled with mamaich's new updates
Click to expand...
Click to collapse
I'm using ARM/Tumb dynamic code created by M-HT: http://vogons.zetafleet.com/viewtopic.php?t=31787
I've changed just one function.
I'm also looking at putting at optimizing dynrec for thumb2, for example, it seems that CBZ might be useful (except it only lets you branch forward!!!)
Click to expand...
Click to collapse
Please post your code changes somewhere, so that I could use them in my project too
don't you think - wouldn't normal ARM apps crash if this was the case? I'm sure most stuff is compiled with interworking, maybe ms interworking convention is different?
Click to expand...
Click to collapse
NTARM kernel is a THUM2-only kernel. There is no interworking it it. So it is possible that MS code intentionally sets the T bit to THUMB when returning from interrupt or a task-switch. Unfortunately this means that we can't use ARM code in our programs (I have not seen any ARM code in MS progs, only THUMB2). Anyway, THUMB2 code is very efficient now, its speed can be the same as of ARM code, and size is much smaller.
Generally, THUMB2 should outperform ARM, yes. Also, the state of Thumb vs. Arm is actually set in a kind of weird way: rather than manually setting a processor bit, it's controlled by the jump address. Since even THUMB2 instructions are always 16-bit (2-byte) aligned, the least significant bit of an instruction address is never 1. Therefore, that bit is used (on any jump-type instruction) as a flag to indicate whether the processor should use ARM or THUMB2 mode. In theory, this should mean that the OS doesn't care about the mode being used... but I've never written an interrupt handler for ARM (a couple other platforms, but not ARM) and there might be something weird going on with them.
GoodDayToDie said:
rather than manually setting a processor bit, it's controlled by the jump address
Click to expand...
Click to collapse
This is true for normal jumps. And that is why we have to set lowest bit to 1 manually on indirect branches inside autogenerated THUMB code. But for CPU itself the mode is kept in T bit in CPSR. And "something" sets it to 1 "sometimes". I have not done much testing, but I think that this should be an interrupt, as I've seen that bit changed in the middle of a generated ARM code.
Anyway the THUMB2 code is better then ARM for us - it is more compact, so more code may be kept in cache (both in CPU and DosBox dynamic recompilator's).
updated with a thumb2 dynrec.
Touch input for mouse
For anyone that wants to use their touchscreen for mouse input, navigate to their %AppData%\Local\DosBox folder and modify the dosbox-0.74.conf file so that "Autolock=true" is "Autolock=false"
It works pretty well with the touchscreen and an on-screen keyboard for gaming and such

Wayland server for Android

ABANDONED
Hi! Does anyone here use Linux desktop distributions in chroot environment on Android device?
I am developing wayland protocol server for Android devices. If anyone is interested in checking my project, latest version of apk is always available here:
ftp://ftp.drivehq.com/mogryph/sparkle/
Currently I am only focused on running Xwayland as client. Also apk supports audio output.
Simplest instruction:
1. Android 6 or newer required, busybox required, root required
2. Prepare linux distribution in directory, image or on partition. Make sure you have Xwayland installed in it. Make sure you specify which DE to run (or at least xterm) in ~/.xinitrc
3. Install and start sparkle.apk
4. Press "edit user.sh", uncomment (remove #) line starting with start_generic_container. Change rest of this line to match your device:
first arg - image or partition where distribution is installed. If distribution is installed in directory and mouting is not needed, leave this arg unchanged.
second arg - mount point or directory with distribution. If you use mounting (first arg), this arg can be left unchanged.
third arg - name of the user which will be used to start Xwayland and DE. Its better to specify non-root. Also this is the user who must have .xinitrc in his home dir (see step 2).
5. Save user.sh and click "Start".
6. Any problems and crashes will be reflected in the log.
If you want audio output:
1. Compile and install driver from pcm_sparkle.tar.gz in your distribtion
2. cp 1.asoundrc ~/.asoundrc
If you have blinking problem, change upload_mode from 1 to 2 in settings. If you have bad performance, setting no_damage to true may help, but in most cases no_damage=false is better. Fastest upload mode is 0 (if it works).
If you don't trust me and don't want to give sparkle root permissions (I perfectly understand this) you don't have to. Also you can do without busybox.
But in this case, you need to understand and do a lot of things. Check sparkle's user.sh to get idea about what needs to be done. Basically:
1. You need to make /data/data/com.sion.sparkle/files accessible from inside chroot container. You can use bind bound.
2. Make sure you have tmpfs mounted over /tmp in container.
3. You may need to change selinux context on /tmp to match sparkle's context or disable SELinux.
4. You need to create new directory in /tmp, symlink sparkle's wayland socket from /data/data/com.sion.sparkle/files/wayland-0 to this dir. And export XDG_RUNTIME_DIR to point to this dir. Dir must be (ch)owned by user who will be running Xwayland and DE.
5. After all this, you can try to start Xwayland and your DE.
new version
New version
rgho.st/8Fbz64Rxj
Added x86 and x86_64 support. Actually it is rewritten almost from scratch but x86 support is the only thing others can notice...
Hello! This project is interesting. I tried you app and it works on my Xiaomi Redmi Note 4X(chromium and glmark from chrooted environment works very well)! Can you publish source code on Github, because it really interesting project?
Also I'm interested, please post it on github!
Did you put this up on github or move this thread? Looks very interesting.
1
Argh, sorry, I decided to abandon this project. You are free to delete thread. Also no copyleft-licensed components were used so I don't have to bother releasing sources.
Hentacler said:
Argh, sorry, I decided to abandon this project. You are free to delete thread. Also no copyleft-licensed components were used so I don't have to bother releasing sources.
Click to expand...
Click to collapse
Check your PM please!
1
Hello again.
For last two weeks I was rewriting it from scratch (yes. again... yes, third time).
Probably need another week to make it stable.
Currently I am not sure it runs on any device except my own 5-year old phone (LineageOS 14).
I will maintain last version here:
ftp://ftp.drivehq.com/mogryph/sparkle/
There is no English documentation, but you can see script "user.sh" to get idea about how to start xwayland. In most cases it should be enough to edit few lines in that script to make it work on another device. If you execute this script on your device with "install" argument, it is supposed to place itself into sparkle's directory and sparkle is supposed to run it ("start" function) automatically. Sparkle doesn't request root unless script does.
Here is video of sparkle working:
https://www.youtube.com/watch?v=tOSFYxCF7Q8
But it seems that KDE + video recording was too much for my old phone
Still, if you going to see video, don't close it until 2:00 where I turned of composition which caused lags.
Also on device everything looks much smoother than on video, even after 2:00.
When I watch fullscreen (1280x720) video on my device, sparkle + xwayland together add just 5% of CPU load (20% load of single core).
Thats it I guess... I tried to to discuss sparkle on 4pda.ru (russian forums), but got very bad reception. "xsdl is perfect, dont reinvent the wheel" they say. So I started to hate humanity and I decided to make sparkle personal project. Also this is last time I am solving reCAPTCHA to leave post on XDA.
Still alive
We are still alive. I've changed first post to reflect actual state. Now sparkle supports audio, auto-mouting containers and is lot more stable.
Yet there are still many things I want to improve in sparkle's core before adding new functions.
Also there are few demo videos on ftp.
Amazing!
Working great on my redmi 6 pro. Stock miui 9.9.3 rom. With linuxdeploy and sparkle from your ftp. No lag on visual and sound. My Linux distribution is alpinelinux arm64 arch.
Since first time I see your posting on 4pda. I'm interested in it. And finally it's on xda.
Thanks dev.
---------- Post added at 02:52 AM ---------- Previous post was at 02:44 AM ----------
For anyone interested in the topic. Please follow the instructions in documentation from ftp. And Translate it to eng from rus.
This sounds amazing! Just curious, is it related to https://github.com/twaik/sparkle ?
I now have it working very well on my Samsung Tab S3 using Xwayland and a tiling window manager. Firefox runs amazingly well!
Is it meant to be used only with Xwayland or will it also work with native Wayland applications?
BTW, I think if you open sourced this project and promoted it a bit, it could become quite popular. It's basically the first way to run X11 GUI applications on Android devices at full speed. If you set up a donation link, you could also get compensated for your time and effort. I'll personally contribute $20 if it's open sourced, and I'm sure others will chip in as well.
robsmith11 said:
This sounds amazing! Just curious, is it related to https://github.com/twaik/sparkle ?
Click to expand...
Click to collapse
Thanks for feedback. Nice to hear that someone managed to start this thing
Twaik's repository is clone of my very very old version of sparkle. I made that version years ago when I was just starting to learn linux and C++. Sparkle was rewritten from scratch two or three times since that version. And (I believe) current version is much better.
Regarding making it open source... Few months ago I had to find real job. Can't spend much time on personal projects any more. But I have my own strange programming style and my own vision of what sparkle should be. Not sure I want others to paint on my picture. It's probably all because of Twaik! I hate how he used old open source version of sparkle. He did terrible things to it, outraging all my beliefs Sorry!
P.S.: Yesterday I've uploaded another apk to my ftp. The file is called "sparkle-testing.apk". This version is much newer and has many fixes. But I've also changed to many things since tested version including some fundamental changes. No guarantee it will run at all on other devices. Interest is mega low and I get no test reports at all.
Hi Hentacler, I've just found your project - it looks really promising. Unfortunately, the only link currently working on this thread is to github. Is this project still live?
I have a samsung galaxy note 10+, and am using it as a laptop replacement. In addition to the android apps using Samsung Dex (Samsung's desktop solution), I have several linux distributions installed inside a chroot using userLand - so far, its working great. I'd be keen to give you project a try if it's still live, and am happy to help out with testing from my device.
Re open source - while I like your project, I'm not super interested in investing time into something that's not open sourced - I appreciate your concerns about wanting to maintain the direction, but having transparent development is pretty important to me. Is Twaik's fork of your project a better place to go?
Cheers.
tillum said:
Hi Hentacler, I've just found your project - it looks really promising. Unfortunately, the only link currently working on this thread is to github. Is this project still live?
I have a samsung galaxy note 10+, and am using it as a laptop replacement. In addition to the android apps using Samsung Dex (Samsung's desktop solution), I have several linux distributions installed inside a chroot using userLand - so far, its working great. I'd be keen to give you project a try if it's still live, and am happy to help out with testing from my device.
Re open source - while I like your project, I'm not super interested in investing time into something that's not open sourced - I appreciate your concerns about wanting to maintain the direction, but having transparent development is pretty important to me. Is Twaik's fork of your project a better place to go?
Cheers.
Click to expand...
Click to collapse
ftp://ftp.drivehq.com/mogryph/sparkle/
Link to FTP should work and there you can get two versions:
sparkle.apk - old version, but confirmed to work by 3-4 people.
sparkle-testing.apk - latest version, but only briefly tested by me.
I don't ask anyone to invest anything... Sparkle doesn't request root access or any other dangerous permissions (unless you enable automatic container mounting and starting) so it's safe to try for anyone who wants.
Btw, somewhere between these two versions I've replaced BASH container initialization script with LUA version. That was probably a bad idea. LUA script is harder to start directly as root and hacks I used may not work (currently may even cause application freeze if root access is denied). Going to revert to BASH probably. But this only touches people who want sparkle to mount container and launch everything automatically on single button press.
p.s.: Why I need to solve captcha every time I post something?
Thanks for the new release! I've updated and everything seems to be working without any changes on my Samsung Tab S3 with chroot and Arch Arm Linux.
Your changes also solved the flickering for me! The old version would flicker the screen whenever my keyboard's trackpoint activated, but it's not flickering at all any more. Performance seems to be about the same.
I think this could be quite popular, but not many people know about it. Perhaps a post on Hacker News or Reddit would raise awareness.
I understand your position on open source and maintaining control. One idea if you haven't already considered it is releasing the code with a restrictive license that forbids any forks. But either way, I'm enjoying being to properly use X11 on my tablet.
BTW, have you tried any native Wayland compositors? I don't really understand the Wayland ecosystem that well. I gave Sway a brief try, but it didn't seem to work. I've only been using XWayland.
@Hentacler Thanks for your reply! Very keen to get this working, but having a few issues. I'm unsure how to configure the user.lua file - I'm using your latest apk.
I have a non-rooted device, and am running archlinux under termux. Works fine with xsdl. I have installed xorg-server-wayland for X11. I'd appreciate any advice you have.
@robsmith11 Are you able to share how you got this working on Arch? Thanks!!!!
tillum said:
@Hentacler Thanks for your reply! Very keen to get this working, but having a few issues. I'm unsure how to configure the user.lua file - I'm using your latest apk.
I have a non-rooted device, and am running archlinux under termux. Works fine with xsdl. I have installed xorg-server-wayland for X11. I'd appreciate any advice you have.
@robsmith11 Are you able to share how you got this working on Arch? Thanks!!!!
Click to expand...
Click to collapse
I am not sure it is possible to use sparkle without root...
Sparkle makes it's directory accessible for everyone (chmod 777). Before Android 8 or 9 this was enough and xwayland from termux was able to connect to sparkle. Here is how people used to start it:
export XDG_RUNTIME_DIR=/data/data/com.sion.sparkle/files
Xwayland
But newer versions of Android brought more restrictions and termux can no longer connect to sparkle. These new restrictions are implemented using SELinux if you know what it is. Applications now have different security contexts.
But that is not all. Newest versions of android brought even more terrible meaningless restrictions effectively "killing" applications like termux and many others.
In short, from now one applications are not allowed to execute code (binary) that comes from "untrusted" sources. Termux used to download a lot of such code from it's own repositories. And now it can't. We can't even unpack binaries from assets.
So I can only help with rooted devices.
P.S. Please forgive me, but I am leaving this website. Making people solve recaptcha every time they want to post something is unacceptable level of contempt.
My mail: [email protected]
Thanks for that, will have a play. I could always just root my device. Weird about recaptcha, not having this issue. Currently through termux I have access to the whole sdcard, and am able to download packages (and distros) in it - will have a play and see what else is possible.
@tillum
I basically just followed the instructions on the first post for using Sparkle without busybox. I didn't need to modify the Lua scripts.
I'm guessing SELinux may be a problem without root. I'll try setting it up without root when I have a chance later.

Categories

Resources