Re: CDMA devices in AOSP: technical details

[Jean-Baptiste Queru]

Everything that ever was available still is, and nobody is stopping you from continuing to do exactly what you were doing.

JBQ

On Tuesday, February 7, 2012, Ashwin Gururaghavendran <ash25...@gmail.com> wrote:
> I have a LTE Xoom and a CDMA/LTE Galaxy Nexus - all of which I
> purchased for developing custom ROMs and other system modifications
> that I can redistribute. But now it looks like it would be tough for
> even myself to build and get such a fully working custom ROM.
>
> The amount we pay for these devloper devices is substantial - and I'm
> sure Google would have had this foresight/information about such
> problems way ahead. The appropriate thing from Google's side for us
> developers would have to give few warnings about such grey areas (at
> least for the Verizon Galaxy Nexus) before the phone was available for
> sale on the retail market.
>
>
> On Wed, Feb 8, 2012 at 6:06 AM, Jean-Baptiste Queru <j...@android.com> wrote:
>> I got additional information, which will make things harder:
>>
>> Apks on retail images are run through dexopt at build time, replacing
>> the dex section with an odex file. The resulting odex files are
>> optimized globally along library dependencies. An apk that's been run
>> through dexopt can only run against the exact libraries that were used
>> in the same dexopt phase.
>>
>> What that really means is that even if we managed to get the package
>> manager to recognize those apks as having the platform signature (one
>> way or another), we still wouldn't be able to execute the code in
>> question, as that code is only executable in the context of the system
>> it was original built as a part of.
>>
>> That's exactly the kind of difficulty that we keep bumping into when
>> we don't have the appropriate licenses, especially for apks.
>>
>> JBQ
>>
>> On Mon, Feb 6, 2012 at 3:34 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>>> It's theoretically possible, but bumps into two aspects:
>>>
>>> -It requires to modify an extremely sensitive part of the package
>>> manager, for a use case that's not relevant for retail devices, so the
>>> risk-reward balance is heavily stacked against AOSP. At the very least
>>> you'll want that behavior to be off by default, with a mechanism to
>>> turn it on that would only be enabled in custom AOSP builds.
>>>
>>> -It requires to generate those signatures without copying the files,
>>> i.e. they'd need to be generated on-device, with a usage pattern that
>>> isn't the normal usage pattern for those files.
>>>
>>> I agree that with those two aspects we'd be potentially one step
>>> closer toward being able to do http://goo.gl/8jit8 on some CDMA
>>> devices.
>>>
>>> JBQ
>>>
>>> On Mon, Feb 6, 2012 at 3:23 PM, Ievgenii Nazaruk
>>> <ievgenii...@gmail.com> wrote:
>>>> As an option AOSP could start supporting external signature files.
>>>> For example an external .zip archive with all the META-INF folder
>>>> content:
>>>>
>>>> some-app.apk
>>>> some-app.sig <- external signature, exact copy of META-INF folder
>>>>
>>>> This external signature should have priority over the internal one for
>>>> this
>>>> mechanism to work. Some modifications should be done to the
>>>> package manager of course. But that's not impossible.
>>>>
>>>> On Feb 6, 11:22 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>>>>> You may have heard about a change in AOSP support for 3 CDMA devices:
>>>>> Nexus S 4G (Sprint), Motorola Xoom (Verizon Wireless), and Galaxy
>>>>> Nexus (Verizon Wireless). A high-level view is
>>>>> provided here:https://groups.google.com/group/android-contrib/browse_thread/thread/...
>>>>>
>>>>> Here is a look at the practical technical differences between GSM and
>>>>> CDMA, as relevant to these devices.
>>>>>
>>>>> In order to properly support a given device in AOSP, the relevant
>>>>> proprietary binaries need to be available. For Nexus devices, we make
>>>>> as many of these as possible available throughhttps://code.google.com/android/nexus/drivers.html, which requires an
>>>>> appropriate license agreement between Google and the owners of those
>>>>> binaries. For GSM (and HSPA) devices, getting these license agreements
>>>>> is relatively easy; however, since there are many more intellectual
>>>>> property holders in the CDMA world, it is much more difficult to get
>>>>> the appropriate rights.
>>>>>
>>>>> On a technical level, in the GSM world the proprietary binaries that
>>>>> are necessary to communicate with the cell network are typ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.

[adam darst]

Let me ask you a very base and frank question, how is it possible
google was blind sided by something you claim to be so.obvious??? Are
you that ignorant as a major player?

On Feb 6, 4:22 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> You may have heard about a change in AOSP support for 3 CDMA devices:
> Nexus S 4G (Sprint), Motorola Xoom (Verizon Wireless), and Galaxy
> Nexus (Verizon Wireless). A high-level view is
> provided here:https://groups.google.com/group/android-contrib/browse_thread/thread/...
>
> Here is a look at the practical technical differences between GSM and
> CDMA, as relevant to these devices.
>
> In order to properly support a given device in AOSP, the relevant
> proprietary binaries need to be available. For Nexus devices, we make
> as many of these as possible available throughhttps://code.google.com/android/nexus/drivers.html, which requires an
> appropriate license agreement between Google and the owners of those
> binaries. For GSM (and HSPA) devices, getting these license agreements
> is relatively easy; however, since there are many more intellectual
> property holders in the CDMA world, it is much more difficult to get
> the appropriate rights.
>
> On a technical level, in the GSM world the proprietary binaries that

> are necessary to communicate with the cell network are typically a
> very small number of C libraries that can be used directly on all
> build configurations without any modifications. In the CDMA world,
> parts of the network stack are implemented as apks, which are
> protected by cryptographic signatures, and the network stack must use
> the same signature as the rest of the system (to guarantee that it
> can't be replaced in a way that'd allow the network traffic to be
> intercepted). Since the system signature varies from one build
> configuration to the next, those apks need to be modified to match
> each build. In turn, that requires licenses that allow making
> modifications to those files, and Google hasn't been able to obtain
> such a license so far. Similarly, the build process for consumer
> builds involves a step called "dexpreopt" that modifies all the apks
> on the system, and running that step also requires licenses that allow
> making modifications to the proprietary binaries, so doing it on a
> CDMA device requires additional licence terms that aren't necessary
> for GSM devices.
>
> Even if the licensing issues were resolved, there'd still be some
> hurdles that'd prevent CDMA devices from working as well as GSM ones
> in AOSP. As an example, performing a factory reset on Xoom (which is
> necessary to work around a bootloader bug) deletes the network
> configuration for Verizon Wireless, and that network configuration
> can't be restored in AOSP builds as it is tied to the initial sign-up
> flow, which isn't the same for AOSP builds and retail builds.
>
> Now, here's how things are likely to look in the future for those CDMA devices:
>
> - Most likely, the relevant source files will continue being in the
> Android source tree.
> - Quite likely, it will be possible to actually compile that code.
> - We plan to continue to distribute factory images for Galaxy Nexus
> and proprietary binaries for all relevant devices, where we can.
> - There won't be any testing done on AOSP builds for those CDMA
> devices, so they'll probably bit-rot.
> - CDMA devices won't be targeted by improvements in the way AOSP
> builds can be installed or distributed.
>
> JBQ

[Jean-Baptiste Queru]

I'd been told that there wouldn't be any license issues, and I did all the ICS AOSP preparation work and testing based on that. Once there turned out to be license issues after all, after all the technical work had been done, I turned to investigating technical workarounds for the lack of licenses. That's when I started to bump into those CDMA-specific issues. Those issues mean that without the appropriate licenses the CDMA devices in AOSP are stuck in their current state, which is clearly not good enough to be realistically considered "supported".

JBQ

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Skynet11]

I'm not going to bother re-hashing what Google should have seen coming
and what Google should have done, because that's been covered already.
Therefore, I will simply ask: Is there any possibility that sometime
in the future Google might be able to secure the licenses it needs to
support CDMA devices in AOSP? It seems to me that Google should do
whatever it takes to honor its word that the Galaxy Nexus toro would
be a developer phone. It sounds like some of these IP owners are
putting the screws to Google and we're the ones who are caught in the
crossfire. Is this a correct assessment? Is there any hope that this
issue might eventually be resolved? Thanks in advance...

[Jesse Godsey]

I really do not see this happening you guys.  Everything I am reading is telling me it is already a done deal.  Google does not and will not any longer support CDMA devices directly.  And even firmware updates only if the carriers proprietary radio files, etc. will work with Google's updated source.

The writing is on the wall, Google is no longer directly supporting cdma for Aosp building as well as not providing CDMA devices Ota updates, that will come now directly from Verizon.  Verizon will nor carry another Nexus ever is my prediction.  Game over.

On Feb 8, 2012 9:18 AM, "Skynet11" <jmcin...@gmail.com> wrote:

Is there any possibility that Google might be able to secure the

licenses it needs to support CDMA devices in AOSP? It seems to me that
Google should do whatever it takes to honor its word that the Galaxy
Nexus toro would be a developer phone. It sounds like some of these IP
owners are putting the screws to Google and we're the ones who are
caught in the crossfire.

[Skynet11]

So what happened between Gingerbread and ICS so that this issue is
just now coming up?

[Jesse Godsey]

I do not know man. I think it is political

On Feb 8, 2012 10:22 AM, "Skynet11" <jmcin...@gmail.com> wrote:

So what happened between Gingerbread and ICS so that this issue is
just now coming up?

[gnarlyc]

I wonder who we can complain to? (Qualcomm?) Maybe several screaming
end users will make a difference? Probably not, but I'll be glad to
scream a little.

On Feb 8, 10:48 am, Jesse Godsey <jessegod...@gmail.com> wrote:
> I do not know man. I think it is political

[Skynet11]

Hey, customer outcry has worked before ;)

[Jesse Godsey]

I am with you all.

On Feb 8, 2012 6:15 PM, "Skynet11" <jmcin...@gmail.com> wrote:

Hey, customer outcry has worked before ;)

[Kenneth Crudup]

On Feb 6, 2:34 pm, Jean-Baptiste Queru <j...@android.com> wrote:

> That was definitely the original plan, but sometimes even the best plans bump into difficulties.

I'm sure JBQ can't comment on why (and FFS people, why are y'all
yelling at HIM over this?!) but my gut tells me this means either/all
of:

- VZ wants to stem changes on these platforms, probably to prevent
rooted/modified/customized devices from circumventing features the
carrier would rather omit or charge extra for

- VZ has run into support/maintenance/replacement issues with modified
devices

- VZ is just being VZ (and I'm sure Sprint is, if to a lesser extent,
too) and just being their normal, customer-adverse selves

"Follow the money"; it's usually an excellent way to identify the root
cause of issues like these.

[Jesse Godsey]

This is all obvious, but more to it than that.  Google also committed to supporting our phones which is why many of us have purchased them. 

Google and Verizon have had some disagreements and some back and forth about certain features and apps being there and not and whose controlling what as well as Google having to support non AOSP binaries and external signatures on apks not belonging to them, blah, blah, blah.

Bottom line to me is this.  Do not agree to something contractually that make both parties money at the cost of the consumer.  This should have all been figured out and understood prior to selling this device and making promises.

[mandaman2k]

From the way I see it, all this is Verizon faults, since with the
Nexus S 4G, Google and Sprint had no problem on posting the binaries
and drivers on all 7 releases of Gingrbread that came out.

On Feb 8, 6:25 pm, Jesse Godsey <jessegod...@gmail.com> wrote:
> This is all obvious, but more to it than that.  Google also committed to
> supporting our phones which is why many of us have purchased them.
>
> Google and Verizon have had some disagreements and some back and forth
> about certain features and apps being there and not and whose controlling
> what as well as Google having to support non AOSP binaries and external
> signatures on apks not belonging to them, blah, blah, blah.
>
> Bottom line to me is this.  Do not agree to something contractually that
> make both parties money at the cost of the consumer.  This should have all
> been figured out and understood prior to selling this device and making
> promises.

[Bryan Buckley]

just wondering... what's the better alternative phone/software for a CDMA network? iPhone? windows? Just wondering. Seems like you value the network more than the OS, which is fine. I am still on CDMA also; though I am strongly considering switching networks now (especially since data is getting to be so expensive... I might not even buy the data and just rely on offline functionalities of Android and wifi)

I too wish CDMA wasn't so license-ridden (since I have been VERY happy with CDMA/LTE), but I value the OS more than the network these days. If anything, the second-rate support of Android on CDMA (and worse time-to-markets) should be a wakeup call to telecoms using CDMA.

Is it possible to at least support the very bare CDMA functionality like voice in AOSP or some binary download page? I am pretty ignorant on matters of radio communication technologies, but as I mentioned before, I am starting to ponder the idea of only having voice/sms and wifi anyway.

On Wed, Jul 4, 2012 at 2:40 PM, adam forrest <ajf...@gmail.com> wrote:

i bought my toroplus just for the fast updates less then a month ago locked in to 2 year contract i can safely say i will never buy another android phone as long as i live and am in the proccess of selling my nexus thank you google for killing a hardcore fan

On Monday, February 6, 2012 4:22:00 PM UTC-5, JBQ wrote:

You may have heard about a change in AOSP support for 3 CDMA devices:
Nexus S 4G (Sprint), Motorola Xoom (Verizon Wireless), and Galaxy
Nexus (Verizon Wireless). A high-level view is

provided here: https://groups.google.com/group/android-contrib/browse_thread/thread/a61cf74b965dbde5

--

You received this message because you are subscribed to the Google Groups "android-platform" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/VP8cM_C2PWUJ.

[Jean-Baptiste Queru]

Well, it's very much possible to support CDMA devices in AOSP. As an
example, we've resolved the issues on the Nexus S 4G, and it's back
with full support, voice and data, CDMA and WiMAX. Along with the
other variants of Nexus S, it works great with AOSP and all the
hardware is functional.

That being said, regardless of the differences between GSM and CDMA
devices, the only devices that can be supported in AOSP are the
flagship devices, i.e. the ones that Google gets directly involved in
as part of preparing new versions of Android. That's how the GSM
Galaxy Nexus that's sold in the Google Play Store is supported, but
the Sprint Galaxy Nexus can't be (Google's involvement isn't quite
direct enough for the latter to be supported in AOSP).

JBQ

Technical Lead, Android Open Source Project, Google.

[Jean-Baptiste Queru]

[Borgey]

So we've been lied to basically is what this says but only in a nice
way. We've been pretty much fooled into thinking this phone would have
AOSP support at the time of purchase only to get it taken away 2
months after? Just because Google can't make a deal with people who
own licenses should NOT be consumers problem since we've already came
through on our part of the deal (paying for the phone). Now Google
needs to remain TRUE to their word and give us what we were promised
when we purchased a Nexus device.

On Feb 6, 4:22 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> You may have heard about a change in AOSP support for 3 CDMA devices:
> Nexus S 4G (Sprint), Motorola Xoom (Verizon Wireless), and Galaxy
> Nexus (Verizon Wireless). A high-level view is

> provided here:https://groups.google.com/group/android-contrib/browse_thread/thread/...

>
> Here is a look at the practical technical differences between GSM and
> CDMA, as relevant to these devices.
>
> In order to properly support a given device in AOSP, the relevant
> proprietary binaries need to be available. For Nexus devices, we make

> as many of these as possible available throughhttps://code.google.com/android/nexus/drivers.html, which requires an

[Jean-Baptiste Queru]

I'm very sorry that you feel that way.

We really intended to get better support for CDMA devices, on par with
GSM devices. That was definitely the original plan, but sometimes even
the best plans bump into difficulties. With appropriate licenses and a
bit of help from the manufacturers and operators to tie the loose
ends, there's no fundamental technical reason why that shouldn't be
possible.

Unfortunately no matter how much I might desire to distribute the
missing proprietary binaries in a form that's appropriate for use with
AOSP, I can't possibly do that without appropriate licenses. Without
those files, there's no way to honestly claim that AOSP is supported
on those devices.

JBQ

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>

--

[Borgey]

I understand your end, I really do. But, I really do feel like we've
just got cheat out of a Nexus........ big time

> > For more options, visit this group athttp://groups.google.com/group/android-platform?hl=en.

[Ievgenii Nazaruk]

As an option AOSP could start supporting external signature files.
For example an external .zip archive with all the META-INF folder
content:

some-app.apk
some-app.sig <- external signature, exact copy of META-INF folder

This external signature should have priority over the internal one for
this
mechanism to work. Some modifications should be done to the
package manager of course. But that's not impossible.

On Feb 6, 11:22 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> You may have heard about a change in AOSP support for 3 CDMA devices:
> Nexus S 4G (Sprint), Motorola Xoom (Verizon Wireless), and Galaxy
> Nexus (Verizon Wireless). A high-level view is

> provided here:https://groups.google.com/group/android-contrib/browse_thread/thread/...

>
> Here is a look at the practical technical differences between GSM and
> CDMA, as relevant to these devices.
>
> In order to properly support a given device in AOSP, the relevant
> proprietary binaries need to be available. For Nexus devices, we make

> as many of these as possible available throughhttps://code.google.com/android/nexus/drivers.html, which requires an

[Jean-Baptiste Queru]

It's theoretically possible, but bumps into two aspects:

-It requires to modify an extremely sensitive part of the package
manager, for a use case that's not relevant for retail devices, so the
risk-reward balance is heavily stacked against AOSP. At the very least
you'll want that behavior to be off by default, with a mechanism to
turn it on that would only be enabled in custom AOSP builds.

-It requires to generate those signatures without copying the files,
i.e. they'd need to be generated on-device, with a usage pattern that
isn't the normal usage pattern for those files.

I agree that with those two aspects we'd be potentially one step
closer toward being able to do http://goo.gl/8jit8 on some CDMA

devices.

JBQ

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>

--

[Brad Gogats]

As long as Google continues to support the CDMA devices with retail builds and factory images I dont think we will see much change, AOSP will still be usable to us just not 'officially' supported due to license issues (which we really hope can be worked out but probably will not be, especially with fierce competition in the LTE IP space), thanks JQB and lets all hope Google holds up their end of the bargain and continues to provide retail builds to the CDMA devices.  

[Prem Kumar]

What about supporting CDMA devices for folks that don't need the CDMA
drivers but can benefit from all the other drivers such as Wifi etc?
We recently got several CDMA phones and it is a shame to have to
switch to GSM without much notice.

On Feb 6, 3:34 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> It's theoretically possible, but bumps into two aspects:
>
> -It requires to modify an extremely sensitive part of the package
> manager, for a use case that's not relevant for retail devices, so the
> risk-reward balance is heavily stacked against AOSP. At the very least
> you'll want that behavior to be off by default, with a mechanism to
> turn it on that would only be enabled in custom AOSP builds.
>
> -It requires to generate those signatures without copying the files,
> i.e. they'd need to be generated on-device, with a usage pattern that
> isn't the normal usage pattern for those files.
>
> I agree that with those two aspects we'd be potentially one step

> closer toward being able to dohttp://goo.gl/8jit8on some CDMA

> > For more options, visit this group athttp://groups.google.com/group/android-platform?hl=en.

[Ezekeel]

Regarding custom ROMs, since resigning the proprietary binaries and
distributing them would break copyright law, what about pulling the
proprietary binaries from the device during the installation process,
resigning them on-the-fly with keys fitting for that custom ROM and
putting them back? I guess that would break the EULA the user has
agreed to, but do I see it right that this would not break the
copyright? Would this be a way for the Android community to legally
distribute custom ROMs for CDMA devices?

On Feb 6, 10:22 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> You may have heard about a change in AOSP support for 3 CDMA devices:
> Nexus S 4G (Sprint), Motorola Xoom (Verizon Wireless), and Galaxy
> Nexus (Verizon Wireless). A high-level view is

> provided here:https://groups.google.com/group/android-contrib/browse_thread/thread/...

>
> Here is a look at the practical technical differences between GSM and
> CDMA, as relevant to these devices.
>
> In order to properly support a given device in AOSP, the relevant
> proprietary binaries need to be available. For Nexus devices, we make

> as many of these as possible available throughhttps://code.google.com/android/nexus/drivers.html, which requires an

[Pete]

I don't think that's really a "feeling", it's true. We each spent
around $600 (either directly or through contract) for what was being
sold as "the premier google developer phone".
If I bought a car with 4 tires, and 3 weeks later the seller showed up
to remove 1 of them, there would be a lawsuit.
Google didn't just figure this problem out, coinciding with the first
wave of everyone purchasing the Nexus. I have no doubt, at this point,
that the difficulties had a role in the delay of the release, but
someone figured that "we got a lot of phone to unload, let's get them
purchased before they find out"... I'm certain that some
entrepreneurial law team will figure out a way to get to the bottom of
this.

> > For more options, visit this group athttp://groups.google.com/group/android-platform?hl=en.

[Jean-Baptiste Queru]

Putting together instructions and/or tools for people to copy and
modify files without a license? This is a legal question, but since
I'm definitely not a lawyer, absolutely not a DMCA lawyer, and
undoubtedly not your lawyer, there is definitely absolutely
undoubtedly no way I can answer that question.

I suggest that you look at the details of http://goo.gl/8jit8 to see a
case where I take great care about not copying or modifying such
files. I also created the very annoying packaging of Samsung's
binaries for crespo4g binaries so that the exact files that get
distributed in the self-extractor remain unmodified.

JBQ

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>

--

[Skynet11]

Would this approach be possible for other CDMA devices, including
toro? Would this allow developers to legally build custom AOSP ROMs
for CDMA?

On Feb 7, 10:57 am, Jean-Baptiste Queru <j...@android.com> wrote:
> Putting together instructions and/or tools for people to copy and
> modify files without a license? This is a legal question, but since
> I'm definitely not a lawyer, absolutely not a DMCA lawyer, and
> undoubtedly not your lawyer, there is definitely absolutely
> undoubtedly no way I can answer that question.
>

> I suggest that you look at the details ofhttp://goo.gl/8jit8to see a

> > For more options, visit this group athttp://groups.google.com/group/android-platform?hl=en.

[Jean-Baptiste Queru]

Well, I can't speak about all CDMA devices, since I'm only familiar
with a few of them.

Also, again, I'm not a lawyer, and i'm not your lawyer, so I can't
possibly answer questions about whether something is legal or not.

The approach I took for the GSM Galaxy Nexus (installing via recovery,
leaving proprietary files entirely untouched in the process)
definitely doesn't for for the CDMA version, because the proprietary
files on that device need to be modified in order to work with a
custom build, and the tools I used don't allow doing anything like
that.

JBQ

> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Skynet11]

A question I had asked you directly before, and I thought others would
benefit from: Is it conceivable that AOSP does automatically re-sign
the proprietaries during compile time?

On Feb 7, 2:13 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> Well, I can't speak about all CDMA devices, since I'm only familiar
> with a few of them.
>
> Also, again, I'm not a lawyer, and i'm not your lawyer, so I can't
> possibly answer questions about whether something is legal or not.
>
> The approach I took for the GSM Galaxy Nexus (installing via recovery,
> leaving proprietary files entirely untouched in the process)
> definitely doesn't for for the CDMA version, because the proprietary
> files on that device need to be modified in order to work with a
> custom build, and the tools I used don't allow doing anything like
> that.
>
> JBQ
>
>
>
>
>
>
>
>
>
> On Tue, Feb 7, 2012 at 11:04 AM, Skynet11 <jmcintir...@gmail.com> wrote:
> > Would this approach be possible for other CDMA devices, including
> > toro? Would this allow developers to legally build custom AOSP ROMs
> > for CDMA?
>
> > On Feb 7, 10:57 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> Putting together instructions and/or tools for people to copy and
> >> modify files without a license? This is a legal question, but since
> >> I'm definitely not a lawyer, absolutely not a DMCA lawyer, and
> >> undoubtedly not your lawyer, there is definitely absolutely
> >> undoubtedly no way I can answer that question.
>

> >> I suggest that you look at the details ofhttp://goo.gl/8jit8tosee a

[Jean-Baptiste Queru]

-That'd require to copy the proprietary files into the source tree,
which can't be done without a license.

-That'd require to modify the proprietary files, which can't be done
without a license.

JBQ

> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Nathaniel Husted]

Thanks for the update on this. It's this sort of issue where I wish
the Android division at Google would use its bully pulpit and pressure
companies to provide more "open" alternatives in this regard. Google
is in a particularly unique position given an OS stack that is already
open source thus providing a great basis for an open mobile platform.
I commend the progress of the AOSP team (which I assume to be a...
very... small subset of the Android building as a whole) to open up
Android as much as it can, it sometimes feels as though for every two
steps that are made, the carriers' stubbornness puts us three steps
back. It appears as if they unable to release their anachronistic
viewpoint on wireless data networks.

Cheers,
Nathaniel

[Jean-Baptiste Queru]

Thanks!

You're definitely right that there are steps forward and steps back.
Over some short periods of time, at times things move backward a bit,
often as a result of trying to move too far forward and then having to
retreat a bit.

I do believe however that things have been moving forward overall. As
high-level examples, we now have unlockable bootloaders in retail
devices (starting with Nexus One). We now have licenses for some of
the proprietary binaries (starting with Nexus S). We now have official
factory images (starting with Galaxy Nexus).

JBQ

[S 'Dis' McCarthy]

Unfortunately, it seems likely that the courts will agree with Google.
(http://gotgame.com/2011/12/13/linux-lawsuityou-have-been-dismissed/)

[Jean-Baptiste Queru]

I got additional information, which will make things harder:

Apks on retail images are run through dexopt at build time, replacing
the dex section with an odex file. The resulting odex files are
optimized globally along library dependencies. An apk that's been run
through dexopt can only run against the exact libraries that were used
in the same dexopt phase.

What that really means is that even if we managed to get the package
manager to recognize those apks as having the platform signature (one
way or another), we still wouldn't be able to execute the code in
question, as that code is only executable in the context of the system
it was original built as a part of.

That's exactly the kind of difficulty that we keep bumping into when
we don't have the appropriate licenses, especially for apks.

JBQ

[Ashwin Gururaghavendran]

I have a LTE Xoom and a CDMA/LTE Galaxy Nexus - all of which I
purchased for developing custom ROMs and other system modifications
that I can redistribute. But now it looks like it would be tough for
even myself to build and get such a fully working custom ROM.

The amount we pay for these devloper devices is substantial - and I'm
sure Google would have had this foresight/information about such
problems way ahead. The appropriate thing from Google's side for us
developers would have to give few warnings about such grey areas (at
least for the Verizon Galaxy Nexus) before the phone was available for
sale on the retail market.