I'm re-packaging my web service api library from Android to cross-platform,
I notice that I've used a lot of AsyncTask ... I wonder how do I dodge using this Android-specific method by
replacing with something more common, and would run perfectly in Android as well.
Related
Hi, I've been looking at running GNU Linux apps on a rooted android. device with modern hardware and I've yet to find a 'nice' way to run x apps with acceptable GUI performance. Currently I've tried the java implemention of x on android which is barely useable and various vnc - rpc intergrations running x11 using a virtual frame buffer which is much better but laggy.
My idea to solve this problem is to completely do away with the vnc etc.. proxying. that 8s hack the virtual frame buffer version of xorg so that the main pixel map surface is in ipc shared memory and use ipc to render this through the android api.
So is it possible to statically link the needed android libraries to allow abdroids ipc to work between a hacked xorg vfb and abdroids shared memory ipc to a native android app. Thus making high performance rendering with near zero memory coppies possible.
Secondly, and this would be a bonus, could I even get rid of ipc and a native android app by getting xorg on my root GNU Linux install to work directly with android graphics and UI apis. This would be ammazing.
Hopefully ipc is at a kernel level so it may be possible to just port the needed parts of android to GNU Linux to do this if the statically linking method is known not to work.
Any ideas and suggestions, what do you think of this idea for intergraring GNU Linux x apps and android.
I really like this idea and I've been looking for something like this. You said you used the "X server" android app? I'm kind of curious on the performance. Was it laggy or just that it wasn't fully what you expected?
jthree2001 said:
I really like this idea and I've been looking for something like this. You said you used the "X server" android app? I'm kind of curious on the performance. Was it laggy or just that it wasn't fully what you expected?
Click to expand...
Click to collapse
Currently I'm running xrdp and tightvncserver in a gnu/linux environment (using inode linking not chroot) and xfe as the windows manager.
I connect to this from android using a rdp client.
The main issues appear to be very slow performance on graphics updates, visably slow, which I put down to the overheards of running everything through vnc/rdp - over sockets - mem coppies, compression (which I should turn off to see if it helps) encryption and all that stuff that goes along with rdp and vnc that's not needed if you use something like shared memory and blit to that.
Performanc of the apps in xfe &co, for instance libraoffice or eclipse etc.... seems to be pretty good, so that's not the issue, just the graphics.
Running a Asus transformer infinity T700
my current messing arpund has been trying to get the Android NDK to compile and run on ARM, which in theory should be no problem so long as it doesn't rely on x86 machine code to do the job (which I doubt).
idky google locked down the architecture in the builds and didn't just leae it as any old gnu/linux or whatever and let the person making the build tweek any bugs, instead of having to hack googles custom build system for building the toold chain to for a specific architecture.
floowing some rough profiling
jthree2001 said:
I really like this idea and I've been looking for something like this. You said you used the "X server" android app? I'm kind of curious on the performance. Was it laggy or just that it wasn't fully what you expected?
Click to expand...
Click to collapse
Ok, I did some crude profiling using the setup
tightvncserver
xrdp
and xrdp client on android.
the major bottle neck was the rdp client on android which made my testing cpu limited since it was maxing out cpu usage. I beleive this may be due to a bug in Android on my tablet relating to non opengl es graphics..
anyhow I got some more usefull data
xrdp was typically sitting at around 40% cpu and all it's doing is taking data from tightvnc and shunting it over rdp to the client.
next on the list was the vncserver using typically less than 30% cpu.
I think this shows there is clearly a lot of overhead (based on the 40% cpu xrdp was using) of using a remote desktop protocol over sockets that should be easy to mitigate by using shared memory.
I also tried a different setup
tightvncserver
and a vnc client on android
taking rdp out of the loop
again the android client made the tests cpu limited but perforance was much better.
This VNC client is open source, so my next step is to create an opensource project and modify the VNC client so that the user input is up to scratch and look at using opengl for graphics (assuming that's where the bottle neck is) so that it's not longer cpu limited.
Once that is done (which should also failarize me with the VNC protocol and the client code).. I can look at replacing the graphics part of VNC with a shared memory buffer, but keeping the user IO over the existing VNC protocol as that makes sense...unless that also becomes a major issue.
That also leaves me some way of sending additional data back and forth without having to do it 'all' via shared memory which would be much more of a mission
in theory there shouldn't be any need for any kind of complicated mutexing between the android client and the x server sine the x server will be all but write only and the android client always read only.
on a side note,
running java linpack on android I get about 50mflops per cpu
with disk io I get about 1gig per second cached reads.
so some crude math would give me 250mega words
my screen is 1920 by 1080 (well actually 1200), but we'll call that 2k by 1k, or 2 mega words.
so a theoretical performance into the high tens of fps seems quite achievable, which is much bettern that the 5 or so tops that I'm getting atm by an order of magnitute.
having a quick poke around, mostly related to my xorg wows (that is it complaints about no tty device when starting up. it seems that it's not too difficult to get xorg running using a frame buffer driver after a few android services have been stopped. So i'm not sure if this is still needed or not.. IPC betwen gnu and android is still an interesting project.
So anyhow, I'm going to try and get xorg running properly, there are even tegra 3 drivers for xorg too, so in theory the performance should be substantially better than anything an ipc hack would be able to achieve.
I was struggling not to make that kind of posts but as far I can see, I definitely need help in order to proceed.
I need help with hacking an app. The application in question utilizes AES encryption for some subset of web requests. As I understand, the key for encryption is generated by the app at native code level which then used for encrypting/decrypting internet traffic, using shared library. In addition to that, there is a method to fetch the encryption key, if my understanding of the process is correct.
Personally, I don't follow the whole sequence of actions it does to encode/decode data (app heavily utilizes both java, native arm code and server-obfuscated JS code so it'd a bit complicated to follow). So, I thought that it might be faster and more effective to go straight for the key, so the plan was writing xposed module which would fetch it.
I haven't developed for Android platform before so please bear with my ignorance. As I understand, if the method in shared library is called Java_<class>_<method> then it can be declared in that class and be called from there. If the library is checked using IDA Pro, you could see a bunch of method following that naming approach in Exports tab. The problem is that the key fetching method uses different naming/declaration - <ClassA>::<ClassB>::<Method> (and its export name is something like _ZN3ClassA6ClassB9MethodEv). While I have a vague idea of calling typical native class methods (Java_.... ones), I don't have a slightest idea if <Class1>::<Class2>::<method> could be called from Java code somehow.
Any help would be appreciated.
I have a to chose between those Database :SQLite, Realm or Redux
witch one is the best for regular db update ?
Hi smauh117, this is my opinion:
Persistence - why Realm, not Room (SQLite)?
Room Persistence Library is a part of google's android acrhitecture components announced Google IO 2017. It provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite, works well with LiveData.
But, SQLite is not simple, and relational database is not easy for a lot of android developers. In almost android application, local database is offen used for data caching only, and isn't center of bussiness processes.
Realm is a mobile database, a replacement of SQLite and ORMs. It is much more simple than SQLite, but really powerfull, easy to learn in minutes, not hours, for every mobile deveopers, both Android and iOS. Even "Realm Database is much faster than an ORM, and often faster than raw SQLite". With lazy data loading, your app can easy to archive better performance and user experience, it's really difficult if you are using Room.
Room works well with LiveData and lifecycle aware to prevent memory leaks, how about Realm ?
It dosen't matter, Realm can easy to adapt with LiveData, read more: Android Architecture Components and Realm.
For full article and source code, please visit my project here.
I also created this project to compare Realm and SQLite (with ROOM). Please checkout different branches.
Thank you
:good::good:
smaug117 said:
I have a to chose between those Database :SQLite, Realm or Redux
witch one is the best for regular db update ?
Click to expand...
Click to collapse
AFAIK: Redux is an architectural pattern and not a database like Realm and what do you mean by "regular db update" ?
Anyway, Google's Room is a pretty good and established abstraction layer over SQLite on Android. I don't recommend Realm because there're a couple of pitfalls regarding multithreading. If you don't want to use SQLite + Room check out Objectbox.
smaug117 said:
I have a to chose between those Database :SQLite, Realm or Redux
witch one is the best for regular db update ?
Click to expand...
Click to collapse
SQLIte/Room may not be the best option depending upon what you actually mean by regular db update.
That is SQLite and therefore Room (Room being an abstraction layer over SQLite) is intended as an embedded database and thus each device has it's own distinct database and synchronisation with external data would have to be coded/developed, just pulling data from one source wouldn't be overly difficult. However, two/multiple way/device synchronisation would introduce complexities and hence why many solutions use other databases that are intended as a client server solution (e.g. MYSQL for example).
Firebase, not that I've used it, could be a solution as this is a client/server solution and is designed for Android use.
Personally I find native SQLite easier and therefore faster to use than Room. I've never used Realm.
it depends on your data architecture, if you'd like to use a non relational database just go with Realm, it's like mongo for mobile apps, otherwise there is Room, which represent the relational database by using Sqlite.
@MJT said:
SQLIte/Room may not be the best option depending upon what you actually mean by regular db update.
Personally I find native SQLite easier and therefore faster to use than Room. I've never used Realm.
Click to expand...
Click to collapse
I completely agree. I use SQLite to save user preferences in the application. It is simple and stable.
And this is a cross-platform solution (not only for android).
Hi there. I have created a few apps using the android version of the processing IDE. I was amazed at how easily i could create applications for my device compared to using the official IDE which was far too complicated for an amateur like myself. I have now reached a point however, where the limitations of the processing IDE are showing themselves, it was developed as a means to create visual 'sketches' after all and not for creating complex applications.The main problem i have is in the organisation of my code which becomes harder and harder as the application gets bigger. Which brings me to my question; are there any android programming environments which are more 'app oriented' but still provide that layer of abstraction which hides all the unnecessary baggage of straight up android app development? would be great if there was some GUI features too. does this exist or would i be better off sticking with processing?many thanks.
Hi there. Is there anyone who knows how their graphics stack is implemented?
It looks like they use host graphics stack, but I've seen ROM's internal structure - it uses it's own gralloc. I know they do not use AHardwareBuffer because it appeared only in Android 8, not Android 5 (their minimal Android target). I know they do not use gralloc from host machine because vendors modify it's ABI and it any app using it will crash. And modern Android linker prevents it from being dlsym'ed (it is in grey-list).
How are they doing it? gl-streaming? android-emugl? Anything else?
My goal is simple - create native buffers and native windows and share them between processes without using Android private API's or use them without need to recompile for target platforms.
Please, help me.