I want to make an application that does something in the background, and to control its behavior, I wanted to have a quick-settings tile.
I managed to get the toggle working just fine, but now I want to know if it is possible to have a 'drop down' menu for the user to be able to choose an option out of 3 possible options. (3 different modes for the 'on' state)
Something like the wifi and bluetooth tiles here, that have that little arrow
Is this a feature only for system apps, or is there a way to do it?
It seems from here that unfortunately third party apps cannot use this feature.
Quote:
Note: You’ll notice some of the system tiles have an additional UI that replaces the whole quick settings pane with a custom UI. Unfortunately, this isn’t available to third party tiles.
Related
I want to disable Bluetooth tile from the quick settings panel. I am using android 9 and I want to do it on a system app. So if there are some changes to be made in source, I would be happy to know it.
I have found many solutions telling how to add a new custom tile via TileService, but I need to disable tiles that are already present (like Bluetooth tile).
Note: I do not want the feature itself to be disabled, i.e. the user would be able to enable disable feature from the settings app itself. I just want to disable the qs tile.
Searched a bit on cs.android.com and this seems to be the relevant class.
frameworks/base/packages/SystemUI/src/com/android/systemui/qs/tiles/BluetoothTile.java
From there you can handle click ( or not handle it actually), or show a "disabled" icon etc.
If you want to "remove" it, then frameworks/base/packages/SystemUI/src/com/android/systemui/qs/tileimpl/QSFactoryImpl.java seems to be the class that adds them. It reads from Settings.Secure.QS_TILES
frameworks/base/packages/SystemUI/src/com/android/systemui/qs/tileimpl/QSFactoryImpl.java
yes, This file we can edit and remove unwanted tiles.
I'm developing an Android-/iOS-App with react-native.
I want to allow my customers to select between options upon clicking the "options menu hardware button" in Android (you know, the button usually at the bottom left of the android devices with 3 lines on top of each other, often triggering a menu in the app providing additional options).
Question: How can I listen to the options menu button click?
To clearify, I mean that button:
I know that the button does not exist under iOS and not under all Android phones and I will have to implement another solution for there, but that does not matter at the moment, as I want the button primarily to provide debugging functionality for my customers/testers (e.g. sending me the state of an erroneous screen).
Strangely, I did not find any resources on google regarding this problem, although I would assume wanting to use hardware buttons in react-native is a common task. Maybe I used the wrong search terms - if someone could link me to better terms describing this problem, I'm thankful as well :D.
Only thing I could find is the BackHandler for handling back-button-clicks.
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'd like to add a "hidden" or "developer only" menu option to my Android app for debugging purposes — basically I just want a menu option which, when selected, copies the apps database out to a file somewhere on the users disk.
Is there an easy way to achieve this? I'd prefer something that's hidden normally but can be enabled "out in the field", but something that requires a quick and easy compilation flag would be OK too.
In my knowledge there is no developer only option to do exclusive things in Android. You can derive your own i.e. - 10 time click on specific View, specific gesture on any activity. Its up to you!
Desktop apps have top level menus (File, Edit, Search, ..., Help).
Web apps have very similar thing, menu tabs (Logo, Questions, Tags, Users, Badges, ...).
However I cannot find equivalent of top level menu in Android framework. Assume that my app has 5 main activities. According to menu design guidelines options menu should contain actions related to current activity. So how an app should allow users to easily switch to one of five main activities.
It seems that different apps solve the problem in different ways. Some have a tab list at the top of the screen, some at the bottom. Even Google applications aren't consisted in that field. Google Listen has an options menu item called 'Listen Home', however Listen main activity has no that options menu item. Others have two icons in app luncher which start two different activities from one app.
I realize that due to small phone screens Android apps have to be designed in a slightly different way than web or desktop apps. But I have a feeling that the app top level menu topic was omitted in Android framework. And developers are on their own here. Or am I missing something?
Update: this is Google blueprint for a great app
Update2: this an example app of these patterns
Update3: GreenDroid library helps a lot implementing these patters in your apps. It seems that dashboard and action bar patterns are becoming quite popular.
You should take a look at this Google I/O session: http://www.google.com/events/io/2010/sessions/android-ui-design-patterns.html
They talk about the design patterns they used for the Twitter application and basically the type of concept you are asking about. Basically, your activity should have a top bar that gives the user specific tasks to do in the view or allows them to switch into another activity.
Google has not implemented anything like this into the actual SDK yet so you're sort of on your own in terms of implementing it but the main concept is given in the presentation. This is the direction that Google would like to see Android shift into though.
Hopefully this helps you out somewhat.
The file/edit menus of desktop apps have a very different purpose than the questions/tags etc. tabs at the top of this webpage.
The contents of the file/edit menu should be implemented as in the options menu that appears when you press the menu button. This is, as you noted, to save space on the smaller screens.
App navigation like the questions/tags etc could be implemented using a Tab Layout. You are right that apps vary in whether or not the tabs are on the top or bottom, but I don't think thats a huge deal. In my unscientific look through apps on my phone, the bottom seems to be more common. However, I think it might depend on your specific implementation which you decide.
A lot of apps don't require any sort of navigation like that, and can get away with just having a path forward or back via the back button. I think this is preferable for a lot of applications, but won't work in all cases.
I'm not sure what more you would want built into the framework.. It seems like you can accomplish any kind of navigation desired with the above options.
You can look at the source of the Google IO app
ioshed