I'm looking for a way to find out which browsers are installed on the Android Smartphone and their package names.
Why do I need it?
Well basically, my App reacts on certain URLs, i.e. http://bit.ly, so when the click such an he will get an choice in which App to open it. So far everything is working as intended.
If the user sets up this app as default for this kind of links, it will always open in this one without further asking the user. So far so good too. But by doing this, he will be completely unable to open this links in his browser.
So I need a way to send this intent directly to the browser, but to do so I have to know which app the user has set to be default for http/https scheme for example (as user can change it if there is more than 1 browser installed).
Sending the intend with
intent.setComponent(new ComponentName("com.android.browser", "com.android.browser.BrowserActivity"));
should't be a problem I think. The problem is, I can't send a standard intent für URLs, because my App would catch it again if set as default by the user.
should't be a problem I think
Hardwiring in the package and class names of code that is not yours is always a problem.
So I need a way to send this intent directly to the browser, but to do so I have to know which app the user
has set to be default for http/https scheme for example (as user can change it if there is more than 1
browser installed).
Use PackageManager and queryIntentActivityOptions() to filter your activity out and get a list of other activities that the user can choose from.
Related
In my app i handle Intent.ACTION_SEND intent sent from other apps.
One of such senders can be the Chrome app.
I can simply send the URL of the current page or the selected text from the Chrome app to my app via built-in 'Share to ...' functionality inside the Chrome. In both cases in my app I can access the shared text via Intent.EXTRA_TEXT.
However for the case when selected text is shared additionally to the text itself I would like to receive the URL of the page to which this text belong.
I've blindly tried several other Intent.EXTRA_xxx fields but without any luck.
Does anyone know is it possible at all? Is it more-or-less universal or app-specific?
In case if it is not possible to receive this info from the intent, are there any other ways to achieve the similar goal? Maybe somehow ask the chrome-app directly what is/was the current page? Will be glad to any ideas...
You might find my question silly, but I can't find anything about it. I don't even know how to call it to get the tutorial I need.
I want simply my application after clicking a button to start for example Waze and pass on the address that the user can navigate to it.
If you could just direct me what should I look for it will be great.
If you want to launch the Waze app specifically, you can use the URL scheme at waze.com/about/dev to launch the app. I don't know of any Intent protocol or URL scheme that's shared by any and all navigation apps.
Is there any way to signal Android OS to open the package installer upon download of an .apk file?
Perhaps by Content-Type? or maybe an APK specific url protocol, like apk://apk.location?
Are you doing the download yourself in your own app, or are you trying to create some behavior in an external app?
I don't think you'll be able to trigger behavior upon download outside of your app (since the user would have to select the downloaded file in order to open it), but if you're handling the download yourself, I think you want this post on how to install an application programmatically.
Edit: Addressing your comment in which you said you are writing a website and want to be able to force the APK to be opened by a native app: I can think of a way to do something like it, but you would have to handle the download in the native app because you won't get the browser to do the download for you.
You'll need to register your native app to receive ACTION_VIEW Intents with URIs in whatever format you choose; I recommend using something like yourappname://localhost/escaped_download_url_to.apk. In your Activity get the path from the URI in the Intent and grab the last part of it (URI handling is broken into a few components: protocol, host, and path). Unescape it as necessary and then start the download manually in the app, and then upon completion you open the downloaded APK from wherever your app put it, using the link I provided.
So long as you make sure your mobile website provides an href to yourappname://localhost/escaped_download_url_to.apk, you'll be able to trigger this behavior. When the user clicks that link, it should provide a dialog to choose which app to use to open it (if they have more than one app capable of doing so) which when they select your app will launch the Activity that you registered with the Intent filter.
Edit the second: you probably don't need to do any escaped URIs; just using a made-up URI protocol as you suggest in your own post should work, so long as your app registers to receive Intents with that protocol. yourappname://yourserver.com/my/location.apk will work. All that really matters is being able to pull the download URL out of the data you give to the app in the URI.
I'm developing an app that we will put on Android tablets on be used by employees in the field. We want to lock down internet access as much as possible to minimize data usage (so that the employees can't go streaming Netflix movies or something and driving up our data usage). As part of that effort, I'd like to have http(s)?:// links open up in a custom activity I made. Now, I can easily do that by registering the activity with an intent filter on the http/https schemas, but I'd prefer not to have the user have to choose between browsers when opening a link, and I don't want my activity to become the default activity for every link (there may be situations in which the user should be using the Android browser).
Is there a way to set up my activity as the http handler...but only for links launched from my app?
Is there a way to set up my activity as the http handler...but only for links launched from my app?
If the links are from your app, just use startActivity() with an Intent identifying your activity, rather than some generic Intent like ACTION_VIEW.
If your issue is that you are displaying the Web content in a WebView and links clicked there lead to the browser, use setWebViewClient() along with a WebViewClient implementation that handles shouldOverrideUrlLoading().
During my activity I'm sending an intent to the browser in order to display a webpage :
Intent i = new Intent(Intent.ACTION_VIEW, Uri.parse("http://ww.mywebpage.com");
startActivity(i);
I need to make sure that before sending the intent the browser cache and history are cleared so that the page get loaded from server directly and not from phone.
So far I've found the 2 following but I'm not sure they are used correctly :
Browser.clearHistory(getContentResolver());
Browser.clearSearches(getContentResolver());
Also with that cache is not cleared.
Do you know how to do that ?
First, you are assuming there is only one Web browser for Android. You are mistaken, and will be increasingly mistaken over time. Steel, Dolphin, Opera, etc. are already in production for Android, and Mozilla's Fennec is coming along nicely. This solution will not help you with other browsers.
Second, if a browser is incorrectly caching your data, your problem is probably on the server (i.e., not sending proper cache control headers). I'd try to fix it there, so that it will behave properly across all browsers.
Third, wiping the user's entire history and searches, to satisfy your requirements, is rather unprofessional. How would you like some desktop app wiping out your desktop browser's history and searches?
Fourth, you cannot clear the browser's cache programmatically.
Yes... and if you must assert more control on the client side rather than fixing it at the server, you'll need to display the content with a webview inside your application where you have full control, rather than delegating to the browser (which is a separate application running under a separate user id and separate security context that you can't mess with).