I am making a car launcher application, which contains shortcuts to other apps, when i'm in another app i'd like to press the home button and go back to my launcher
So basically i need to override the home button outside of my app,the override has to work only when my app is opened in the background so when i close my app the home button will work as usual taking you to your default launcher
Can i implement something like this or i'm asking too much?
There is no way to intercept the home button on Android, unless you make your app the home screen. This is for security reasons, so that malicious apps cannot take over your device by overriding all the buttons that can exit. The home button is the one sure shot way to be able to leave any app.
In short, no it's not possible, and even if it were, it is a serious disruption in what a user expects out of an app's behavior.
If you go the route of making your app act be a replacement home screen you'll have to include in the install instructions for the users to set your app as the default launcher.
Then the home button would take them to your app. In order to get it to switch back to the default launcher when they are not in "car" mode would be a bit tricky but you could prolly achieve it with some sort of fork activity that checks if car mode is enabled if so go to your car mode launcher if not go to the default launcher (it gets trickier if the user already has a different 3rd party launcher) So essentially your app will always be the home screen app no matter if car mode is enabled or not, but if it is not then you manually start the "normal" home screen.
Related
I need to ask for permission from the user. One of the permissions I need is ACTION_MANAGE_OVERLAY_PERMISSION and the other is Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION. When asking for it as you can see in the code below, it takes the user to the Settings screen so the user could tick the permission from there.
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION,
Uri.parse("package:" + getPackageName()));
startActivityForResult(intent, OVERLAY_PERMISSION_REQUEST_CODE);
On some Android phones and Android versions, it takes the user straight to the specific application setting (the app that it is called from) on other devices it opens up the list of applications from which the user has to find the app and then tick the permission. In most cases on Androids lower than 10 it opens up the specific app settings window and when it's 10 or higher, it opens up the list.
Is there a way to make it consistently open the current application setting that is open?
I tried adding:
intent.addCategory("android.intent.category.DEFAULT");
intent.setData(Uri.parse("package:" + getApplicationContext().getPackageName()));
But that did not help either.
And secondly, is there a way to ask for this and other Settings permissions without opening the Settings menu and instead of doing it in a dialog inside the application?
If not then is there a way to ask for multiple Settings permissions one after another because my application requires two Settings type permissions.
EDIT
Here is what I meant by the specific application settings vs the list.
On the left picture, all apps are listed and on the right picture the specific app is opened (happens if you click on the app in the list).
Now in some cases, it directly opens the right picture but mostly it opens the left. Is there a way to force open the right picture at all times?
Is there a way to force open the right picture at all times?
No.
The Settings app usually is modified substantially by the device manufacturer. They can do whatever they want. This includes ignoring the Uri or outright removing third-party access to this screen, where the latter is what the documentation is warning against:
In some cases, a matching Activity may not exist, so ensure you safeguard against this.
If you make your own Android firmware, you could ensure that this Intent action behaves as you want, for whatever devices run your firmware.
My Android app currently enables WRITE_SETTINGS in its Manifest. When the app makes an intent Settings.ACTION_MANAGE_WRITE_SETTINGS, it shows a system dialog enabling the user to set the permission for the app to modify system settings. I would like to change this dialog however because I do not like the layout of the system generated screen. In addition, I would like to enable battery optimization on the app as well, and that has its own separate system dialog. The system dialog takes up the whole screen and can be confusing for the user to use, especially when there are two screens displayed in succession.
I would like to use my own XML layout or a popup for the dialog and letting the user enable/disable these permissions as needed. Is there a way to do that and not have the app launch the system dialog?
You can't change the system dialog for settings, media projection, runtime permissions... It's a system dialog, it can't be changed to prevent abuse.
The best you can do is explain to the user what's expected of them before you start showing these system dialogs.
The system dialog [...] can be confusing for the user to use, especially when there are two screens displayed in succession.
Explain what needs to happen before each step.
Explain what you need from the user in your app, in your visual style, then show one system dialog.
After user confirms it explain the next thing in your app, then show another system dialog.
Avast Anti-Theft (not affiliated) uses this approach when setting the app - it needs to enable its device admin and listen for notifications, both are controlled in system UI.
I have an app for a customer (refer to it as "their" app). When "their" app is open they do not want users of the device to use any other apps.
The only way they want to get round this, is if i create a login page within the app, and from there you can go to the android settings page. If the android settings are accessed, then the user should be able to go anywhere they want, until "their" app is in the foreground again, then the device should be locked into using just that app.
If this makes any difference, "their" app is a cordova app. I dont think it will, but thought i would mention it anyway. Needs to work in android 5.0
Is this possible at all? What would i need to implement for this? A service and timer?
UPDATE
It is a tablet, so it will never ring.
If the user presses the Home button, nothing should happen as the app should stay in the foreground
I'm write launcher switcher. Android show list of installed launchers when I press HOME button. How hide this list or get Home button press event?
What you want is not possible, for obvious security reasons. A malware author could use this feature to replace XYZ app with their own fake XYZ app to attempt to steal private information, without the user's knowledge.
I have solved this issue. I used the method addPreferredActivity of the PowerManager to set default launcher. This method is deprecated and requires a platform key, but I have not found any other way.
Having some really strange "bugs" with my Android application at the minute, it I run it from Eclipse it runs fine, pretty much perfect.
It contains a login screen that I can access and get to my main screen fine when running through Eclipse. When I press the home key and return to my application it returns to the last position (Activity) the application was in.
However when I release sign a build and deploy it on the device it has different behavior,after going through the login screen when I press home and then return to the application the login screen always appears.
Code is identical in both builds, only difference is one is signed with the default debug keystore while the other is signed with my own release keystore.
Has anyone come across this? Its really confusing!
EDIT: More info:
The application currently works like this:
Main activity is launched which then calls the login activity, login activity then moves to my app core activity.
I have also discovered that it appears to be on the first run after install that I have the issue, if I run the app, force close it and then run it again it then runs perfectly without any issue.
So it seems to be something really strange?
I know this is an old question, but this issue created me some headache and I'm posting the solution below in case of someone is having the same problem.
The "weird" activity flow is different between debug and release mode because of Intent's launch mode. When you're in debug, you press the "run" button in order to launch the Main Activity. When you're in release mode, you installed the app, then you press the "open" application button.
Once the Application is opened from different location, the Intent will change and will cause to reopen the app. On top of that (thanks to Android's architecture) if you had multiple activity flow, e.g: Splash -> Login -> Main -> etc. and you press "home" and reopen the application from a different location, the whole Activity flow is restarted, BUT the old activities will remain in the stack. For me, that's caused some problems because of some variable initialization within a Singleton.
In order to fix this, you can set different launch mode within AndroidManifest for your activities:
android:launchMode="singleTask"
also, you could try with singleInstance or singleTop. Each launch modes are having different behaviour.
You can replicate this issue if you have your Application published in Google Play Store. Navigate to your app within the Store and press the "Open" button. Once the app is launched, press the "home" button and go to your Menu screen and open your app from here. You will see that the app is recreated.
Can you configure Eclipse to use the same keystore?
I use an Ant script, which installs my 'debug' application with the same key used for my published versions, so I have not seen this issue.