I am just wondering how to enable/disable 3G/2G using the Android SDK and not just intenting to the 3G settings page. Thanks. Also is there a way to do the same thing, but with GPS. Thanks!
There is no exported to the SDK functionality to switch between 2G and 3G. For a given device you could probably figure out the private functionality, but it wouldn't work unless the app was signed with the system key.
You can disable the radios though, by turning on airplane mode.
And you might be able to make a shortcut to open the appropriate settings activity directly, instead of going through a few levels of menus to get there.
If you make your own build, you can presumably add the capability you really want, but that's likely not useful to anyone but yourself.
Edit: further detail - to understand how it works, look at the settings menu code (default version, a given device will differ):
http://android.git.kernel.org/?p=platform/packages/apps/Phone.git;a=blob;f=src/com/android/phone/Settings.java;hb=HEAD
Edit: AOSP is no longer served from kernel.org. A browsable mirror of
the current phone repository is at
https://github.com/android/platform_packages_apps_phone however due to
evolution of code organization there is no longer a Settings.java
there. One might either use git to reconstruct the version above from
this repository, or else try to figure out where the code has migrated
to in current releases.
You would need to find out the implementation specific set of NT_MODE_ constants you wish to toggle between. And you need to be able to write to secure settings, which requires being signed with the system key. Unless it's a custom build, you probably don't have access to that.
You cannot enable or disable any of these from an SDK application.
Related
I am hoping to implement some security for an Android app to prevent people from using the code unless it was installed on the correct device by the company. My first choice would be to make sure the app was installed through the Google Play Store, but this app will not be available there.
I have determined that one security measure that will work for my use case is checking some of the information in the Build class. I am concerned that there could be the possibility that some of the fields in the class may not stay the same, even if the same model of device is always used.
What portions of the Build class are subject to change for a specific model of device and what fields should never change?
In the end all of these system configs are just .xml files residing on the device somewhere around /data/system/sysconfig which you can modify in any way you want if you have write access (aka root) so I would recommend starting from making sure that the user running your app does not have root privileges. There are some FOSS libraries for it, you can start from there.
I'm toying with a very simple app that just adds a quick settings tile using Cyanogenmod CustomTile API.
Everything works (my app's code closely resembles the CM SDK sample app), except for a single scenario. The problem is, once I've manually removed the tile I can't find any way to add it back.
I've tapped "edit tiles" and deleted my app's tile. Now calls to CMStatusBarManager.publishTile don't seem to have any effect (I've surely tried to restart the app) and the only tiles listed for manual addition are the system ones. Uninstalling the app and re-installing it works, but I want to handle this scenario in somewhat more user-friendly fashion.
It would be best if I only could register the tile to be listed along the system ones in "edit tiles" mode, but I guess there's no API for this at the moment. Another acceptable solution is a way to re-add the tile (I'll just show a warning that tile was removed and a button to re-add it).
The question is specifically about CyanogenMod 12.1 and 13. Right now I don't care about any upcoming Android N stuff — I just want to make a user-level application specifically for CM-based ROMs of a certain phone have a feature and be on par with stock ROM.
It seems to me that there is a lot of confusing resources regarding the proxy topic on Android.
First of all, it seems that all the methods of the Proxy class are declared deprecated and it's suggested to:
"Use standard java vm proxy values to find the host, port and
exclusion list. This call ignores the exclusion list."
The official java vm proxy values can be accessed in the following way:
System.getProperty("http.proxyHost")
System.getProperty("http.proxyPort")
System.getProperty("http.nonProxyHosts")
This could seem confirmed by the documentation of the ProxySelector class.
But trying on a real device or an emulator, these values seems to me always empty. After looking to the Android source code of the hidden ProxySelector activity, it seems that the proxy is saved into the secure settings of the system in the following way:
Settings.Secure.putString(res, Settings.Secure.HTTP_PROXY, hostname);
And only an application signed by the OS provider can write to the secure settings. Developers can access these settings only in read mode in the following way:
Settings.Secure.getString(getApplicationContext().getContentResolver(),Settings.Secure.HTTP_PROXY);
Someone can clarify if this is the correct reading of how can be access the proxy settings into Android? (At least it seems to work). If this is the correct intepretation, why the documentation is so full of errors?
For getting proxy values, accessing the System properties as you have done should work; it should not be necessary to access secure settings. If you cannot use the System properties to read proxy settings that were made through the normal device UI, then there is a problem. Proxies are per network type, so the APN and WiFi will have separate proxy settings.
I don't know if it's the "right" way to access the proxy settings but it's the right and only way you should access the system "secure settings".
Maybe this is also interesting, looks like it makes things easier, especially if there are Wifi proxys (does Android support something like this?). At least it looks like great abstraction for the various android versions.
I am currently working with AOSP Gingerbread and have built a customized rom for Nexus One which excludes WiFi and Camera.
However, WiFi can still be seen in the settings menu.
How do I remove it from the settings layout?
P.S. I want the rom to be 100% free of any modules, drivers or libraries from those two.
I had commented out USE_CAMERA_STUB := false from BoardConfigVendor.mk and replaced all WiFi related defines with BOARD_HAVE_WIFI := false in BoardConfigCommon.mk before compiling.
Is this modification correct or is there a better way to do it?
Thanks.
Ok, I just commented out wifi and wifi settings from wireless_setting.xml and wireless_setting.java to remove them from the settings layout.
If you remove the appropriate drivers then the hardware just wont work.
The next thing is to do is check and decompile your android framework.apk which is situated in the folder "framework" under "system".
So in hierarchy it would be system/framework/framework-res.apk
In this framework you have to both delete the java and xml queries towards the appropriate function, so i.e. wifi.xml and the framework.jar!
Only this is the appropriate way to get rid of those functions for once and for all.
i m new in android i want to create application that gives option for create new profile (like meeting,outdore etc),manage profile(not location base it's manually)
plz help me
If I understand you correctly, you want to quickly switch between several profiles that change certain settings like Wifi On/Off, mutes all sounds, etc. right?
If that's what you want then your best bet would be to not re-invent the wheel and - depending on what phone you have - to install a custom ROM like CyanogenMOD which already features profile management. This would void your warranty though.
Otherwise, you could possibly achieve this with either an Xposed module (will most likely only work if you have a Nexus device, since it requires a pure "AOSP" version of Android and Root permissions) or the app "Tasker" which also requires Root access.