>From the technical side, I suspect they intended to eventually do something like that. But on arm (for whatever reason) iptables incurred a -huge- performance impact, so it was shelved/skipped. (And while you could probably muck about with the API and restrict well-behaved apps, you couldn't restrict poorly-behaved ones without something system-level.)
On Mon, Nov 16, 2009 at 11:31 PM, nEx.Software <[email protected] > wrote: > I have always felt that there needs to be more granular permissions > for Internet usage. For example, with Google Analytics for Mobile... I > would like to see an "Analytics" variant of the Internet permission. > Or as you mentioned, if there is a phone home aspect, there could be > permission and associated URL listed in the manifest, so the user can > make that informed decision. I just find it hard to swallow that I > have to grant access to the entire Internet for something so narrow > and directed. Creating a public (trusted) intent would be a step in > the right direction... I think it would have to come from Google or be > a prominent open solution where users and developers could feel > comfortable that the information being passed through that app is > safe. > > On Nov 16, 9:16 pm, Jeremy Slade <[email protected]> wrote: > > Presumably all these apps are just 'phoning home' for tracking usage > > stats and such - nothing malicious (whether it's a good ideas is > > another question). Couldn't the same thing be done by an open intent > > that is called by all of these apps? Then the apps themselves don't > > need to request internet access. Internet access would be limited to > > that one (presumably trusted) intent. In the case of the intent not > > being available on the phone, apps would still need to have a fallback > > policy. > > > > On Nov 16, 2:17 pm, "nEx.Software" <[email protected]> > > wrote: > > > > > > > > > If I don't believe an application should require Internet, I don't > > > install it. I hope that there are others who do the same. To require > > > internet permissions (with the current generic internet permission) on > > > an app which really does not need it, such as aiFlashlight, gives me > > > reason to question the motives of that developer. I ask myself "Now, > > > why the heck would a flashlight app require internet permissions?" and > > > then move along to another app that does the same thing without > > > requiring those permissions. I usually recommend to others that they > > > do the same thing. Taking this route is, in my opinion, a band-aid, > > > not a solution. > > > > > On Nov 16, 2:09 pm, AlexK <[email protected]> wrote: > > > > > > Yes, INTERNET permission required. > > > > > > For example In our application we show activation dialog with > > > > description about activation process. > > > > In your cases can be done something different. > > > > > > On Nov 16, 8:16 pm, "nEx.Software" <[email protected]> > > > > wrote: > > > > > > > Of course, now you have to add Full Internet permission to every > app > > > > > and thus negate any usefulness of this permission for actual use. > > > > > As if this permission was not already useless enough in telling the > > > > > user what the app intended to do... > > > > > > > On Nov 16, 11:13 am, AlexK <[email protected]> wrote: > > > > > > > > Source code which you can integrate into own application for > checking > > > > > > black list. > > > > > > > > /** > > > > > > * Determines status of device's IMEI. > > > > > > * > > > > > > * @return -1 - imei status retrieval failed. 0 - Green status 1 > to 3 - > > > > > > Yellow > > > > > > * status 3 to 5 - Brown status above 5 - Red status > > > > > > */ > > > > > > public int getIMEIStatus() > > > > > > { > > > > > > // 1. Get device ID > > > > > > TelephonyManager manager = (TelephonyManager)getSystemService > > > > > > (Context.TELEPHONY_SERVICE); > > > > > > String sDeviceID = manager.getDeviceId(); > > > > > > // 2. Fetch for IMEI data. > > > > > > // Will look like > > > > > > // > http://www.artfulbits.com/android/antipiracycheck.ashx?IMEI=123456789... > > > > > > String url = " > http://www.artfulbits.com/android/antipiracycheck.ashx? > > > > > > IMEI=" > > > > > > + sDeviceID; > > > > > > // Server will return 200 if request post was successful. > > > > > > final int http_ok = 200; > > > > > > // Create new http client. > > > > > > HttpClient client = new DefaultHttpClient(); > > > > > > // Create new http post. > > > > > > HttpPost post = new HttpPost(url); > > > > > > // Cache http response. > > > > > > HttpResponse response = null; > > > > > > // Will return -1 unless server provides its own value. > > > > > > int imeiStatus = -1; > > > > > > try > > > > > > { > > > > > > // Executind post. > > > > > > response = client.execute(post); > > > > > > // Making sure we've received correct status code. > > > > > > if(response.getStatusLine().getStatusCode() == http_ok) > > > > > > { > > > > > > // Retrieving content stream. > > > > > > InputStream stream = response.getEntity().getContent(); > > > > > > // Decorating stream with Input stream reader > > > > > > InputStreamReader isr = new InputStreamReader(stream); > > > > > > // Decorating input stream reader with buffered stream > reader. > > > > > > BufferedReader reader = new BufferedReader(isr); > > > > > > // Reading imei status from stream. > > > > > > imeiStatus = Integer.parseInt(reader.readLine()); > > > > > > // Closing buffered reader will recursively close decorated > > > > > > input stream > > > > > > // reader and input stream. > > > > > > reader.close(); > > > > > > } > > > > > > } > > > > > > catch(Exception e) > > > > > > { > > > > > > e.printStackTrace(); > > > > > > } > > > > > > return imeiStatus; > > > > > > > > } > > > > > > > > On Nov 16, 7:57 pm, AlexK <[email protected]> wrote: > > > > > > > > > I just did publishing of the web service! > > > > > > > > > All details can be found here: > > > > > > > > >http://www.artfulbits.com/Android/antipiracy.aspx > > > > > > > > > In 5 minutes I'll update database by our latest catched pirate > phones. > > > > > > > > > On Nov 16, 2:19 pm, "[email protected]" > > > > > > > > > <[email protected]> wrote: > > > > > > > > +1 > > > > > > > > > > This keeps coming up but I am bumping because it shouldn't be > ignored > > > > > > > > by Google. > > > > > > > > > > Problem is people can buy and refund within 24 hours. So we > need a web > > > > > > > > service apps can call where we can send a device ID plus a > google > > > > > > > > checkout number which confirms a valid non-cancelled order. > If this > > > > > > > > web service could be centralised to check other app markets > too, we > > > > > > > > would all be laughing. > > > > > > > > > > Its not cost effective for a single dev to work out a > solution. A team > > > > > > > > of people should be driving this forwards where they can keep > an eye > > > > > > > > on what the pirates are doing and continue to improve the > system as > > > > > > > > the pirates continue to break it. > > > > > > > > > > So the question then becomes a monetary one. No one has the > motivation > > > > > > > > to build a system without a monetary incentive. So how about > all app > > > > > > > > devs who are interested in the scheme support the anti-piracy > > > > > > > > developers by paying a monthly subscription. Most app devs > would be > > > > > > > > happy to do so if they can claw back 100's of pirated copies > of their > > > > > > > > apps. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
