I used to install OS Monitor (https://play.google.com/store/apps/details?id=com.eolwral.osmonitor) on my Android devices.
It's a nice utility, very poweful yet not intrusive.
In particular, I like the realtime monitoring of CPU, RAM and battery temp.
Unfortunately, OS Monitor won't support Android 7.0 and following version due to securtiy constrain.
I searched for alternatives but without much success. The real-time monitors I found on Google Play offer widget but no integration with the status-bar.
Do you have any advice for a possible substitute?
Thanks.
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 know some people will not like what i'm going to write here, So should user's use ART runtime? No! .
First let's talk about Google-in-Go (Go), Go is the language from Google and Android is the mobile OS from Google. So far there is no Android SDK for Go, and Go doesn't support JNI so switch to ART sound a good idea since ART can compile to two banckends "Quick" and "Portable" "JIT and LLVM".
If it's LLVM, that pretty much opens the door for running Native Client apps on Android, and possibly even merging Android with ChromeOS, right?
Go 2.0 can handles 64-bit much better than 32-bit and 64-bit applications is Google next target. Porting Android's Dalvik to 64-bit would be like converting a subcompact econobox into an all terrain SUV. It would make far more sense to throw it away and start from scratch, where scratch is, for Google, ART + Go
Why Go?
Go is fast, Go launguage is bundled with high quality libraries, Go is from Google!
.
Now, FlexyCore. Flexycore's most prominent product is "droidbooster," /generating heavily optimized ARM binaries/ an app that will make your Android device run 10x faster and increase battery life... sound familiar? "ART"
FlexyCore was development outside the public eye, And now Google acquisition the company for $23.1 million!, Google statement was: The FlexyCore team has strong expertise in building software to optimize Android device performance, and we think they’d be a great fit with our team.
Let's talk again why not to use ART now?
Android is implemented in Java. Pretty much all of Google Play Services is implemented in Java.
That means android can rely less on the fact that graphics and guts of many UI widgets are native code under a thin layer of Java. Android was always a Java OS. So you will not find any different if you switch to ART unless you are doing significant computation in your own app, a synthetic benchmark will vastly over-emphasize the impact of a better JIT. ART is there only so Google can obtain early feedback from developer's and partner's.
Sources:
(ycombinator - arstechnica - paradigmx - Android)
I recently moved to a BLU Studio energy and I am enjoying it very much. I use limited apps/services on my phone and want to know what would be the best launcher, settings and/or apps to utilize to limit RAM usage. I want to know if using the stock apps, (browser, messaging, music, etc...) will help utilize the RAM better or if I need a different launcher or both.
The phone has 1gb and consistently runs at 80% of max. I have not received a warning, however, I would like to be proactive in preparation. The phone is a quad core Mediatek running 4.4.2 on a seemingly thin BLU skin. I run one home page, no widgets and have shut off all animations. I would like to see the phone running with what I need around 60-70% of max. I currently use mostly google applications and have listed the extras below that I must have. I am open to all suggestions, even changing apps to more ram friendly types and will provide whatever information about the phone as I know it is a new model and there is not a lot of info here as of yet. I also am aware that there is a way to add RAM from an SD card, but, there is no guide to rooting listed here on site so it is not a viable option as of yet.
Apps on Phone beyond stock:
Amazon
Keep
Feedly
Gamestop
Last.fm
Keepsafe
Shuttle
Wallet
Rigdata
I truly appreciate any help or respectful opinions that can be offered.
try nova launcher
experiment and see which runs the best for your phone each is different
Sorry if this isn't the best section to be asking in, it's a big forum out there with so many boards.
I'm trying to run many instances of a certain Android app concurrently. I need either Google Play services to be available for a one-time sign in on each instance, or preferably a way to import app data to remove the need for Google Play or any other components of the Android environment besides the basic runtime needed to run the app.
I'm currently using an Android emulator (Nox) running on 640x360 at 20 fps, which is able to get me about 14 instances running on my local Windows. machine before things start crashing. The limiting factors seem to be the frequency of snapshots taken by the VMs and running low on RAM, which in turn increases CPU usage for defragmentation and page file management.
Is there any more efficient way to accomplish this task? Perhaps an x86 Android runtime with settings to reduce graphics quality? I've also looked at the Genymotion AMI on AWS but all of Amazon's VM options seem too powerful (and costly) to run my app on so many machines.
Thanks!
I’m building an app to monitoring the android device in Kotlin.
I’ve looked in 3 obstacles:
1 - The difference between android under and post 7.0.0 on foreground services
2 - Chinese ROMs, with an agressive kill of apps when user do a simple clean on last apps
3 - which android tool can I use for resolve it.
I’ve seen until now: AlarmManager, permanent notifications, accessibility service… Broadcast receiver to up application when system restart and battery optimization, but all my tries didn’t seem to help me in solving.
For example, the follow tutorial doesn’t work after I clean the lastest apps used in a Chinese ROM (Xiaomi): robertohuertas.com/2019/06/29/android_foreground_services
Showing permanent notification is the only way according to android docs. But chinese rom use there own task management to save battery which even closes permanent notification, If user manual cleans app from resent task. Currently i am ignoring those devices/ limited support. I am looking for better solution.