Related
I have some things on my phone i want to automate,
building an application for it would be a little over the top,
mainly because it can be done with mortscript quite easily
the only problem would be that the script would be running, always..
So i build an application which runs mortscript periodically
the initial app is the config where you can define the settings and select the
directory the App needs to look in.
next have the app create the shortcut and when you run the app through the shortcut, the app should run all the scripts in the folder.
Please note that while the script is running the time does not increase,
this is to make sure that no 2 scripts can be run at the same time.
ToDo.
- change the icon, this one is probably not freeware (any help is appreciated)
- sort the scripts before running
It has been tested on a emulator and my diamond, everything seems to be working like it should.
Let me know what you think
reserved 1
reserved 2
Major Changes to the UI and usage Check the market for the latest version or use the version attached to this post. If you have trouble with the posted version use the market version as it will always have the lastest fixes. The attached version might have an issue I did update the attached version but I won't manage it here.
1. Complete task ui revamp, easier building and management of tasks.
2. Added cron string builder, you can now build time string with rolling pickers and show you the next execution date (great for visualizing your time string). This will build 98% of the schedules most of us use.
3. Clicking on the clock in the Cron tab will now show all the active queued tasks (tasks that were active when cron was started).
4. Added option to run on boot for a task, this makes tasks execute if the option is checked and cron is set to auto restart. This allows a task to run only, at boot, and the task does not have to be active. (Sascha Kerkeling).
5. Added option to import scripts, you can now import the contents of a script file (Sascha Kerkeling).
6. You can now activate/deactivate a task from the tasks view.
7. I have kept the old tasks view in place for this update so that you can trasnfer any existing tasks over... it will be removed next update.
8. Added cron change log... this will automatically show once every update.
9. Added safe guard so that a reboot command cannot be fired with the execute on boot option (just in case).
10. Added better logging of why task commands fail, this will show as a complete stack trace in the execution log.
11. Added 6 new default tasks that might be helpful (Sascha Kerkeling, A. Simmons).
This is cron for your phone a small app I developed to allow me to restart/shutdown my phone on a schedule, but Cron has a billion uses and I wanted to see how others will use it I also use it to backup my market apps on a schedule.
**WARNING YOUR PHONE NEEDS TO BE ROOTED TO USES THIS APP**
This app can be dangerous if used wrong, if you use this app incorrectly and mess your phone up its your fault not mine. You wouldn't blame snap-on if the wrench you used breaks a bolt on your car, so don't try and blame me for what you do wrong with this tool. If you do I will only point at you and laugh.
**WARNING YOUR PHONE NEEDS TO BE ROOTED TO USES THIS APP**
Features:
Uses the standard Cron4Phone time string schedule.
Run all type of shell commands on any schedule you can think of.
Run tasks to shut your phone off on a schedule.
Auto restart so Cron4Phone continues to run even after a restart.
Small apk foot print.
unlimited concurrent tasks available.
Set a task as inactive/active.
Test execution setting to log commands only.
I'm really looking forward to seeing how others will use this tool. Please feel free to point out errors or suggestions. If you want help setting schedule I can give pointers.
Android market download
ooooh
as soon as I can liberate a copy from a market enabled phone I will begin tinkering... that might take a while
would you consider releasing it to f-droid.org if your license allows?
Here you go
Here's a copy... I haven't opened the source up although I probably will in the future, when I have more time to spend on it (working on a video game). This copy is signed with the same key as the market version and its ad supported I will slowing be updating the task management part of the ui.
this is the market description
*****YOUR PHONE NEEDS TO BE ROOTED TO USES THIS APP*****
This app can be dangerous if used wrong, if you use this app incorrectly and mess your phone up its your fault not mine. You wouldn't blame snap-on if the wrench you used breaks a bolt on your car, so don't try and blame me for what you do wrong with this tool. If you do I will only point at you and laugh.
*****YOUR PHONE NEEDS TO BE ROOTED TO USES THIS APP*****
-----------NEW INFO READ------------
After another full audit and help from Sascha Kerkeling and M. Porter, I redesigned Cron to no longer use long running service and instead now (correctly) uses AlarmManager to precisely execute tasks in a WakefullIntentService. This will will insure that all task are executed even when the phone is in deep sleep (even when the phoen doesn't hold any other wake locks) and barely uses any resources to accomplish this. I will now be able to focus on the UI... Dynamic task here we come!
-----------NEW INFO READ------------
Cron4Phone is a time-based job scheduler in Unix-like computer operating systems. Cron4Phone enables users to schedule jobs (commands or shell scripts) to run periodically at certain times or dates. It is commonly used to automate system maintenance or administration, though its general-purpose nature means that it can be used for other purposes, such as connecting to the restart your phone and backing up apps. This is a foreground service so that it is guaranteed to stay running, use the home key to back out of the app or double tap the back arrow to kill the app. Killing the app kills the service.
Features:
Uses the standard Cron4Phone time string schedule.
Run all type of shell commands on any schedule you can think of.
Run tasks to shut your phone off on a schedule.
Auto restart so Cron4Phone continues to run even after a restart.
Small apk foot print.
5 concurrent tasks available.
Set a task as inactive/active.
Test execution setting to log commands only.
This tool can be used to do endless amount of things, I'm really looking forward to see what you guys can use it for so please share your ideas, command and schedules.
I have provided 3 tasks that I thought would be the most useful to most users shutdown, restart, and backup apps.
Interesting
Sent from my SCH-I500 using XDA App
testing your application, it's really simple.., i'm hoping custom task can be added more
New version
EDIT: removed refer to the OP...
I attaching a new version to this post, it fixes a bug with the restart on reboot not registering your tasks. Basically if your phone reboots and you have active tasks and cron is started it will keep on running.
As for the ui I will slowly work on updating the task tab so that task can be managed dynamically, other than that the rest of the ui will basically stay the same, I want it to stay simple and small.
The market version has also been updated.
ttt for updates!
Very nice app, I would like to see more Linux tools working with Android.
Sent from my Zio using xda premium
Yes and this was one that I thought was needed, and while you can run cron on your phone through busy box, this app doesn't need that module and uses standard java to mimic cron all while putting a clean ui on top of it.
Thank you.
[EDIT]
ACK! Okay, I just stopped and started the cron and it is now working. Sorry about this post. :-/
[/EDIT]
I am going to resurrect this thread because I can't figure this out and I'm a Unix admin. I have tried to set a schedule for a job to run every 5 minutes (this was to test, the actual job will run every 30 minutes). I have tried to set */5 * * * *, /5 * * * *, and 0,5 * * * * and none of them work for every 5 minutes. Can you look into this or give an example in here? Thanks!
fstrim
If anyone is still out there -- I use Cron4Phone to schedule daily reboots and would like to add an fstrim command to run daily, maybe weekly. Can anyone help me with setting this up (command syntax, etc)?
Is there any chance to get the apk from somewhere? Thanks in advance!
I hate it when an app runs in the startup specially if the app is not that important. Is there any way of disabling those apps that run in the startup? As well as those apps that runs in the background even if you don't need em to? They eat up RAM and make the NC slow! I wish I can manage them.
Let them be android takes care of itself.
Read this: http://forums.androidcentral.com/general-help-how/102171-apps-always-running.html#post1088042
---
- Sent from my LG Optimus V using Tapatalk
les02jen17 said:
I hate it when an app runs in the startup specially if the app is not that important. Is there any way of disabling those apps that run in the startup? As well as those apps that runs in the background even if you don't need em to? They eat up RAM and make the NC slow! I wish I can manage them.
Click to expand...
Click to collapse
Yes...get an app in the market called Android Optimizer, it is free. In the menu hit the startup manager icon. Disable the app (s) you don't want to run at start up or background.
StarlahRain said:
Yes...get an app in the market called Android Optimizer, it is free. In the menu hit the startup manager icon. Disable the app (s) you don't want to run at start up or background.
Click to expand...
Click to collapse
You sure of that name? I did a search in the market and do not see it.
StarlahRain said:
Yes...get an app in the market called Android Optimizer, it is free. In the menu hit the startup manager icon. Disable the app (s) you don't want to run at start up or background.
Click to expand...
Click to collapse
You do not need an app like this. People use task killers and startup blockers and then complain about how crappy and slow stuff is because THEY ARE NOT ACTUALLY RUNNING IN THE BACKGROUND. They are cached for faster start up next time. They do not take up any battery or CPU power. Android is linex not windows.
--------------------------------------------------
Here is the post i linked to earlier:
I develop Android apps so I though I'd explain why a task killer isn't needed on an Android system.
Activities
Android apps use activites to preform tasks. For example, if you use a file manager to send a picture via email, the file manager calls the send activity within an email app, passes the file name to it and the email app sends the picture.. not the file manager. This will result in seeing the email app as "running" even though the user didn't actually launch that email app.
Smaller apps
Using activites helps developers design smaller apps. A file manager app that contains every bit of code needed to do everything a file manager does would likely be so large that no one would want to install it. Developers know that an android phone more than likely has an email app so there is no need for the developer to include email code in his/her file manager to send a picture when he/she can call an activity in an existing email app to do the job. This results in a smaller file manager app since there is no need to include email code or any other code for an activity that can be done via an app that is already present on the phone. This also alleviates redundant code. When you install an app outside of the android market, also known as sideloading, the file manager app calls the package installer (already present in Android) to install the requested app.
Running apps vs. cached apps
The "Manage Applications" list included in many android devices lists running apps as well as cached apps. Cached apps don't use any CPU or battery, they're cached so they will load faster the next time you need them. Killing cached apps results in those apps requiring more time to load the next time they are launched.
System management
By default, every android application runs in its own Linux process. Android starts the process when any of the application’s code (activities) needs to be executed, and shuts down the process when it’s no longer needed and system resources are required by other applications.
* Android is hard coded to automatically kill a task when more memory is needed.
* Android is hard coded to automatically kill a task when it’s done doing what it needs to do.
* Android is hard coded to automatically kill a task when you haven’t returned to it in a long time.
* Most services (while possibly running in the background) use very little memory when not actively doing something.
* A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
* Killing a process when it isn’t ready only causes it to have to reload itself and start from scratch when it’s needed again.
* Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
* Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
* The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
* Most applications will exit themselves if you get out of it by hitting “back” until it closes rather than hitting the “home” button. But even with hitting home, Android will eventually kill it once it’s been in the background for a while.
If you see an app running that you didn't launch, it's most likely because an activity within that app was called by another app to perform a task. If you kill the app you didn't launch, the system has to relaunch that app in order to complete its task. This is why some people kill a task and then see it immediately running again. Constantly killing that app creates a situation where the user is battling the system resulting in wasted system resources.
Android is Linux
Android is not a Windows-based OS, it is based on Linux. Many of the apps you think are running aren't actually running, they're cached, this is typical with a Linux operating system and is much more efficient than other systems. Cached apps don't use any CPU or battery, they're cached and will load faster the next time they're needed.
Let the system manage resources.
---
- Sent from my LG Optimus V using Tapatalk
patruns said:
You sure of that name? I did a search in the market and do not see it.
Click to expand...
Click to collapse
I apologize ..it is called Optimize Tool Box...lite version(free)...
koopakid08 said:
You do not need an app like this. People use task killers and startup blockers and then complain about how crappy and slow stuff is because THEY ARE NOT ACTUALLY RUNNING IN THE BACKGROUND. They are cached for faster start up next time. They do not take up any battery or CPU power. Android is linex not windows.
--------------------------------------------------
Here is the post i linked to earlier:
I develop Android apps so I though I'd explain why a task killer isn't needed on an Android system.
Activities
Android apps use activites to preform tasks. For example, if you use a file manager to send a picture via email, the file manager calls the send activity within an email app, passes the file name to it and the email app sends the picture.. not the file manager. This will result in seeing the email app as "running" even though the user didn't actually launch that email app.
Smaller apps
Using activites helps developers design smaller apps. A file manager app that contains every bit of code needed to do everything a file manager does would likely be so large that no one would want to install it. Developers know that an android phone more than likely has an email app so there is no need for the developer to include email code in his/her file manager to send a picture when he/she can call an activity in an existing email app to do the job. This results in a smaller file manager app since there is no need to include email code or any other code for an activity that can be done via an app that is already present on the phone. This also alleviates redundant code. When you install an app outside of the android market, also known as sideloading, the file manager app calls the package installer (already present in Android) to install the requested app.
Running apps vs. cached apps
The "Manage Applications" list included in many android devices lists running apps as well as cached apps. Cached apps don't use any CPU or battery, they're cached so they will load faster the next time you need them. Killing cached apps results in those apps requiring more time to load the next time they are launched.
System management
By default, every android application runs in its own Linux process. Android starts the process when any of the application’s code (activities) needs to be executed, and shuts down the process when it’s no longer needed and system resources are required by other applications.
* Android is hard coded to automatically kill a task when more memory is needed.
* Android is hard coded to automatically kill a task when it’s done doing what it needs to do.
* Android is hard coded to automatically kill a task when you haven’t returned to it in a long time.
* Most services (while possibly running in the background) use very little memory when not actively doing something.
* A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
* Killing a process when it isn’t ready only causes it to have to reload itself and start from scratch when it’s needed again.
* Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
* Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
* The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
* Most applications will exit themselves if you get out of it by hitting “back” until it closes rather than hitting the “home” button. But even with hitting home, Android will eventually kill it once it’s been in the background for a while.
If you see an app running that you didn't launch, it's most likely because an activity within that app was called by another app to perform a task. If you kill the app you didn't launch, the system has to relaunch that app in order to complete its task. This is why some people kill a task and then see it immediately running again. Constantly killing that app creates a situation where the user is battling the system resulting in wasted system resources.
Android is Linux
Android is not a Windows-based OS, it is based on Linux. Many of the apps you think are running aren't actually running, they're cached, this is typical with a Linux operating system and is much more efficient than other systems. Cached apps don't use any CPU or battery, they're cached and will load faster the next time they're needed.
Let the system manage resources.
---
- Sent from my LG Optimus V using Tapatalk
Click to expand...
Click to collapse
Yes..I have noticed some side effects.alarms and what not. I guess ur right the only real way is to completely uninstall the apk ..would u happen to know why my adw launcher keeps forceclosing each time boot my nook? I am not running any icon packages..so what other source (or app) could be calling on it to run at startup?
StarlahRain said:
Yes..I have noticed some side effects.alarms and what not. I guess ur right the only real way is to completely uninstall the apk ..would u happen to know why my adw launcher keeps forceclosing each time boot my nook? I am not running any icon packages..so what other source (or app) could be calling on it to run at startup?
Click to expand...
Click to collapse
I am not familiar with adw. Is there an option to save it in memory I know that many replacement launchers do so you might want to make sure that is checked.
Also if you are using a task killer, it is probably trying to kill it and that could cause it to force close.
---
- Sent from my LG Optimus V using Tapatalk
StarlahRain said:
Yes..I have noticed some side effects.alarms and what not. I guess ur right the only real way is to completely uninstall the apk ..would u happen to know why my adw launcher keeps forceclosing each time boot my nook? I am not running any icon packages..so what other source (or app) could be calling on it to run at startup?
Click to expand...
Click to collapse
Do you have Titanium Backup installed? You can clear data and uninstall apps with that as well.
auto starts kills those apps... i run it on my NC>.......i dont need dialer /voicemail...etc.....
Just a thought but if you continue to have force close issues with apps, try running fix permissions. This usually ends the issues. I run adw ex and have no problems. Those few times I have had issues, fix permissions has solved the problem. Just sayin.....
Sent from my NookColor using Tapatalk
Hello,
In a component of my application I have an image followed by 4 button choices. When the user presses a button, the other buttons should be disabled and after a 500 ms pause it should inform the user if the choice was correct using a visual cue (such as "want to be a millionaire" where the button blinks with a background color). Afterwards the next image is loaded and proceeds as before.
Thus far I managed to get it working but I feel this approach is partially wrong. As per documentation I'm using an AsyncTask, loading the image in the background and updating the imageView from there. The buttons are disabled from onClick, and using a Handler with a Runnable, I schedule it to run in 500 ms (I also maintain an extra reference to the correct choice with a member Button variable). This only half works as expected because I want another 500 ms of delay when the choice is revealed as correct/incorrect.
What I really want:
1) After the user presses a button, disable the rest
2) Immediately start loading the next image in the background
3) Wait 500 ms to reveal if the choice was correct/incorrect
4) Highlight the correct choice for 500 ms
5) If the image was loaded, display it and continue
Something like this. Instead, what I now do is starting to load the image after the user is informed of his/her choice. Any advice on how I can improve this?
Hi,
Do you have the images locally or you are downloading them from the web? If you have to download images I recommend you a library called "Universal Image Loader for Android"
jdroidsoft said:
Hi,
Do you have the images locally or you are downloading them from the web? If you have to download images I recommend you a library called "Universal Image Loader for Android"
Click to expand...
Click to collapse
I have the images locally in my assets folder.
mmark1 said:
Hello,
In a component of my application I have an image followed by 4 button choices. When the user presses a button, the other buttons should be disabled and after a 500 ms pause it should inform the user if the choice was correct using a visual cue (such as "want to be a millionaire" where the button blinks with a background color). Afterwards the next image is loaded and proceeds as before.
Thus far I managed to get it working but I feel this approach is partially wrong. As per documentation I'm using an AsyncTask, loading the image in the background and updating the imageView from there. The buttons are disabled from onClick, and using a Handler with a Runnable, I schedule it to run in 500 ms (I also maintain an extra reference to the correct choice with a member Button variable). This only half works as expected because I want another 500 ms of delay when the choice is revealed as correct/incorrect.
What I really want:
1) After the user presses a button, disable the rest
2) Immediately start loading the next image in the background
3) Wait 500 ms to reveal if the choice was correct/incorrect
4) Highlight the correct choice for 500 ms
5) If the image was loaded, display it and continue
Something like this. Instead, what I now do is starting to load the image after the user is informed of his/her choice. Any advice on how I can improve this?
Click to expand...
Click to collapse
Correct me if I'm wrong but you outlined what you want to do ? what part do you have a problem with ? and is this homework by any chance ?
deanwray said:
Correct me if I'm wrong but you outlined what you want to do ? what part do you have a problem with ? and is this homework by any chance ?
Click to expand...
Click to collapse
Yes I did but I'm looking on advice on how to accomplish this
Of course it's not homework.
mmark1 said:
Yes I did but I'm looking on advice on how to accomplish this
Of course it's not homework.
Click to expand...
Click to collapse
well I mean what part of what you said you want to do are you having a problem with, cause you outline what you need to do...
and from what you have done, sounds like there is nothing that you're missing ?
Luckily, loading images from the assets directory will only take a couple of milliseconds tops so having your app start loading the image after the user makes a choice will guarantee that the image will be loaded with no jank.
First of all I know that this title creates a lot of questions.
The problem is exactly what the title says.
While developing apps, you make mistakes (NullPointers etc)
They are thrown when the occur, normally.
Today, it's different, sometimes, when Android (Studio) feels like it wants to help me, it redirects the debugger to a class that is used to "crash" the app at an exception.
With the cool features of Android Studio, you are able to see the content of the strings during debugging. With that feature, I've been able to solve most of the problems.
But now, I ran into a problem that doesn't have the solution above.
When the app "crashes" the screen stays white, and nothing is outputted in any logcat.
All it says is
"D/AndroidRuntime: Shutting down VM"
Is this a bug in Android Studio or in Android?
Hello,
First of all make sure that you have the latest version of Android Studio.
When the app crashes is selected application above the logcat (there is a spinner which says you what app is being displayed, does it say 'com.yourpackagename'? or does it say 'No Application'?) If so I think there is a bug in Android Studio, I have faced it too several times. When your app crashes it force closes the app?
You can try these things:
Unplug your phone and plug it again and wait for a confirmation on the device's screen.
If the confirmation dialog is not showing up, while the device is connected via USB, go to the Settings and disable the USB debugging mod. Wait a few seconds and re-enable it. Wait for confirmation on the device. If still not shows. Close the Android Studio and repeat the above steps. Reopen the Android studio. Run your app, if still not getting logcat you can try getting it manually like this:
Go to the folder where adb is installed (Normally on Windows C:/Users/Username/Appdata/Android/sdk/platform-tools) via terminal with admin rights .
Run cmd.exe as admin, type:
cd ../../Users/Username/Appdata/Android/sdk/platform-tools (where Username is the username of your windows account.)
Type adb devices while your phone is connected via USB with debugging on
See if it says unauthorized, if not, you are good to proceed to the next step.
Type
adb logcat > mylogcat.txt
And quickly open your app to go to the app that causes the crash. Try to cause the bug. When the bug occurs press Ctrl+C
Now your logcat is in the mylogcat.txt within the same folder of adb.
If you need more help extracting the logcat via the above way (manually) let me know
Hmm, at the moment the crash occurs, the app freezes and stays white. Only the main thread though. I've checked the logcat in Android Studio, the app is my app, and the doesn't really matter. It shows nothing.
No logcat not even with the cmd option.
Could it be that my custom rom is causing difficulties?
Thanks,
Tim
Try to place breakpoints in every line on your code. Try step by step to run the app line by line and where the execution flow jumps some lines of code that it shouldn't or stucks at a line of code whithout going to the next lines of code that it should, there should be the problem.
Are you doing intense work on the main thread? I had experienced an issue where I was doing heavy work on a view's onTouchListener and because the touch events were bottlenecking, my UI stuck, and on logcats I didn't got any error, but got a warning that the thread is shutting down due to the fact that the onTouchListener was busy to handle the touch event.
The best option and the most reliable you have now is to debug your app line by line as mentioned above. If it does not help, try commenting lines of code where you think you may be doing intense work or inside listeners and see if your app still crashes. Then uncomment blocks of code and run again and again to see until it crashes again. In the last block of code that you uncommented should be the error.
That way you can limit your search on these lines of code.
If you could further provide any detail of what are you doing in the main thread or any sample code, I will be able to help you further
I do not think that it is related with the custom rom, otherwise logcats would have some errors of missing packages etc
Well, using breakpoints I was redirected to the piece of code that is used to output exceptions. I didn't had a breakpoint there so I don't know why it went that deep. I'm doing heavy for with the runtime.exec command.
I've discovered the exception that was thrown when I posted this question, and the exception wasn't printed anywhere so I don't know why this isn't working. I was getting the java.lang.NumberFormatException exception. This will cause the app to crash, right?
If not how do I 'enable' that?
Thanks
If you are catching that exception the app will not crash. (try catch block). It may crash when any variable from that try catch block had that Number format exception, but when referencing it from outside the try-catch block.
Numberformat exception is occured when trying to convert String to Integers or a Number, and the string does not match the Integer format. E.g. Integer.parseInt("4.3") will throw that exception.
To enable the crashing of the app during that exception, do not catch that exception (NumberFormatException). If you are catching Exception (it is a superclass of NumberFormatException and is more general, it includes this exception too) then again your app will not crash.
If you are catching any of these exceptions, your app will not crash (may crash inside the catch or outside the try catch block)
Exception
RuntimeException
IllegalArgumentException
NumberFormatException
Possibly, a string conversion to Integer or Long or Double or Float may be causing your problem The errors are "silenced" due to the try-catch block Are you printing the exceptions with e.printStrackTrace in the first line of the catch block? (e is the Exception caught)
Hmm, I'll take a look at my code so check if I used a try and catch block.
Thanks!
It was the fault of Google Analytics, I had exception reporting on and that was causing the app to freeze instead of crashing and showing the exception.
Thanks!!