IssueTracker

WRITE_APN_SETTINGS was made signatureOrSystem in ICS, and is no longer available for use by third party applications.

why for the sudden change? many network operators are dependent on this feature in order to provision/configure android devices specially here in Norway. Does android support all networks and MVNO's now all over the world?

Where can we address this issue? or who is the right person to talk to?

This is not just a single developer. I am representing a company. I hope you can point me to the right direction who to talk with this issue. Thanks for the help.

WRITE_APN_SETTINGS was removed for security reasons.  There are no plans to revert this change.

If your company has a compatibility issue with Android, please feel to file a new bug detailing the exact problem you're facing and I will help get it to the right person.

Hi,
we have the same problem, a lot of operator ask them to configure remotely APN (in case of end-user modified them by error).

Do you know if we can do this operation with third party application signed by the manufacturer ? (we know that some api are accessible for manufacturer)

Regards

signatureOrSystem permissions are available to applications signed with the same key used to sign the device operating system.

Having said that, going back and changing something the user explicitly set (aka "end-user modified them") seems like a very rare problem. Changing it without their permission is obviously a security concern.

I fully understand google position, but as long s there is no API to mamange Mobile data as there is an API to manage WIFI, some developers were using APN renaming as a way to control mobile data usage.

What about a Mobile data (and 4G) control API?

since you already mentioned about key used to sign both the app and the device operating system can access signatureOrSystem permissions, can you tell us how this actually works? I assume this is the only possible way to write APN settings.

Is this key the same key used to sign all device operating system on a particular model that released to the public? Or is a key unique to each device?

How about if the app signed with device key were made available on the android market? Would the update process be the same? Will the signatureOrSystem permission not be affected if there are new permissions introduced?

How about if the app is bundled on the device operating system? What would be the advantage and disadvantage?

Kindly share the necessary information needed for obtaining signatureOrSystem permission I might be missing something.

Thanks, Looking forward for a response.

Re comment 7:

Android 4.0 (ICS) introduced a bandwidth management tool for users. Please see http://developer.android.com/sdk/android-4.0-highlights.html for details (see "Control over network data"). There is no programmatic API available today for third party applications to control bandwidth usage.

Re comment 8:

signatureOrSystem permissions are available to applications pre-installed on the system, or applications signed by the device manufacturer. Please see http://developer.android.com/guide/topics/manifest/permission-element.html#plevel for more details.

There is no one "master key" used to sign all device operating systems. Each manufacturer has their own signing key, and there's often different signing keys for different devices by the same manufacturer.

Applications signed by a manufacturer key would be updatable through market just like any other Android app. The app would only get access to the signatureOrSystem permission if it was installed on a properly signed device. The signatureOrSystem permission would NOT be granted if it was installed on a device where the signatures don't match. For example, a Google application signed with the Google signing key would NOT have systemOrSignature permissions on a Samsung signed operating system.

I understand there are some security issues with this permission, but I think this is not acceptable solution. It is widely used by 3th party applications which are very popular among users.

And I don't know what is so big about changing APN. As far as I know changing APN cannot costs user a money or something. Phone just won't connect.

Until now I did not heard about application taking advance of this permisson. Anyway it would be realy nice to have this permisson back. :(

Hi I just want to clarify your statement on Comment 9(Re comment 8):

"Applications signed by a manufacturer key would be updatable through market just like any other Android app."

This is not the scenario where the manufacturer will give us their key but instead we will give them our app and they sign it themselves and bundle it on the device operative system. How I understand about market updates is that keys used to sign the app must not conflict in order to upload the update.

Does this not affect the market update if the app in the device operative system is signed by manufacturer key and the same app published on the android market is signed by our own key?

Thanks.

This is bull, we should be able to set device APNS just as we previously were. GIVE ME AN EXAMPLE of when WRITE_APN settings was used in a case as a threat. I HAVE NOT found one example anywhere. This was a severely bad move on googles end and needs to be addressed, specially cases in witch we have unlocked devices running on prepaid or MVNO carriers. I want to know where I can submit this as an issue. The manufacture of the device will not sign third party apk's neither will they implant a way to modify the settings so that users with unlocked, reprogrammed devices may be able to use all there features.

"WRITE_APN_SETTINGS was removed for security reasons.  There are no plans to revert this change."

While I understand the security issues and the need to restrict silent access, not providing alternate options is extremely disappointing.

My app does not gratuitously mess with APNs to control bandwidth, its used to create the APN for the giffgaff service. It exists because giffgaff have been unable to automatically provision all Android phones, don't have their APN in the shipping APN list and a significant number of their users seem incapable of manually entering it correctly. I also fix a number of faults by removing other APNs Android incorrectly switches to.

I don't need the write permission back but I do need some alternative. I'm happy if that requires my users to explicitly confirm writing changes, they're running my app to change APN after all. It would be nice if I can do the same while deleting APNs but I can walk them through doing that manually if needed.

But I need some sort of workround because my current solution of hijacking the notification system to cut&paste every damn APN field just makes Android look like it was written by clowns.

This is Bullshit!!!  You guys have created a problem now that needs to be fixed.  I'm running straight talk and although they use various towers from various carriers, I cant get access to the apn that they want me to insert because you guys have hard coded this crap not to allow config from apps.  You guys are PATHETIC and had no truly valuable reason to not allow users to control rights to that section.

Fix this!

Unjustified restriction and abnormal compared to the context - very bad that is not provided any alternative solution (see the MDM of Apple or the BES of RIM) to handle the APN.
Severe damage to all companies that have already invested in the applications and software platform (especially for platforms of Mobile Device Management).
More over severe than in the initials ads of the version 4 was not mentioned nowhere this limitation. Were mentioned only "improvements".
We expect as soon as possible a real solution or workaround

I also have a problem with this new restriction.
Isn't the whole idea of being able to define multiple APNs, so that various applications can use the connections they need?
We use an internet APN and a private corporate APN. These can be setup on the phone by the user manually. The issue is: Our corporate apps/widgets can't now choose to use the correct connection.
Any company that uses Android and a private APN are going to have this problem. You can't expect users to go into settings to change the default connection every time they need to look at corporate apps/widgets.
Please provide a solution.

I also have this problem.
I need to change APNs directly, is it an unjustified bug!!!!
There are a way to configure APNs with OTA OMA (via sms for example)?

Please, solve it soon!!

Even our application which is dependent on the multiple apns provided by the operator is also broken with 4.0. This is severely restricting the flexibility for the operator to provide different plans.

please solve it soon

As others have said, this is BS. Taking away functionality like this is extremely high handed. If you truly believe this is a problem that needed solving, all you had to do is bring up a dialogue asking for confirmation. Now you have ruined the user experience for many users. Phones are supposed to get better (just got an SGS 3), not worse. Hope you're not turning into Apple, they always think they know best too.

We as a operator in the Netherlands use multiple IMSI's. We need to be able to write APN settings as changing the IMSI. Please fix this asap!!

GOOGLE .. we need this functionality back. You can not take it away and ignore the applications that work with it. My application needs to write APN settings. Doing that, ignoring applications that write APN settings, you are going to lose applications and consequently lose your clients.

I can not turn on/off my GPS, i can not write APN settings, i can not set my system clock, i am very curious to know what google are going to block in the next version.
I thought that new versions of Android would come with new functionalities, instead of remove the old features.

We are another multi-IMSI operetor in France, Belgium, Netherlands, Luxembourg and Switzerland (more countries coming soon!), it is really IMPORTANT to fix this as soon as possible, else our subscribers will not be able to use Android anymore!

In the US, we have prepaid carriers like MetroPCS and Cricket Communications that allow reprogrammed phones on their networks, however due to the restrictions placed on Android 4.x in removing WRITE_APN, many people are unable to use their phone's features such as MMS, 3/4G, and in some extreme cases apps that switch between APNs for corporate purposes.  While there is a workaround for root users, many end users that are unable to root cannot use something like this to switch between APNs and some networks will not accept built in APN settings (example Cricket Communications used a MNC of 016 under Gingerbread and older, but the MNC of a Verizon phone is 004. Even modifying build.prop many users running ICS cannot use their MMS and 3G.) Very bad move Google.

This "new functionality" prevent us to support google with buying new phones which use ICS, because we need in our apps switch between different private APN's...

Bad decision. Changing APN with five touch is really very annoying.

Our customers (Gov. and large enterprises) has their own private APN's with their operator in order to route all traffic through their own infrastructure before accessing the internet.
We provide the customers with an app that sets the correct apn for their setup.
With this change I cannot recommend our customers to choose a device with ICS due to the fact that the users will have to manually add their APN's which also will be a show-stopper from the customers side.

I just wonder why you removed this feature? What did you intend?

Android is becoming very annoying with all the restrictions for a supposedly 'open' platform. WTF, Google? Why not just prompt the user when he installs an app that uses 'unsafe' permissions? If he wants to go ahead, then he takes responsibility for any potential consequences. There are many legitimate reasons for wanting to change APN settings, or even put the device to sleep. Not all apps are for public consumption. Please treat us like adults and allow us to make our own decisions about what to allow in our apps. You are only going to limit the platform and do damage to its reputation by continuing down this draconian path.

I have a suggestion. The way i understand the situation is that Google are protecting the public from potentially harmful applications (this is just an assumption, feel free to correct me if i'm wrong) by not allowing programmatic access to certain 'dangerous' features like WRITE_APN_SETTINGS or DEVICE_POWER. Fair enough. On the other hand, there are developers and companies who would like access to these features for private or internal use (i.e. not for public consumption). The obvious solution is for Google to introduce a setting called PRIVATE_MODE or DEVELOPER_MODE or something similar which allows UNRESTRICTED access to ALL features, effectively bypassing the permissions system. Any app that has this setting will not be allowed to be published to the market, thus protecting the public. When such an app is installed (outside of the usual market mechanism), the user will be warned and told how dangerous it is when it first runs and will have to confirm that it is ok, failing which it will be automatically uninstalled or blocked. This gives developers or private users all the flexibility they need and still protects the public. What say you, Google?

I think actually Google should provide the phone operators a operator program , if registered to this program and providing the signatures to that program and the applications signed with that submitted signatures, can have that extended permission, which is in case WRITE_APN_SETTINGS which is really a part of the operator customizations.

I am OK, if Google sells a PRIVATE API key for accessing this type of operations. "Free" for usual developers, "Paid" for enterprise developers.

I'm working in an aplication to make stadistics in the service of a telecomunications company, one of the most important thing is that we have a lot of differnts APNs to make tests, and we need to change it automatically, but with this issue make the job is quite imposible.
There will be any solution in the nexts versions ?
By the moment I've to ask for new old phone.
(Sorry for my english )

From the looks of it Google doesn't care. They wont do anything unless a law suite comes about and maybe one should

[Comment deleted]

@ aliaga.c...

If you just need to setup test devices, install your app to /system/app and reboot. It should then gain the permission. Can probably be done on unrooted phones with adb.

...if it's meant to run on customer devices, you're screwed.

I'm about to say fuckall to the android as a platform.

Moving on to a new mobile system. Fuck you google. From me. A former fan and advocate of your products. Switching to BING you butt trumpet dunderfucking grubstain.

[Comment deleted]

It's good that Google is still checking this issue. Hope they can do something about this.

For some of those who don't know the danger of changing APN silently, in some places it may lead to additional charge from mobile network. But again, there are a thousand better ways to make it more secure other than simple remove the permission.

But anyway I'm all OK with that. Google is not what it's used to be - remember the "note in Reader" feature removed?

Reply comment 9:


Re comment 7:

Android 4.0 (ICS) introduced a bandwidth management tool for users. Please see http://developer.android.com/sdk/android-4.0-highlights.html for details (see "Control over network data"). There is no programmatic API available today for third party applications to control bandwidth usage.

This is still a very immature feature. You can disable background data for everything... except Android OS... which keeps consuming data. I think you're forgetting that not all consumers are public consumers, some are enterprises and as such, the needs are different. The APN switching feature was a good workaround for controlling "uncontrolled" data traffic. If you want to keep this permission private to the system, then ok, but you'll need something else to give enterprise environment applications more control.

Hi, guys!
I faced with same trouble.
Could you tell me, was solution found ?

Thank you.

This change is extremely inconvenient. Can you not find a way to allow developers to control the default APN while still maintaining security?

Perhaps a possible solution would be to change the permissions so only applications that are Device Administrators have access? This way end users are less likely to compromise their device settings to malicious applications and MDMs and administrators are happy that they'll have control over custom APNs again.

I'll second to comment #30. I do understand that most applications are consumer focused, but not all... It's not the first time I'm disappointed with Google removing some permission because this or that, forcing us to create workarounds for newer versions. Not everyone build consumer applications, and business users have different needs. There should be a permission like PRIVATE_APP or NON_MARKET_APP, to allow companies to build their own non-market listed applications, without all the restrictions expected on a more closed audience. Obviously, user would be prompted about the risk.

Will it be possible to engineer a APN cycle funcionality into the next Android version...ie. cycle users created APNs at preset intervals. Or better yet think about specifying different APNs for different apps such as exchange mail, gmail and even browser. I have 2 x APNs on my S3 (internet & corporate) and using the corporate to sync exchange mail/contacts as well as certain corporate apps and then internet for gmail and the rest.
It's mind boggling that Android will after providing a service just take it away without providing an alternative or even communication and reasons.

Appreciate your feedback,

GS

All Google need to do is grab the source to any of the superuser/supersu apks and repurpose it gate APN changes. Turn most likely uses into a one time user prompt.

But that's not the Google way. They say it's not broken so resign yourselves to it NEVER being fixed.

[Comment deleted]

Could someone please explain how the problem can be solved with a rooted device ?

Does signatureOrSystem mean that I could place my App to /system/app and then it should work ?

Yep, just put it in /system/app and reboot.

I've just started a new business in France - and am selling android phones -the phones are great - but now I am having to pull them all back because of the problem with the apn's - they can't get on the internet because there is no add apn button for Free.fr - you can't add the settings manually - because there is no add button.  You can't use apn back up and restore because of the 3rd party issues.  I'm sure there is probably some really nifty hack - but I'm a business woman trying to make a living - funny enough - some of the other phones are fine. I'm just at a loss - so many years of supporting Google - and now this.

As everyone can see from these comments, Google couldn't care less. This big has been here since Jan 2012.

They could easily fix it with an extra warning message when someone asks for WRITE_APN_SETTINGS, but google don't see the problem, so apparently neither should we.

Google have become flabby and arrogant, they are so rich it seems that they don't want or need your business. Sun was exactly like this, bugs on the bug parade for 7+ years.

Well let me tell you a store:
We start developing an application for a company that use a lot of phones (more then 500). The app is ready, we make an contract with the carrier so the offer us a good price for traffic on those phones but they limit the access to internet (we don't need it) and offer us access over 3G only to our server using a custom APN and now... we need to manually input APN for all 500+phones! Ar you fucking joking?

Why does not google offer the possibility to user for example to limit the access of the application? There are some cases (enterprise app) that need to be able to create APN, INSTALL and UNISTALL apps without user permission and so on!

[Comment deleted]

This is wonderful, by the way one of the services that you do not have the correct APNs settings in by default for is VIRGIN MOBILE.
Do you have any idea how much of my time I am wasting because you keep screwing with the poor consumer?

I know that I'm commenting more than a year after comment #6. However, I am working with many Tier 1 carriers and the APN change/restoration/fix use case is required in all of them. The APN modification as a response to a "do not connect" use case, accounting for about 40% of the calls to the call center.
It is my understanding that this functionality should not be system0

Is there any better development plateform ? im going to leave google... go to hell

Not even rooting the device? I have the very same problem as chitu.mi

It sucks to manually configure each device...

hello, I work in a few apps about 2 years and I want to try this method, anybody try this?

private static final String[] APN_PROJECTION = {
     Telephony.Carriers.TYPE,            // 0
     Telephony.Carriers.MMSC,            // 1
     Telephony.Carriers.MMSPROXY,        // 2
     Telephony.Carriers.MMSPORT          // 3
};
and this to get the info:

final Cursor apnCursor =SqliteWrapper.query(context, this.context.getContentResolver(), Uri.withAppendedPath(Carriers.CONTENT_URI, "current"), APN_PROJECTION, null, null, null);

The SQLiteWrapperClass is hidden (I found this class on the Internet).

import android.database.sqlite.SqliteWrapper;

THAT is NOT COOL! Honestly, why deny access to all the info when you could normalize the table and separate the passwords onto another table that could be marked as secure?!?!

ALL I WANT TO DO IS READ ACCESS TO APNs - NOT WRITE!

Whoever was the "genius" (and I really mean those quotes) behind this move needs to broaden his/her horizons for more adaptive technology, not everyone is a freaking rock requiring the same things. WTF?

This does NOT feel like a move going forwards but rather a move going backwards.

For those requiring more sensitive data (such as passwords) then you're SOL (shit out of luck), but don't deny the rest of us read values for our network operators!!

This is blasphemy and I don't agree with this dick move.

I understand that changing the APN is a serious thing. But instead of just limit it to 3rd party apps, you should show a warning message before giving the permission, like when you are using a VPN.

reading apn and writing apn settings should be separated. In our program we need to check if certain apn exists if not write apn. But since write apn require special permission we should at lease be able to:
1) Check if apn exist and warn user if necessary
2) open apn intent with pre entered info for user to save.
3) You can give me write apn functionality and warn user when program does that and require a clicking "ok" button.

Simply put you are destroying enterprise use cases where a special SIM card is inserted and and a special apn needs to be configured for device to connect internet or enterprise network.

Reconsider this please. Not every enterprise can sign device firmware for this..

Hello, to anyone watching this stream, I have raised a similar MultiIMSI issue that I have observed on Marshmallow (6.0), relating to data bearer not being set up when SIM card switches to second IMSI.
Have any of the Test Managers of networks using MultiIMSI solutions noticed anything similar?
My issue is https://code.google.com/p/android/issues/detail?id=222173
And if anyone wants to ask me about it directly, my e-mail is nigel.domaingue@gamma.co.uk