I know it is possible to clear all Preferred Activities for my Package using
getPackageManager().clearPackagePreferredActivities(getPackageName());
But is it posible only to clear a specific one? For example clear the Intent.CATEGORY_HOME but still keep the default for lets say android.media.action.IMAGE_CAPTURE?
I am talking newer devices HoneyComb and above.
I have tried to change the package name for the Image_Capture Activity but to no effect (makes sense since the User can reset the Preferred Activites per App not per Package, so the clearPackagePreferredActivities works just as that button).
If this is the only possibility to clear the defaults, than I would need to make two apks - one for the Home-App and one for the Photo-App to get the desired effect.
(Note that the photo-app does really nothing but is designed to bar the user from using camera as part of blocking of my Kiosk-App).
Related
I want to create an accessibility feature for Android where a hint appears whenever a person presses or long-presses on an app icon. To do, this I have a few questions:
How to identify when a user clicks on the icon of an app on the
homescreen or app launcher?
How to make use of this event to then
pull appropriate information and present it to the user?
Do I need to develop a custom launcher app to be able to identify user presses etc.? Or can I somehow retrieve this information from whatever launcher a user uses and give the hint?
There are a couple of different ways to get after the information you are looking for.
The first option is to create a custom launcher, as you suggested. This has obvious drawbacks. Most obviously, having to re-create an entire launcher applications is obviously difficult, and likely to create more issues than fixes. You could search out an open source launcher application, and attempt to add your feature to this, however you'd then be reliant on the purveyors of this codebase to accept your feature.
The second, and the way I'd recommend, to access this information is through accessibility services. This information is available to services like TalkBack. It is essential to how they function. The difficulties you'll face here are interacting properly with the numerous launchers available out there. However, most of these launchers are based off of a similar starting point, which is the Android base open source launcher. As such, the portions of the launcher that you care to interact with should be coded very similarly in most launcher examples.
The downside to this approach is that only one accessibility service can be active on a device at a time. So, users who are partially blind, who may want to use your feature and TalkBack at the same time, won't be able to. It is of course to you to determine which set of difficulties/benefits you'd prefer to deal with, but these are your options.
If we look at one activity as a graph node, transition/calling from one activity to another as a graph edge, one android app can be conceptually converted into a graph. I am trying to see if there is any way to create such a graph starting from the first page/activity of an app.
Let us say we can use android UI test automator to help if needed.
I am trying to see if there is any way to create such a graph starting from the first page/activity of an app.
It would be exceptionally difficult.
I am assuming that you are trying to hack... er, I mean, "analyze"... somebody else's app. In that case:
You have no idea how many activities there are, unless you are reverse-engineering the APK. And even then, you have no idea how those activities will be used (e.g., legacy app that is putting activities in tabs and not using them as an ordinary activity).
You have no way to know what triggers the activities to appear. For example, a certain activity might only appear via an "Easter egg"-style bizarre set of inputs. Some might be triggered by things outside the app itself, like a Notification or a third-party invocation of ACTION_VIEW for some MIME type the app supports. And some of the triggers may be dependent upon other inputs (e.g., a disabled action bar item that becomes enabled only if you have set up an account elsewhere in the app).
With full source code, you could do static analysis to find all startActivity() and startActivityForResult() calls, and for simple variations you might be able to divine which activity starts which. Even that could get tricky in some cases, for complex Intent construction.
I am relatively new to android and want to create an application that permanently overrides androids basic softkey behaviour and view (for devices with soft keys).
Some functionalities I want to implement are changing the size of the softkeys window at the bottom, change its images, and possibly change its functionality.
For example, the user can set the size to of the softkey to be "large", "medium" or "small". And I can change the functionality of the back button to open say a particular application instead of going "back".
I'm basically looking for a high level answer as to how to do this, a basic direction of what I should read/study in order to be able to accomplish this. I realise this may require root access.
Please note that I want this behaviour to change not only in my application but I want the effect to exist on all applications. If this requires the application to be running atleast at the backend, that is fine.
After doing some decent amount of search, it seems I will have to make changes in the systemUI.apk, or possibly get its source code and modify it. Is this correct?
Thanks in advance.
I don't think even root is going to be enough for the type of changes you are describing. You're going to need to edit the Android source code and build your own system image.
Well you can't override system resources because they are part of the system image.
What you are looking for is called Home Application which can be developed like any other android app no need for root , you can find an example for it in your sdk samples.
Home Sample Application.
your app would be responsible to have UI components to send the user to all of the phone functionalities which includes:
Place for wegits
Place for apps listing (menue)
Access telephony functionality (call, phone history ...)
Access settings.
I need general advice.
I'm building an app that can be started via the icon (normal way) but also with an intent triggered by a click in the notification area (the app places an icon in the notification area). The is awaken when a time event / alarm occurs.
The app has 5 to 10 views. Is it better to open a new activity for each view? How can I be sure not to have mutliple tasks open? Say if my app is Activity-A, Activity-B, Activity-C and can be started from Activity-A and Activity-B (depending on if it's opened via the icon or the notification area) ... how do I clean everything upon app close?
Or is it better to have one activity and just switch views (xml layouts)?
I'll start of with what you should watch and read. It should be clear that navigation in Android is very easy to do wrong. Google has a history of doing differently from app to app, but they are getting better. This said, if you are to do an app you should know how it is intended to work, and the best way to do that is to read the docs. As mentioned, there was an excellent talk at IO'12. There is also a very good section on the design site, and finally there is a good section in the API Guides.
To summarize: a full screen is an activity (which in turn can be constructed of fragments). The activities should in virtually all cases be structured as a tree with the root being the activity that are launched from home. For every activity you should have an "up" activity that takes you up in the hierarchy. Note that this is different from back which should take you to the last full screen state you were in. Also note that full screen means that for example tabs should not be recorded in the "back history", since they provide navigation within a screen.
When it comes to tapping a notification it should be equivalent to: pressing home, remove the task from the recents view (clearing the task), opening the task, and finally take the shortest path to get to the activity presenting the info that the notification told you about. Complicated, yes indeed... But at least there is a helper class in JB and in the support library called TaskStackBuilder.
The key to all this is a UI design that follow the Android design guidelines. Take your time to make the design for your app, and make sure to separate up (static) and back (temporal).
It might be as simple as using a different launchmode, which you can define in the manifest or I think in the inent you are using. It takes some experimenting but SingleTask or SingleInstance may be the right choices for you,
Your activity should support onNewIntent in this case, to reuse existing Activities if that is the desired effect.
In this case I better use one activity or use fragments.
I am creating an Android application for a customer which will be pre-installed and distributed together with the handsets. Now the customer asked me to lock down the ROM to prevent the future users from using anything else apart from this one app. I.e. no browsing, no email, nothing which could create any costs etc.
Now after some googling it seems to be relatively straightforward to remove applications from an Android image. But even if I can remove the web browser, email client, the Android Market App etc, how can I make sure that the user will not reinstall those apps via the USB connector? As Android is just Linux I am sure there are ways of denying all users the right to install new applications (or actually denying them pretty much anything apart from using this one app).
If somebody could point me in the right direction it would be much appreciated.
EDIT:
To clarify things a bit, the customer does not want to use the android devices as phones, even though they are phones. With 100€ touch screen phones becoming available, it becomes viable to use those phones for just one specific purpose. In my customers case, the device will be used as something like a POS system: the employee uses the phone to process a certain kind of customer request, and for this the app needs to have a data connection which will accrue costs of course. Now obviously contracts can be set up that will oblige employees to pay any irregular costs themselves, but why make it that complicated?
This is not about taking freedom away from users but rather about using android phones as general purpose touch screen devices with a data connection that employees can use in a business environment without shooting themselves in the foot with unexpected high data connection cost.
There's not really a whole lot you need to do to make a single-purpose device. If you play your cards right, it should be something you can do without having to tinker with the ROM.
The quick-and-easy route would be to deploy your application as a replacement for the stock launcher, just like any of the other home replacements that are available. Setting that as the default would cover most of the opportunities for casual tampering, since it would leave no other way to launch or install anything else. The only other things I can think of off the top of my head that you'd need to do are snag the search button so it doesn't bring up the default Android search box atop your app and the green key so the phone app won't come up.
You would, of course, need a way to get to the original launcher to maintain the device and install new versions of your app. I'd accomplish that using a "Maintenance" menu item somewhere that asks for some form of authentication (e.g., a password), changes the home app back to the original and launches it. When you're done doing what you need to do, set your app as the default launcher and you're back in business.
Edit to address MAINERROR (now Octavian Damiean)'s comment:
Any activity in any application can register itself as a home application by adding an intent filter on the android.intent.category.HOME category. It's literally four lines in the manifest, and you don't have to write any code to support it. Take a look at lines 77-82 in the stock launcher's manifest for an example of how this is done. (Ignore the filters on DEFAULT and MONKEY; they're not necessary.) Once the activity is selected as the default handler for the category, it becomes the first thing launched at boot and what comes up when the Home key is pressed. HTC Sense, aHome, Panda Home, etc. all use this mechanism.
Launching the stock home (or any other application) explicitly is about five lines of code.
Side note: There's a application on the Market called Home Switcher that lets you launch any of the activities filtering on the HOME category or set one as the default.
Unless the handset manufacturer adds a lot of shovelware, the stuff that runs in the background should be inconsequential and won't get in the way.
There was a similar question already somewhere. You can indeed limit the functionality of your device by the amount you want or have to. In order to achieve this you will definitely have to build your own modified ROM.
You will have to touch the ROM because you will have to get rid of several applications running in the background. One you won't need them anyway and two as you don't need them they would only consume resources.
You might want to take a look at http://source.android.com there you will find more information about the sources which will hopefully direct you where you need.
Blrfl's answer is great, but it still has a problem: if the user long presses the HOME button, the recent applications popup will appear an the user will be able to launch another app.