"There just wasn't enough time to do it." is the phrase which sank a thousand good projects.
I'm sure if you added up all the time spent implementing the current method, fixing the problems, segregating it's roll out to avoid rooted devices, and dealing with developer frustrations there would have been time if the right approach had been taken at the outset. JBQ, believe it or not I have a lot of respect for you and the other members of the Android team who've stayed on the lists and taken part in the tougher discussions, but my opinion of Google is rapidly diminishing. Al. Jean-Baptiste Queru wrote: > No doubt that using a DRM solution that is not based on > forward-locking is the right long-term approach. We know what it would > take to implement it. There just wasn't enough time to do it. > > JBQ > > On Thu, Feb 26, 2009 at 11:00 PM, Al Sutton <[email protected]> wrote: > >> JBQ, >> >> You can do both (after all apps on Windows, DOS, Linux, etc., etc., etc. >> have been doing this for years). >> >> The solution we offer at >> http://andappstore.com/AndroidPhoneApplications/licensing.jsp works >> irrespective of whether the 'phone is rooted, non-rooted, copied, spun >> dry, etc., etc., etc., because it does not prevent circulation of the >> apk but instead uses a DRM mechanism to ensure the user has obtained the >> rights to access features within an application. This is the "modern" >> way of doing things where the distribution media isn't protected, but >> the software requires a product key or similar to offer unhindered >> functionality. >> >> At the London Dev day last year I gave Mike Jennings an idea on creating >> "trusted" applications to alleviate the problem of "How does a user >> trust an app isn't malicious", and I got the impression that crypto was >> not a strong point of the team, so I'd be happy to go over how the >> AndAppStore licensing system works with one of more of you guys so that >> we can get a viable, working solution deployed. >> >> Al. >> >> Jean-Baptiste Queru wrote: >> >>> The problem is that you're fighting between two conflicting goals here: >>> >>> -the need to have a root-capable debuggable and custom-flashable >>> device like the ADP1 for application development. >>> >>> -the need to have a non-root-capable non-debuggable >>> non-custom-flashable device like a consumer device in order to >>> maintain forward-locking guarantees. >>> >>> Intuitively, it should be theoretically possible to implement a design >>> that can switch between the two modes with the proper guarantees (i.e. >>> wiping the relevant partitions clean when going from a >>> forward-locking-capable build to a non-forward-locking capable one). >>> That'd require resources, of course, which would then have to be >>> pulled from other tasks. >>> >>> That being said, from the point of view of application development, >>> you need to expect that the differences from one consumer device to >>> another (e.g. which apps are installed by each user) will be greater >>> than the differences between an ADP1 and consumer devices like the G1 >>> (ignoring for now the issues about 1.0 vs 1.1 on ADP1 that we're >>> working on). Worrying about the differences between e.g. one ADP1 and >>> one G1 seems to be ignoring the differences between the thousands of >>> G1s out there. >>> >>> JBQ >>> >>> On Thu, Feb 26, 2009 at 6:21 PM, Steve Barr <[email protected]> wrote: >>> >>> >>>>> On Thu, Feb 26, 2009 at 1:48 PM, vendor.net <[email protected]> wrote: >>>>> > JBQ, will ADP1 support copy-protected apps in the future? >>>>> >>>>> >>>> On 2/26/09, Jean-Baptiste Queru <[email protected]> wrote: >>>> >>>> >>>>> I'd say that the current design would make this hard, but I have no >>>>> visibility over what the future plans might be. >>>>> >>>>> >>>> I think a lot of us just want their Dev Phone to be as close as >>>> possible to a customer's phone so we can test and have confidence in >>>> our Java apps before putting them out on the Market. Should we go to >>>> Holiday and be done with it? It would be great if there was some >>>> official blessed "upgrade" that would let us have a customer-like >>>> phone. I'm willing to nuke whatever's currently on the my phone to >>>> get it to that point. >>>> >>>> Otherwise, perhaps some return/refund program should be put in place. >>>> >>>> Steve >>>> >>>> >>>> >>> >>> >>> >> -- >> >> * Written an Android App? - List it at http://andappstore.com/ * >> >> ====== >> Funky Android Limited is registered in England & Wales with the >> company number 6741909. The registered head office is Kemp House, >> 152-160 City Road, London, EC1V 2NX, UK. >> >> The views expressed in this email are those of the author and not >> necessarily those of Funky Android Limited, it's associates, or it's >> subsidiaries. >> >> >> > > > > -- * Written an Android App? - List it at http://andappstore.com/ * ====== Funky Android Limited is registered in England & Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
