Is there any rom for s7 that allows both apps on multiwindow to be active at the same time? As default for Android Oreo, only app in focus can be active, the other one would be paused, unless the app is specifically coded to run even if not on focus (like google apps). I heard this works on MIUI, where people can launch and play two instance of Pokemon Go at the same time.
Related
"External" App Backgrounding - True 100% Multitasking for the Next Gen of Apps?
There are many apps in Android that don't behave when you multitask or should i say TRY to multitask with them. Recently more and more apps just refuse to multitask, as they will either stop or reload themselves to their home screen when the app leaves the foreground.
For instance NetFlix, WatchESPN, TWEETCASTER, the native android music player and in-browser streaming radio/video apps will abruptly cease playing the second you do something else. Even worse when you return to the app you have to start all over as it won't be in the same menu as when you left the app. And these are just to name a few of these misbehaving apps.
I was hoping that some kind of app could solve this dilemma, where it would externally keep a chosen app "in memory" or in a locked state. This would give the power to the user instead of allowing the app to dictate how it should run on the OS. It would be 100% TRUE BACKGROUNDING for the Android OS!
I should be able to designate the app or apps that should be "backgrounded" or "locked" in memory, so that we could do any other tasks and if I was to return to the locked app it would be in the same exact state as when you left it.
If the "locked" or "backgrounded" app was a streaming video/radio app, then if you were to lock the app in memory, then the streaming video/radio should continue to stream or play in the background until you either manually exit the app or un-lock the app.
There were a few iphone apps that did this similar function as well, running off the "backgrounder" function. I'm hoping that this can be duplicated on the Android OS, as this is a very frustrating shortcoming of the Android OS. I realize that Android does offer true multitasking, but the problem is that it also caters to misbehaving apps, giving them the ability to not multitask.
I would imagine that the app would have to run under root, but I think this can be done. Anyone think they can offer this up to the community? Thanks!
I had given my old Android 2.3 phone and a fairly new Android 4.4 tablet to my kid.
Within about a month, both devices basically became non-functional on start up.
After some analysis, it became clear that all the games and recreational apps my kid installed was causing the problem: they were all built to auto-start on device boot up, and they lacked an option to tell them not to auto-start on device boot up.
Since both devices were rooted, I used a tool (Clean Master) that quickly identified the auto-start apps and stopped them from auto-starting.
My question is this:
Why would an app developer build an app that auto-starts with no option to disable that? Many auto start apps will just kill the usability of the device, and it isn't trivial finding out why.
If the device was not rooted, there's probably no way to stop these apps except to uninstall them. If Android allows a third-party app on a non-rooted device to auto-start, why isn't there an app that works on non-rooted devices to stop these apps from auto-starting?
Nate2 said:
I had given my old Android 2.3 phone and a fairly new Android 4.4 tablet to my kid.
Within about a month, both devices basically became non-functional on start up.
After some analysis, it became clear that all the games and recreational apps my kid installed was causing the problem: they were all built to auto-start on device boot up, and they lacked an option to tell them not to auto-start on device boot up.
Since both devices were rooted, I used a tool (Clean Master) that quickly identified the auto-start apps and stopped them from auto-starting.
My question is this:
Why would an app developer build an app that auto-starts with no option to disable that? Many auto start apps will just kill the usability of the device, and it isn't trivial finding out why.
If the device was not rooted, there's probably no way to stop these apps except to uninstall them. If Android allows a third-party app on a non-rooted device to auto-start, why isn't there an app that works on non-rooted devices to stop these apps from auto-starting?
Click to expand...
Click to collapse
Actually, there were non-root apps that could disable auto-start of other normal apps till JellyBean 4.2 I guess.
Then came the security enforcements which prevented this for non-root users.
Android assumes that an app necessarily needs auto-starting at boot for the smooth working of the app.
There's a reason behind that.
For example, if you disable auto start of FB messenger or WhatsApp, you won't automatically get notifications unless you open it one time so that certain services begin to run in background.
The same goes for your kid's apps like Talking Tom, which gives essential notifications (from a kid's point of view) like "I'm Hungry" or "I wanna pee" or something like that
But you have non-root apps too (you gotta dig a lil deeper to find them) which doesn't work like root apps, that is, doesn't disable them to start at boot. Instead, they stop the apps/services after booting that's disabled in that app.
Apps like CC Cleaner or the so-called antivirus apps work that way only
How to install apps on your Android Wear smartwatch
>> By David [email protected]
1. Find your apps
Google has kindly put up a gallery of Android Wear apps on Google Play – most of these apps have been updated to provide something else on your wrist besides simple notifications. A growing number of them (including @here) have been built specifically for watches rather than phones, but are still installed through your mobile.
You can find the same selection from the Android Wear app on your smartphone: choose 'Browse suggested apps' from the front page of the app.
2. If you've ever installed apps on your phone then you can install apps on your smartwatch – the process is exactly the same for Android Wear apps whether you're using Google Play on the web or the Play app on your phone. Tap through the confirmation screens (and any payment information dialogs) to start downloading your chosen app. Apps specifically built for Android Wear will be transferred over automatically and won't show up as icons in the list of apps on your smartphone.
3. If you want to run an app from your watch, with the new Lollipop 5.1 update there is a new list of apps to choose from before you hit the old actions list - just tap any app to start using it. The menu is the first list that comes up when you swipe to the left before contacts.
Most apps also come with a voice command you can use as an alternative way of launching them (check the app descriptions for details).
4. Watch navigation and Launching from your phone, Setting up notifications>>Setting up default apps
Good tut
Thanks for the tutorial. Very easy to follow.
How to install apps on your Android wear
Soon I'm planning to hit a purchase to android wear smartwatch & the informative content that you have posted will be helpful for me in future.. Thanks a lot for the same.
Useful information. But will it work, if I am using a modified version of Android. Like I am thinking about having a Block Modular Smart watch.
Sent from my GT-S5360 using XDA Free mobile app
Can I just say what a relief to find someone who actually knows what they're talking about on the internet? You definitely know how to bring an issue to light and make it important. More people need to read this and understand this side of the story. I can't believe you're not more popular because you definitely have the gift.
Delete
Hi folks, I am tempted to replace my old phone with the newly released 8T.
There is a certain feature I would like the 8T/Oxygen OS to have, which is to run apps with its cloned version and work profile version simultaneously in split screen mode (2 foreground both active and 1 background).
The phone I have right now runs MIUI and I am able to create a cloned version of the app with MIUI's built in cloning feature, and then I used Island to create a work profile version or the app, making it 3 copies total of a certain app, and I am able to run the them all at once in split screen mode.
I don't have oneplus devices so I am unable to test it. but I did go to my local store to see if oneplus/oxygen os can clone. Unfortunately it could not clone the app i want. and then i was told that if i install it through ADB or some tricks in developer settings I can clone, plus help from Island I can also have 3 copies. But the guy told all these also mentioned that he had problem running further copied apps (like other work profile and cloned apps) as it crashed and he couldn't find a way to fix it.
Can someone verify these? does cloning apps through ADB always have issues running with the original apps and work profile apps? thanks in advanced
On OOS 11 and 12 when I force close any app, it stays closed all the time. I have one or two apps that I don't need to run all the time, just from time to time, so I force them close usually.
But now I'm on OOS 13 and when I force close app it's re-run after some time. It looks like android "revives" app. And this app has unchecked "backgroud activity" and "auto lunch" of course.
Is this a new "feature" of android 13? Or OOS maybe?
The new "feature" you've said is actually "something normal all the time" form Android 4.0 +. This is something you can have on AOSP. What you want is actually something "dirty" made by the device manufacturer, which is a nightmare for Android developers. Those manufacturers don't follow the Android standard and prevent the software to be triggered under some circumstances, this breaks the functionality of the app.
For example, using the Android WorkManager can register a worker with a scheduled task. Developers can assign the task to be executed at a specific time or every a period of time. The WorkManager is a wrapper for Jobscheduler and AlarmManager. Depending on the Android OS version, the WorkManager automatically choose to use one of the above methods to run the scheduled task. If an app registers a PeriodicWorkRequest and assign it to execute every 2 hours, even the app is closed, the PeriodicWorkRequest still can be triggered and revives the app every 2 hours. The nightmare for developers is that OPPO, Xiaomi...etc, these manufacturers prevent the scheduled tasks to be executed if the app is closed(Hall of shame). They are not following the Android standard, so apps can not behave as expected. It is totally different from the documentation at developer.android.com, but every manufacturer is doing this under the excuse of battery optimization, so many users think this is normal. However this is actually some nasty customization to the OS made by the manufacturer to break many apps on the device. That's why apps with background services, such as, Tasker, Bitwarden can not work correctly on many devices if they're not excluded in battery optimization management apps made by the manufacturer.
Almost every Android developer has to tell users to visit https://dontkillmyapp.com/, because Chinese manufacturers like to kill app services and break all the apps with background services. And finally now Google is introducing CTS-D, to tell devs about how background services work on the device. I guess this is why things are finally moving back to normal in Android 13.
#The page https://dontkillmyapp.com/ is a website made by developers to teach users to whitelist apps after receiving a lot of complaints about apps not working correctly. Thanks to those manufactures created this mess.
evilhawk00 said:
The new "feature" you've said is actually "something normal all the time" form Android 4.0 +. This is something you can have on AOSP. What you want is actually something "dirty" made by the device manufacturer, which is a nightmare for Android developers. Those manufacturers don't follow the Android standard and prevent the software to be triggered under some circumstances, this breaks the functionality of the app.
For example, using the Android WorkManager can register a worker with a scheduled task. Developers can assign the task to be executed at a specific time or every a period of time. The WorkManager is a wrapper for Jobscheduler and AlarmManager. Depending on the Android OS version, the WorkManager automatically choose to use one of the above methods to run the scheduled task. If an app registers a PeriodicWorkRequest and assign it to execute every 2 hours, even the app is closed, the PeriodicWorkRequest still can be triggered and revives the app every 2 hours. The nightmare for developers is that OPPO, Xiaomi...etc, these manufacturers prevent the scheduled tasks to be executed if the app is closed(Hall of shame). They are not following the Android standard, so apps can not behave as expected. It is totally different from the documentation at developer.android.com, but every manufacturer is doing this under the excuse of battery optimization, so many users think this is normal. However this is actually some nasty customization to the OS made by the manufacturer to break many apps on the device. That's why apps with background services, such as, Tasker, Bitwarden can not work correctly on many devices if they're not excluded in battery optimization management apps made by the manufacturer.
Almost every Android developer has to tell users to visit https://dontkillmyapp.com/, because Chinese manufacturers like to kill app services and break all the apps with background services. And finally now Google is introducing CTS-D, to tell devs about how background services work on the device. I guess this is why things are finally moving back to normal in Android 13.
#The page https://dontkillmyapp.com/ is a website made by developers to teach users to whitelist apps after receiving a lot of complaints about apps not working correctly. Thanks to those manufactures created this mess.
Click to expand...
Click to collapse
I think the point rufik made is the opposite. It's not about android autokilling app.
Instead when he force closes the app, it starts again.
Check that Auto launch isn't enabled for the app. Settings>Apps>Auto launch
Rootk1t said:
I think the point rufik made is the opposite. It's not about android autokilling app.
Instead when he force closes the app, it starts again.
Click to expand...
Click to collapse
No, you don't understand my point. I'm talking about this under the view of an app developer. I mean auto killing app also has a feature that prevents Jobscheduler to be called.
What I meant:
Due to no app auto killing => system not preventing Jobscheduler to be executed after app force close => Jobscheduler executed after force close app(Jobscheduler task was created before force close app, and Jobscheduler is not the part of app, so it is not forced closed, it still execute, it should be cancelled by the app itself) => Jobscheduler task call codes from the app => the app starts itself.
More info : https://stackoverflow.com/a/63226260
With Jobscheduler, you can make a app to restart itself after forced close on AOSP. But this trick never works on manufacturer customized Roms with app auto killing feature.