When you normally want to add an AppWidget in Android there is a list where you need to pick one widget and it binds it to the home screen.
I'm trying to build an app which has its own appWidgetHost and specific App Widgets that I built for it.
I have two problems:
I would like to be able to automatically bind a widget to my AppWidgetsHost without the user picking from the list.
I want to make my own 'pick widgets list' and to load only widgets that I have created.
To make it simple; There is my app with my AppWidgets and I want full control in terms of binding a appWidget to the appWidgetHost etc.
3 people asked similar questions in Google forums:
Link 1
Link 2
Link 3
The only answer I found to be a possibility is in link number 2. Paraneet (one of the repliers) said that you can install the app under /system/app instead of /data/app because some security issue. but I'm not sure if it is a reliable solution for production, and I would like to know more about the pros and cons of doing this.
Thanks, Shai.
Unfortunatlly for you (and me), Paraneet is right.
binding appwidget is a sensitive action and thus, to avoid malware it requires the user's consent for the most part however if you install your app into the /system/data folder then you considered part of the OS and you are given a system permission which lets you decide to bind appwidget that you created without any user's involvement.
In Android O, its possible to pin app widget programmatically. Just watch at example here
Also check out Google official documentation
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.
I am trying to archive same thing as done in "hierarchyviewer" tool, which dumps the tree of Views present at any given moment on the device or emulator screen.
But i want it to be an Application running on a Android device. This app will keep running in background like a Serve and will dump the currently displayed Views in a text file.
Is it possible? is there any code examples are available?
Is it possible?
No.
The closest you can come is to implement an AccessibilityService. This would more closely mirror the uiautomatorviewer functionality, giving you a subset of what you see in Hierarchy View. This also requires a double-opt-in by the user: the user must install your app and activate it in Settings in the accessibility area.
As far as I know, you couldn't access other apps if they do not explicity share that info with you by the use of Intents (or if you own these other apps).
So, based on this limitation, my bets are you can't access another app's View Tree by regular means. And if you chould, I think you shouldn't, as this is somehow "secret" to other apps, and you'd be registering information without permission. In fact, what hierarchyview uses is, for sure, some sort of trick that directly uses internal private libraries of Android. Like taking a screenshot, that you can't do with the "default" implementation, but using these kind of testing tools.
That being said, check this answer, where it shows how to get the current app in foreground. From here, getting the View tree should be impossible, but as long as you could call getWindow() on that app's current activity, this could be done.
So I am using the Home sample to build an application that creates a second home screen for the user. The idea is to be able to have only one user account yet restrict certain access to chosen applications. I have managed to ensure that all of the applications are invisible in the XML yet I am struggling with how to change this to make certain apps visible.
Is it possible to write a whitelist of accepted apps for instance the preinstalled apps or child friendly apps for children who game using the android device and then put in a Java method to access this white list? This is the only way I can think to make it work.
If anyone knows the correct way can you please help.
Thanks.
Ok so I discovered how to do this.
In the home sample they provide a for loop in the Home.java file that covers all apps and displays them. It take a simple if statement to restrict the apps that can be viewed -
// for loop is here
if (info.activityInfo.applicationInfo.packageName.contains("com.android"))
//then the rest of the home sample is here.
Still very basic but provides me with a good enough UI so that kids cannot see apps I don't want them to.
I am developing an application that should be extendable
I want the user to install the base app and then extend it by installing extension packs (different APKs) or plug-ins (like go launcher and theme-packs or add-on widgets)
The only thing I could find is using library project to share the code but that doesn't fit my needs. Can someone explain how its done?
[edit]
To be more specific, here is what I want to do:
I have a set of animated scenes, effects and transitions
animated scene is a combination of code and resources
The user can select the 1st scene, 2nd scene etc..
I wish to be able to add more scenes but I don't want to include them all in one APK
I want to let the user download scenes of his choice.
To build this type of interaction, ContentProvider will be your friend. There are two options I can think of to build this type of system, depending on which direction you would like information to flow.
Option 1: Single ContentProvider in main application
Define a ContentProvider in your main application, which creates an external interface for other applications to read/write data to a common location. This provider maintains access to the scene data files/database your application needs.
Each subsequent plugin application accesses the main ContentProvider (and also warns the user if they run a plugin but haven't installed the main app yet) and installs its specific content by writing it to the ContentProvider. In this way, each plugin is designed to act as an "installer", meaning the user has to download and run the plugin from Market to install the scene content.
Option 2: Each "Plugin" application has its own ContentProvider
This option is the reverse of the above. Define a ContentProvider with a consistent interface in each plugin application and have a method from the main application that scans the system for new plugins (this can be done via PackageManager) and reads the data from each provider into its main local store.
The difference here is that the user won't have to run each plugin package, because the main application will take care of getting the data. However, there's more complexity in defining multiple providers. For instance, you have to make sure that, even if each provider has the same basic interface, they cannot have a single common authority, so you will have to scan the system for package names like your own and resolve the providers based on that information.
Editorial
Having said that, I feel I should mention that I don't believe this is a good method of providing content to your users. My personal feeling on the subject is this method pollutes the user's devices with application icons that do them no good, and it's difficult to hide that kind of thing on the mobile device. A simpler, and much cleaner approach to this would be to store your "add-on" content on a server (AWS services like S3 and SimpleDB are practically free) and use a service like Google's In-App Billing to let your users purchase the new content and download it directly into the single application rather than having them go back to Market and purchase more apps.
Hope that Helps!
I have a set of animated scenes, effects and transitions animated scene is a combination of code and resources The user can select the 1st scene, 2nd scene etc..
If the "animated scenes" are activities. your add-on APKs simply publish their own sets of activities, and you use PackageManager to determine which of your plugins are installed and how to use them.
I have an Android application does many things. I would like to be able have it spawn a desktop widget (?) that opens the application to do a specific thing when the widget is clicked.
Can someone give me a road map on how to do this?
As far as i know, Android applications can not add App Widgets to the home screen. Applications can define App Widgets, but user has to add them manually to the home screen.
However it is not hard to launch Activitys from a widget using PendingIntent.
This is called AppWidget and is described in details in Android documentation (both references and step-by-step guide). Note, that it's the user that adds the widget to his launcher screen. AFAIK there's no way to add it to launcher in code (though HTC might have some undocumented ways).