Related
I'm a heavy AIM user, among other things on Android. For me, AIM always closes when I minimize it, so I tried alternative apps, like the application Hi AIM, which I personally like a lot too. The good thing about Hi AIM is that it has a constant icon in the notification bar showing that it is active therefore I know whether or not I'm signed in or not/if the app has been dropped from memory. I ran several tests IMing myself from my computer with the app open, it works fine even if i minimize it and navigate around my phone. However, if I open up the browser and start loading a website, the icon disappears, and all subsequent messages sent are dropped. This is a large problem for me and therefore the only solution I can think of is locking the application into memory. According to Advanced Task Manager [which I do not leave on, I only use it to check memory], with my phone on standby I usually have around 19-28MB of free memory. I have the 10MB ram hack, as well as CompCache and 32MB swap. I am running the latest Super D with Dark Star theme. The browser obviously has a large memory load and is causing the AIM app to be dropped in favor of running the browser quickly, is there anyway I can lock the AIM app into memory? I understand there will be a minor general slowdown of the phone overall as a part of the memory is now purely dedicated to that single app, but AIM is something I use a lot.
Yes.
I'ts pretty much this thread: http://forum.xda-developers.com/showthread.php?t=652147
Their solution is to "download the AutoKiller app" and press "keep alive"
hope this helps
You just made my day. Thank you very much haha
Advanced Task Manager also works for what you require.
Been using it for awhile now and am satisfied enough to not use another app for such purposes.
I don't know what/how to change this, but this is the code you need to make the sense home app stay in memory. Perhaps its similar to the way you make any other app stay in memory?
Code:
adb pull /init.rc
replace "setprop ro.HOME_APP_MEM ..." with:
setprop ro.HOME_APP_MEM 1536
adb push init.rc /sdcard/init.rc
adb shell
# mount -o remount,ro rootfs /
# cat /sdcard/init.rc | tee /init.rc
# mount -o remount,rw rootfs /
# rm /sdcard/init.rc
This is now android works. The way I see this, this is very much similar to "pre-fetch" concept in windows 7.
I have a 6 GB RAM laptop. Base OS uses less than 1.5 GB of RAM. But like an hour or so when I see my RAM usage, its to the tune of 3-4 GB. What I have noticed is that my most frequently/recently used apps are loaded to RAM and kept there idle. Some amount of RAM is always kept free instead of using up all RAM. This way apps start faster. When I load a different memory heavy program, it pushes the existing one out and loads this.
More or less the same in android too. When u go to any task manager app n see the running apps, u'll notice that many of the apps loaded are the ones u use frequently.
These apps do NOT use any CPU. They are just loaded to memory and kept there for quick access.
When I boot up my phone I have like 190+ MB free RAM. Though left in standy mode, within an hour, I see my free RAM fall to 80-120 MB range. I never saw it go less than 80 MB. And the apps in memory are the ones I used the last time, and the ones I use all the time.
Even if u use a task killer to kill these "inactive" apps at intervals, they would be loaded again sooner or later. That's the principle of android. So by using task killers, though u feel u r freeing up memory, in fact, u r only draining ur battery. What's the use of memory if u r not using it effectively.
Don't worry abt free RAM amount. Let android manage it. Systems are intelligent enough these days.
Hope this helps. Below is more about the same in detail.
Android Memory Management
Android is a Linux based OS with 2.6.x kernel, stripped down to handle most tasks pretty well. It uses native open source C libraries that have powered Linux machines for years. All the basic OS operations like I/O, memory management, and so on, are handled by the native stripped-down Linux kernel.
How to use memory for each application
Android’s process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.
Each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management to the Android run time, which stops and kills processes as necessary to manage resources.
Dalvik and the Android run time sit on top of a Linux kernel that handles low-level hardware interaction including drivers and memory management, while a set of APIs provides access to all of the under- lying services, features, and hardware.
Dalvik Virtual Machine Dalvik is a register-based virtual machine that’s been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.
The Dalvik Virtual Machine
One of the key elements of Android is the Dalvik virtual machine. Rather than use a traditional Java virtual machine (VM) such as Java ME (Java Mobile Edition), Android uses its own custom VM designed to ensure that multiple instances run efficiently on a single device.
The Dalvik VM uses the device’s underlying Linux kernel to handle low-level functionality including security, threading, and process and memory management.
All Android hardware and system service access is managed using Dalvik as a middle tier. By using a VM to host application execution, developers have an abstraction layer that ensures they never have to worry about a particular hardware implementation.
The Dalvik VM executes Dalvik executable files, a format optimized to ensure minimal memory foot- print. The .dex executables are created by transforming Java language compiled classes using the tools supplied within the SDK.
Understanding Application Priority and Process States
The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s priority is equal to its highest-priority component.
Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports.
All Android applications will remain running and in memory until the system needs its resources for other applications.
It’s important to structure your application correctly to ensure that its priority is appropriate for the work it’s doing. If you don’t, your application could be killed while it’s in the middle of something important.
The following list details each of the application states shown in Figure (see the attached image) explaining how the state is determined by the application components comprising it:
Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.
Active processes include:
* Activities in an “active” state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter.
* Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
* Services that are executing an onStart, onCreate, or onDestroy event handler.
Visible Processes Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.
Started Service Processes Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.
Background Processes Processes hosting Activities that aren’t visible and that don’t have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat- tern to obtain resources for foreground processes.
Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when they’re re-launched. These processes are rou- tinely killed as required.
How to use memory efficiently
Android manages opened applications which are running in the background, so officially you shouldn’t care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness’ in everyday performance. We can use advanced task killer/task manager and it does its job very well.
Source:
Code:
http://mobworld.wordpress.com/2010/07/05/memory-management-in-android/
NICE!!
diablo009 said:
This is now android works. The way I see this, this is very much similar to "pre-fetch" concept in windows 7.
I have a 6 GB RAM laptop. Base OS uses less than 1.5 GB of RAM. But like an hour or so when I see my RAM usage, its to the tune of 3-4 GB. What I have noticed is that my most frequently/recently used apps are loaded to RAM and kept there idle. Some amount of RAM is always kept free instead of using up all RAM. This way apps start faster. When I load a different memory heavy program, it pushes the existing one out and loads this.
More or less the same in android too. When u go to any task manager app n see the running apps, u'll notice that many of the apps loaded are the ones u use frequently.
These apps do NOT use any CPU. They are just loaded to memory and kept there for quick access.
When I boot up my phone I have like 190+ MB free RAM. Though left in standy mode, within an hour, I see my free RAM fall to 80-120 MB range. I never saw it go less than 80 MB. And the apps in memory are the ones I used the last time, and the ones I use all the time.
Even if u use a task killer to kill these "inactive" apps at intervals, they would be loaded again sooner or later. That's the principle of android. So by using task killers, though u feel u r freeing up memory, in fact, u r only draining ur battery. What's the use of memory if u r not using it effectively.
Don't worry abt free RAM amount. Let android manage it. Systems are intelligent enough these days.
Hope this helps. Below is more about the same in detail.
Android Memory Management
Android is a Linux based OS with 2.6.x kernel, stripped down to handle most tasks pretty well. It uses native open source C libraries that have powered Linux machines for years. All the basic OS operations like I/O, memory management, and so on, are handled by the native stripped-down Linux kernel.
How to use memory for each application
Android’s process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.
Each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management to the Android run time, which stops and kills processes as necessary to manage resources.
Dalvik and the Android run time sit on top of a Linux kernel that handles low-level hardware interaction including drivers and memory management, while a set of APIs provides access to all of the under- lying services, features, and hardware.
Dalvik Virtual Machine Dalvik is a register-based virtual machine that’s been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.
The Dalvik Virtual Machine
One of the key elements of Android is the Dalvik virtual machine. Rather than use a traditional Java virtual machine (VM) such as Java ME (Java Mobile Edition), Android uses its own custom VM designed to ensure that multiple instances run efficiently on a single device.
The Dalvik VM uses the device’s underlying Linux kernel to handle low-level functionality including security, threading, and process and memory management.
All Android hardware and system service access is managed using Dalvik as a middle tier. By using a VM to host application execution, developers have an abstraction layer that ensures they never have to worry about a particular hardware implementation.
The Dalvik VM executes Dalvik executable files, a format optimized to ensure minimal memory foot- print. The .dex executables are created by transforming Java language compiled classes using the tools supplied within the SDK.
Understanding Application Priority and Process States
The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s priority is equal to its highest-priority component.
Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports.
All Android applications will remain running and in memory until the system needs its resources for other applications.
It’s important to structure your application correctly to ensure that its priority is appropriate for the work it’s doing. If you don’t, your application could be killed while it’s in the middle of something important.
The following list details each of the application states shown in Figure (see the attached image) explaining how the state is determined by the application components comprising it:
Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.
Active processes include:
* Activities in an “active” state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter.
* Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
* Services that are executing an onStart, onCreate, or onDestroy event handler.
Visible Processes Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.
Started Service Processes Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.
Background Processes Processes hosting Activities that aren’t visible and that don’t have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat- tern to obtain resources for foreground processes.
Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when they’re re-launched. These processes are rou- tinely killed as required.
How to use memory efficiently
Android manages opened applications which are running in the background, so officially you shouldn’t care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness’ in everyday performance. We can use advanced task killer/task manager and it does its job very well.
Source:
Code:
http://mobworld.wordpress.com/2010/07/05/memory-management-in-android/
Click to expand...
Click to collapse
Sweet!! Good Info.. But wrong Section. You should port this in the General Section to help all!
rickysa2000 said:
Sweet!! Good Info.. But wrong Section. You should port this in the General Section to help all!
Click to expand...
Click to collapse
Oh. I thought this belongs to Q&A.
Any mods here who can move this to "General" please.
This would be why when you open the built in task manager nothing or only your launcher shows up but when you open ATK multiple other programs are shown open, correct?
I found similar information while researching battery saver programs. I keep ATK when I have stubborn apps that are stuck because it is easier to get through than Android Task Manager but the auto-kill feature is always disabled. Good coverage of this info.
bclark said:
This would be why when you open the built in task manager nothing or only your launcher shows up but when you open ATK multiple other programs are shown open, correct?
Click to expand...
Click to collapse
Exactly! If all programs/processes show up, like they do in ATK, it could cause instabilities in the system when the user kills any important process knowingly/unknowingly.
trekie86 said:
I found similar information while researching battery saver programs. I keep ATK when I have stubborn apps that are stuck because it is easier to get through than Android Task Manager but the auto-kill feature is always disabled. Good coverage of this info.
Click to expand...
Click to collapse
Thanks you. Saw too many threads/posts with questions about ATK and killing tasks. So compiled this so they could all be directed to this thread.
I don't mean to go digging up old threads, but I just wanted to post my opinion here on this memory clearing ordeal.
After reading the entire thread, I am even MORE inclined to want to use ATK or something similar...
At the very bottom of the post, last paragraph, it reads -
How to use memory efficiently
Android manages opened applications which are running in the background, so officially you shouldn’t care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness’ in everyday performance. We can use advanced task killer/task manager and it does its job very well.
Click to expand...
Click to collapse
Here's my take -
While there is no way to override Dalviks operations for application retention, at least while you're operating the device you can keep the memory clear by monitoring and assisting in clearing it out, manually; Which will in fact yield a performance boost for a duration of time. Based on the description of how Dalvik operates, this is true.
Exactly how long of a duration I don't know. But it is as obvious as it gets that while Dalvik memory management is indeed cool, it is far from perfect and definitely induces low memory situations that CAN in fact cause sluggish performance. That much is already known.
So, in my opinion, if you enjoy the absolute maximum performance out of your device, ATK or something similar is definitely NOT a bad idea. Though it has to be done manually and after a period of time applications are brought back into memory, clearing the memory before opening an application allows full memory access to that application and also inevitably reduces CPU load as it removes the requirement for Dalvik to "shove" other applications on idle off the memory to make room for the active applications.
Personally, I just use Task Manager. It seems much more effective at clearing the memory.
Well, there are times when my phone is on for abt a week or so without turning off or rebooting (the times when I resist flashing roms or kernels or modems) and still I hardly feel any sluggishness. And I do NOT use any task killers. I let android handle everything its way.
And there is a difference between cleaning up memory say once every couple days, and having ATK set up to free up memory every hour or two. The first one could be helpful while the second is a battery killer.
rickysa2000 said:
Sweet!! Good Info.. But wrong Section. You should port this in the General Section to help all!
Click to expand...
Click to collapse
why quote such a big post to tell this
come on
regards
strategist99 said:
why quote such a big post to tell this
come on
regards
Click to expand...
Click to collapse
^
Why necropost ?!? Come on !
(just messin with ya)
Sent from my SGH-I897 using xda premium
how about file expert's memory management options?
ok - i get what's being written at the top of this. however, i do wonder about being able to tweak things some, mainly because on file expert's memory manager there's several memory config options: gamer, multi-tasker, light user, whatnot.
i got a phone to fit in my pants pocket, so it doesn't come with tons of RAM. and it freezes quite a bit when swapping between apps. of course there could be many other reasons, but still...
file expert's options don't seem to be persistent, so it's hard to get a handle on which setting would work best. now - would there be a way of making persistent memory optimization changes? if, how?
what is an amount of free memory that would need to be there for things to be smooth? by ATK, i get south of 50Mb quite often, which seems low.
i don't really like ATK's auto-kill - don't know what it will kill, and it seems that a free memory kill-threshold would be better than one based on time.
zdoe said:
ok - i get what's being written at the top of this. however, i do wonder about being able to tweak things some, mainly because on file expert's memory manager there's several memory config options: gamer, multi-tasker, light user, whatnot.
i got a phone to fit in my pants pocket, so it doesn't come with tons of RAM. and it freezes quite a bit when swapping between apps. of course there could be many other reasons, but still...
file expert's options don't seem to be persistent, so it's hard to get a handle on which setting would work best. now - would there be a way of making persistent memory optimization changes? if, how?
what is an amount of free memory that would need to be there for things to be smooth? by ATK, i get south of 50Mb quite often, which seems low.
i don't really like ATK's auto-kill - don't know what it will kill, and it seems that a free memory kill-threshold would be better than one based on time.
Click to expand...
Click to collapse
Auto-kill is quite bad as the it kills processes that always reset.
As for your ram, you could run a Bigmem kernel. 50ram is fairly normal with regular processes and a couple extras. It all depends on what you use/run.
I would need your phone's setup to help you more towards it though.
xperia ray, snapdragon, 512Mb of RAM
don't know what bigmem kernel is or would do. i'm a noob.
the phone as above. list of installed apps courtesy titanium attached - except i've since killed ATK and now trying autokiller, which is good at least for the SD-card parameter tweaks it gives. not sure about its memory management aspects, but at least they're persistent.
list of apps
here's the list - the forum didn't take .htm
and i'm on CM7.2.
EDIT/UPDATE: unrelated to killer apps, but for those of you who came to this thread to find remedies for RAM shortage - my observation currently is that the best thing you can do to yourself is to enable swap. that, and taking out the "play store" took me from 5 crashes a day to 1 - and after half a day of multi-tasking apps i can see up to 80Mb of swap in use, with 60Mb of RAM free, and the phone still running smoothly.
How to detect if an app is in background
In the above article it is said that the memory management is completely under control of Dalvik VM and Android runtime.
Is it not possible for a device driver to intelligently check if any app in background and release memory (allocated inside driver).
onStop(): All the rendering is stopped.
Is it possible to check some app state value to see if app in background or minimized?
This is not the explanation of memory management but process management
I've been looking constantly throughout many forums and have not found anyone with a hindrance of talk about running full linux on webtop with full functionality of the phone.
I've been messing around with the terminal and tried to fish around for something and i wasn't able to find anyway to put ubuntu on this app while being able to support the phone dock accessibilities.
So far for what i know is that its running a 32bit(kinda thought it may be possible for a 64bit counting the dual core) custom UI of Debian while having some source code from Ubuntu to run Firefox. I tried to manually install chrome but was not able. From what I've noticed is that there is a special partition hidden in the root for running webtop mode through the /osh folder i believe.
I bought the the laptop dock and honestly i got to say that this phone has a LOT of potential, the problem to me is that the OS build for webtop is WAY too limited. I would like to see this thing run a full linux with possibly openoffice, chrome, etc. If anyone has any info about a possible hack or something, i'd love to learn about it.
it wud be genious to get ubunut as the 'webtop'
why not
It is Ubuntu, but it has had some things stripped out or built from local sources. Many of the packages are package-name-123.123mot and this causes lots of dep res issues when trying to add in something like xterm from ubuntu feeds.
Lets be clear, there is a linux box lurking in there waiting to be freed. Make is there, gcc is there, X is running on HDMI, there are X apps, apt is there, dpkg is there, /etc is there.
I expect we'll get an xterm running on it this week, if not sooner.
I have the laptop dock, as well. The webtop is this phone's killer feature, imo. Being able to use a full desktop browser is a huge benefit in my line of work. It would be a huge improvement to gain root access and run a more complete Ubuntu.
An update: Success on xterm!
I was able to grab a debian armel xterm and extract it (couldn't install) to /osh/tmp (seemed handy) and fire up /osh/tmp/usr/bin/xterm and display it back to my laptop. I'll have to figure out more about dpkg and why it wasn't installing correctly with this command line, which it seems should have worked:
dpkg -i xterm-armel.deb -root=/osh
We should try to use dpkg properly so we have a maintainable /osh moving forward, to do otherwise is to invite issues. I have dd'ed off my /osh file-system so I can revert when if and when I break it. My goals are fairly straight forward with this endeavor:
* SSH via /osh so it is in init.d and supports -X.
* A terminal of some sort. (half ways done)
* All done via a maintainable and revertible package manager.
To go off laying down zip files or copying around files is far from my goals and should be far from yours.
Full linux?
Arm linux is different from x86 linux. When you say full linux what exactly do you mean?
I understand the need to have it more closely resemble and function like 10.04 lts but it is more likely gonna be closer to a distro like Angstrom...
infrared411 said:
Arm linux is different from x86 linux. When you say full linux what exactly do you mean?
I understand the need to have it more closely resemble and function like 10.04 lts but it is more likely gonna be closer to a distro like Angstrom...
Click to expand...
Click to collapse
ARM Linux and x86 Linux are not different, except in the architecture the binaries are compiled for. The functionality is the same, regardless of the target architecture.
When I say a full Linux I mean it looks and feels like a standard Linux/Unix system with a /var, /etc, /usr, etc. with the most of the functionality we would expect (apparently working /etc/init.d and an actual /etc/passwd) and some of the binaries we know and love (dd, bash, perl, python, vim, Xorg X bits)
It appears to be Jaunty 09.04 based from looking at /etc/lsb-release. Having said that, the packages appear to have been rebuilt at Motorola and some of the deps are missing or I am reading the output incorrectly.
You are confusing desktop linux with embedded linux. For example take a look at the differences in udev.
Sent from my MB860 using XDA App
I hear you, but it looks pretty much like a desktop distro to me, including udev. I do note that /proc and /sys are bind mounts onto /osh/proc and /osh/sys from android, so it is bastardized in that respect.
droidbird said:
I hear you, but it looks pretty much like a desktop distro to me, including udev. I do note that /proc and /sys are bind mounts onto /osh/proc and /osh/sys from android, so it is bastardized in that respect.
Click to expand...
Click to collapse
I'm fairly certain it's the full Ubuntu distro. They've probably snagged packages from Launchpad or such, so once we have dpkg set up, we should just be able to start running with it.
It clocks in (/osh) at 677MB with ~77MB free on the file system. It's pretty feature complete as a userspace from what I can tell.
droidbird said:
It clocks in (/osh) at 677MB with ~77MB free on the file system. It's pretty feature complete as a userspace from what I can tell.
Click to expand...
Click to collapse
Only 77MB free... I might grab an SD card and start installing applications onto it. It'd be easy to add the respective paths to the applications on the SD card to the PATH variable via a script. (I'm thinking about being able to make something that we can pass on as a package to others in the future.
I think the biggest problem will be the RAM. I don't know Android much (2nd week messing with it) but we should find a way to close down some of the apps when launching our 'full' linux. Maybe freeze them or something. If we're using an SD card could we not partition 1GB for swap? I heard about memory problems after having 11 tabs up in Firefox, it'll only get worse with more apps.
Throw in a keyboard/mouse and we could have a desktop that we can plug into any HDMI capable tv/monitor, that would be nice!
droidbird said:
An update: Success on xterm!
I was able to grab a debian armel xterm and extract it (couldn't install) to /osh/tmp (seemed handy) and fire up /osh/tmp/usr/bin/xterm and display it back to my laptop. I'll have to figure out more about dpkg and why it wasn't installing correctly with this command line, which it seems should have worked:
dpkg -i xterm-armel.deb -root=/osh
We should try to use dpkg properly so we have a maintainable /osh moving forward, to do otherwise is to invite issues. I have dd'ed off my /osh file-system so I can revert when if and when I break it. My goals are fairly straight forward with this endeavor:
* SSH via /osh so it is in init.d and supports -X.
* A terminal of some sort. (half ways done)
* All done via a maintainable and revertible package manager.
To go off laying down zip files or copying around files is far from my goals and should be far from yours.
Click to expand...
Click to collapse
I'm interested in this too. I was poking around /osh and trying to get gcc to work so I could try compiling some different things.
I think my aims are slightly different than yours, but lots of the same knowledge is needed. I'm interested in getting applications to run on the phone and showing up in the webtop. i.e. I'd like to have the xterm showing up on the top, not just across the network on a remote X display, like your laptop.
I can't get gcc to work because they seem to have left out the ARM 'cc1' binary which is called.
Anyway, do you mind posting the steps you took (and the site where you got the ARM xterm binary) to get the xterm up and running on the phone? I'm trying to get an ARM cc1 so I can get gcc up and going. From there, I'm hoping I'm not from from 'configure' and 'make' to get lots of different things working. (I realize this isn't something most people would want, but I'm looking at this from the point of view of someone who might like to develop applications for the webtop.)
Also, if you can find out what the proper DISPLAY environment variable is for the webtop itself (and what to tell the 'xhost +' command to let it display X on the webtop), that would be huge for me.
I'll post anything I'm able to find out as well. The more shared knowledge, the better.
For your .deb files, take a look at Launchpad. I'm guessing that's where Motorola probably got their files from.
Does anyone have a backup of their /osh? I might of screwed some stuff up and would like to compare.
I do, currently a 4k dd of the device, ~700mb.
Sent from my MB860 using XDA App
the memory problem is not really an issue, you just have to manually set the partition for webtop mode to be bigger, there is an extra 10gigs built in the phone to run, all that is needed is just the edit on that.
what i mean in full Linux is that i wan't to run REAL applications, not web apps. I ran an external hard drive will movies and music and what not. I saw that this device can really handle heavy traffic like 1080p videos and it brought me to think that this device has the performance to handle a full Linux with minimal lag. a 1080p video runs at an average 2gigs and running on the ram with about at a constant of 150-250 Mb/s depending on how it is running the codec. To be honest the ram is VERY efficient, and the only problem i see to be honest is trying to stream 720p off of YouTube because the phone can't take all the speed (even when in wifi off of a t3 network). There is some limitations but the system can definetly handle high traffic off the ram.
Anyways, aside from that. I searched through the /osh and i found that there is a way to script out addons to do specific back door functions. I'm not really a code scripter so this is where im in uncharted territories. Since this is Ubuntu source code, i believe that if you design a special function script to unlock service mode within the webtop, we might get a full terminal and maybe admin functions. Then maybe we will have right to install specific functionalities. Since Motorola built this build, my guess is that they'll have a pretty complicated security to tap into service mode. Anyone find anything of such resemblance in the root of the os?
Mafisometal said:
the memory problem is not really an issue, you just have to manually set the partition for webtop mode to be bigger, there is an extra 10gigs built in the phone to run, all that is needed is just the edit on that.
what i mean in full Linux is that i wan't to run REAL applications, not web apps. I ran an external hard drive will movies and music and what not. I saw that this device can really handle heavy traffic like 1080p videos and it brought me to think that this device has the performance to handle a full Linux with minimal lag. a 1080p video runs at an average 2gigs and running on the ram with about at a constant of 150-250 Mb/s depending on how it is running the codec. To be honest the ram is VERY efficient, and the only problem i see to be honest is trying to stream 720p off of YouTube because the phone can't take all the speed (even when in wifi off of a t3 network). There is some limitations but the system can definetly handle high traffic off the ram.
Anyways, aside from that. I searched through the /osh and i found that there is a way to script out addons to do specific back door functions. I'm not really a code scripter so this is where im in uncharted territories. Since this is Ubuntu source code, i believe that if you design a special function script to unlock service mode within the webtop, we might get a full terminal and maybe admin functions. Then maybe we will have right to install specific functionalities. Since Motorola built this build, my guess is that they'll have a pretty complicated security to tap into service mode. Anyone find anything of such resemblance in the root of the os?
Click to expand...
Click to collapse
We have root. We could go as far as setup our own desktop environment separate from Webtop. There would be no need to worry about Motorola's security problems.
droidbird said:
An update: Success on xterm!
I was able to grab a debian armel xterm and extract it (couldn't install) to /osh/tmp (seemed handy) and fire up /osh/tmp/usr/bin/xterm and display it back to my laptop. I'll have to figure out more about dpkg and why it wasn't installing correctly with this command line, which it seems should have worked:
dpkg -i xterm-armel.deb -root=/osh
We should try to use dpkg properly so we have a maintainable /osh moving forward, to do otherwise is to invite issues. I have dd'ed off my /osh file-system so I can revert when if and when I break it. My goals are fairly straight forward with this endeavor:
* SSH via /osh so it is in init.d and supports -X.
* A terminal of some sort. (half ways done)
* All done via a maintainable and revertible package manager.
To go off laying down zip files or copying around files is far from my goals and should be far from yours.
Click to expand...
Click to collapse
Fair warning, I'm frequently wrong... but off the top of my head, I think you would need to chroot into the webtop environment in order for a dpkg / apt-get install to work correctly. From what others have posted and my own (brief) investigation, the webtop isn't completely standalone... it shares with the android environment. I've been thinking of leaving the webtop alone for now, and trying the method used to run a chrooted Ubuntu instance on the Nexus One. The risk is low, and once that is in place, I could take a shot at starting an X session that runs out the HDMI, instead of just a VNC server...
EDIT: I should have asked if you chrooted before I just assumed... Sometimes I think before I post, but not often enough.
I got xterm and xeyes to run locally
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(binaries are from a ubuntu-jaunty-arm setup I did in qemu)
After I get a bit more working I'll post better instructions, but for tinkerers:
DISPLAY:0.0 is correct but you also need XAUTHORITY=/data/home/adas/.Xauthority
lxterminal seems to have issues running locally.
Things can be added to the dock by editing /data/home/adas/.gconf/apps/avant-window-navigator/window_manager/%gconf.xml but you'll also need to create a (standard) .desktop file. You can modify the nautilus one to browse /.
i agree package management is needed, but I don't think using the existing one is a good idea. I think either:
1) Create a ubuntu-arm based distro that can be launched when plugged into a dock/hdmi, but leave /osh mostly untouched
2) Or keep everything in a separate prefix, like macports/fink do.
A problem with using /data though is it's mounted nosuid. And /osh is near capacity already.
Hello
I'll still a newbie in WP8 stuff, but I have a silly question or maybe an Idea.
As I have noticed there are lots of APPS running on Windows OS (8,7,XP) to enable ANDROID apps or Games to run on the Windows or MAC
Like BlueStack
So I'm wondering if it's possible to do an Application for WP8 like BlueStack, to be enable to run Android GAMES and if it's possible to run android APPS .. of course it would be so hard to make these Apps pushing Notifications, so I'm wondering about the Games.
Thank you.
Hypothetically possible, but pretty impractical. You'd have to re-implement the Dalvik runtime within the WP8 app framework (and even then, you wouldn't be able to run native apps, which would rule out most games). WP8 also has limitation that make Just-in-Time compilers difficult, which might impede performance. A lot of Android apps wouldn't work because WP8 is so much more restrictive in terms of what capabilities an app can use, too.
Yes, I know there are some distributions that support real time, but I want to come at this issue from a different angle. If you are not familiar with low levels of the Linux OS, please do NOT speculate ! If you are familiar and I am talking crazy, just say so !!
Back in the early 70s, there was a "load and go" OS for PDP-11 computers called RT-11. It was very simple. While you could develop real time "embedded" applications on the target machine, DEC wanted you you to buy a second system for development. The application was transferred to the target machine via paper tape or some other slow simple mechanism (DECtape ?). The target was rebooted into the now load application and off it went. Crude but effective. Thousand and thousand of system were built around this hardware and software.
Time went on and eventually another "layer" was add on top of RT-11 ( developed by S&H Computing) called TSX-11. It allowed the target application to run in the "foreground" while having a "background" for an interactive user to develop the application.
So here is my question
Seeing as most SOCs have 4 or more processors, is it possible for Linux to only use 3 of them ? The 4th processor would run the application in real time (foreground), implying it would have to handle interrupts for those devices it controled. Linux would be running in the "background" and handling all of the "standard" IO. Linux would talk to the foreground via shared memory (pipe).
The big challenges would be loading the foreground application, starting and stopping it.