Fix getNetworkOperator & WifiSsid types #116
Comments
|
XPrivacy does not revoke permissions, but feed applications with fake data, so no delays or crashes. |
|
Xprivacy does not create delay, but it make app misbehave(which is not the same as forced crash by permission revocation) due to what I've said above, even though fake data in right form are provided. The misbehave leads to the delay. If the statement "same API-blocking tricks" is not right, should I describe it as API hijacking? Then everyone is using this. The apps using binary injection has literally no less than 100 million users.The number is large even if only 1% of these devices are rooted, While you can hardly find a legally sold android phone with google apps in China. So I cannot quite agree with it, in fact these "make some applications unusable" apps are the most compatible ones: no rely on roms/android versions/system file modification/deoxed requirement, effectively same low chance to cause crashes as with PDroid/XPrivacy. |
|
Give me one example of an app that misbehaves with XPrivacy. |
|
Here is an example: 07-03 21:05:00.252: I/XPrivacy(12969): load package=com.baidu.BaiduMap uid=10086 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): <title>???--??????????</title> 07-03 21:05:07.239: I/System.out(12969): <style type="text/css"> 07-03 21:05:07.239: I/System.out(12969): body{margin:0;padding:0;font-size:14px;font-family:"????",Arial, Helvetica, sans-serif;} 07-03 21:05:07.239: I/System.out(12969): img,ul,li,form,h2,ol{border:0;padding:0;margin:0;list-style:none;} 07-03 21:05:07.239: I/System.out(12969): .cl{clear:both;height:0px;line-height:0px;font-size:0px;overflow:hidden;} 07-03 21:05:07.239: I/System.out(12969): input{vertical-align:middle;} 07-03 21:05:07.239: I/System.out(12969): a:link{color:#0033cc} 07-03 21:05:07.239: I/System.out(12969): a:visited{color:#800080;} 07-03 21:05:07.239: I/System.out(12969): a:hover{color:#800080;} 07-03 21:05:07.239: I/System.out(12969): a:actived{color:#800080;} 07-03 21:05:07.239: I/System.out(12969): #content{width:95%;align:center;margin:0 auto 0;} 07-03 21:05:07.239: I/System.out(12969): .logo{float:left;width:141px;margin:10px 0 0 0;} 07-03 21:05:07.239: I/System.out(12969): .title{float:right;width:;line-height:24px;background:#e5ecf9;margin:20px 0 0 0;padding-left:8px;} 07-03 21:05:07.239: I/System.out(12969): .title a{margin-left:320px;} 07-03 21:05:07.239: I/System.out(12969): .tip{font-size:18px;margin:25px 0 25px 5px;*margin:25px 0 25px 5px;} 07-03 21:05:07.239: I/System.out(12969): .reason{margin:25px 0 33px 5px;*margin:25px 0 30px 5px;} 07-03 21:05:07.239: I/System.out(12969): .reason li{line-height:24px;height:24px;} 07-03 21:05:07.239: I/System.out(12969): .searchbox{margin:0 0 40px 8px;*margin:0 0 40px 8px;} 07-03 21:05:07.239: I/System.out(12969): .help{margin:0 0 100px 5px;} 07-03 21:05:07.239: I/System.out(12969): .footer{margin:50px 0 20px 0;*margin:50px 0 20px 0;text-align:center;color:#666666;} 07-03 21:05:07.239: I/System.out(12969): .footer a{color:#666666;} 07-03 21:05:07.239: I/System.out(12969): </style> 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969):
07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): ????????????????治????! 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969):
07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): © 2013 Baidu ????????
07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): 07-03 21:05:07.239: I/System.out(12969): The startup itself takes 10 seconds.Here is another, though not quite laggy, where exceptions occurred. app: 07-03 21:10:23.747: I/XPrivacy/XTelephonyManager(5642): get me.imid.fuubo/getDeviceId phone=true 8 ms |
||||||
|
``07-03 21:05:11.713: I/XPrivacy/XTelephonyManager(13024): get com.baidu.BaiduMap/getNetworkOperator phone=true *
This is because WifiSsid is not a string like in Android 4.1. |
|
Thanks for your logcat, but as you can see it are not problems in the description, but bugs. |
|
The two issues in the logcat will be fixed in the next release. |
There is something about LBE. The LBE make its way by using binary injection that you see a .so library is loaded into app's process from the logcat. Thus it uses pretty the same API-blocking tricks as PDroid and XPrivacy. The instinct of dynamic code injection makes it less robust(Every major release receives much complaint on the unstableness/app failing).
However what Per App Settings Module does euqals to removing specific lines of "Android.permission.???????????" in the Manifest. The CM7's permission revocation submodule(not the incognito mode in CM10.1.1+), Luckypatcher app as well as Permission Denied app are effectively the same.
What's more, ALL the alternatives (made by Chinese firms) use the similar binary injection method, which doesn't require to modify "/system" partition, and meet best compatibility. In China, the abuse of permission is appalling.
For example, this weather app (made by the government Meteorological center):
http://www.coolapk.com/apk/com.pmsc.chinaweather
it is ABSURD to see following permissions in a weather app, but it is quite common in China(I guess the 3rd tracking SDK inside requires these permission):
android.permission.CALL_PHONE
android.permission.SEND_SMS
android.permission.RECEIVE_SMS
android.permission.WRITE_SMS
android.permission.READ_SMS
android.permission.READ_PHONE_STATE
android.permission.CHANGE_WIFI_STATE (in case you disable Wifi)
android.permission.WRITE_APN_SETTINGS
android.permission.GET_TASKS
android.permission.ACCESS_WIFI_STATE
android.permission.ACCESS_NETWORK_STATE
android.permission.READ_LOGS
The LBE and other Chinese alternatives cannot prevent apps from accessing getLastKnownLocation API.
(By saying above, I did have used all of the solutions above.)
Here are some LBE alternatives from Chinese developers:
https://play.google.com/store/apps/details?id=com.ijinshan.duba
https://play.google.com/store/apps/details?id=com.qihoo360.mobilesafe
https://play.google.com/store/apps/details?id=com.tencent.qqpimsecure
The most recent release of LBE:
http://www.wandoujia.com/apps/com.lbe.security
Although LBE is probably the first ever to make it possible to control permissions in Android, it shows that the function is currently not central of these apps, which is quite a pity for me(Sadly it suggests Chinese are generally NOT care about their privacy or at least not well educated on the issue).
Answer of the first question "Will XPrivacy make my device slower?" is actually true since XPrivacy/XPatch themselves has little cost to the system. However, the apps may misbehave since their developers have never thought of the fact that the granted permission in the manifest could ever be revoked.
Here is an example, the Opera browser app uses IMEI or something else as an argument to generate an reference tracking ID during the first startup of itself. If the API acquiring the IMEI is blocked, the app will go into a dead loop and refuse to continue, then the system asks you whether to force close the app as it does not response.
Most of the time, it is the apps themselves led to the slowness. I've seen the baidu maps app takes up to 10 seconds to deal with permission revocation by XPrivacy each time it starts.
The text was updated successfully, but these errors were encountered: