Moto G sources

Search This thread

helinhof

Senior Member
Jul 22, 2012
126
46
Franca
Hehe

Motorola hasn't ''released the source'' for the G, many things needed to the fun start will probably be out along the next days. But it's a beginning :D
 
Last edited:

Silencer96

Senior Member
Jan 4, 2012
438
61
CM11, miui, and PA ROM releases are imminent!

Sent from my XT1032 using XDA Premium 4 mobile app
 

tillaz

Senior Member
Jan 20, 2011
320
350
Are you sure for PA MIUI and CM?

They give some information on twitter or fb?

anyone who knows what their doing can build any of the AOSP based rom's for the moto G, with the sources available. (unofficial)
but if your asking if its been announced that the moto G is getting those officially then i have no idea.
 
Last edited:

Cameron581

Senior Member
Mar 28, 2013
618
705
They legally don't have to but if they want to be googles favorite then they will they could release a manual and still be aosp

Sent from my SAMSUNG-SGH-T989 using Tapatalk
 
  • Like
Reactions: protomank

josalaito

Senior Member
Aug 25, 2012
138
229
Is there something Motorola have not released that they have done for other phones? Would it be worth requesting?

Is licenses stuff, some android parts are GPL(Open source), these are Kernel and minor things, the rest of important part(Device and Vendor) are APACHE2 and the brands are allowed to don't release it.
 

flargen

Member
Jan 6, 2013
43
13
Do the device and vendor repos contain drivers or just configs? Sorry for the noob question... :p

Sent from my XT1032 using xda app-developers app
 

lost101

Inactive Recognized Contributor
May 30, 2008
7,417
9,305
This rss feed will notify of any changes or additions to the Moto G Source files. Numerous files appear to have been altered a few hours ago.
 
  • Like
Reactions: Yannis100

Top Liked Posts

  • There are no posts matching your filters.
  • 19
    Yes, I will be building for Moto G. I just need the latest source. The released source is old, causing all sorts of KGSL errors and the WLAN cause weird kernel panics. I hope moto responds and release the matching source.
    12
    sigh.. unfortunately, the latest source dump is OLD :( I have x84-16 ROM and when I ran my own kernel build with x84-14 sources, there are TONS of errors and kernel panics :(. I just posted on Moto's source forge page requesting for matching kernel source for X84-16 Release...
    10
    Motorola has released the sources of our smartphone :D

    Here is the link: https://sourceforge.net/projects/motog.motorola/files/
    8
    Thanks for the explanation. I'm going to try to get involved in development for the Moto G in the new year. Got loads of C++/general coding experience but I'm a real noob with Android dev at the moment and it's really hard to find a reliable source of info for how it all fits together... I think I'm starting to understand to some extent!

    Edit:
    What's with the ultra-confusing CAF versioning scheme? I'm seeing some tags like LNX.LA.2.7* corresponding to Android 4.4.*, and some others like LNX.LA.3.2* corresponding to Android 4.3.*, and basically every combination you can think of! I realise there are many chipsets involved here, but it seems all over the place and I can't find any explanation!

    Congratulations! You just figured out one of the top five CAF complaints of, well... basically everyone outside of Qualcomm. :)

    CAF branching/tagging has always been a bit confusing/a nightmare. The one thing that DOES seem to be a pattern is that the "2.7" branches only seem to apply older Kraits (8064 and 8960)

    In general, AOSP-derivative projects like CM and Omni have used "2.x" CAF branches as their baseline. jb_2.5 for 4.2, jb_2.6 for 4.3, and we're trying to use kk_2.7_* for 4.4 with Omni - one thing to note is that currently there are no "stable/longterm" CAF branches for 4.4 - there is kk_2.7_rbX, but no "general" kk_2.7 branch published. (rb branches tend to be deadends and can sometimes lead to merge headaches if you track them - but we have no other choice so far)

    It seems like there were some "3.x" branches/baselines starting with 4.3 - I think 3.2 for 4.3 and 3.5 for 4.4, and those "3.x" branches seem to support many more chips than the "2.x" branches.

    This could potentially lead to headaches down the line for the G short-term, although long-term, it's more of a general headache for various projects, if we've been primarily using "2.x" branches so far, and we need to move to something like one of the 3.x branches for newer chips.

    I know lalit will scream if we have to rebase to a 3.x branch for Omni qcom stuff... since just tracking 2.7 for some repos has been a nightmare so far.
    6
    Do the device and vendor repos contain drivers or just configs? Sorry for the noob question... :p

    Sent from my XT1032 using xda app-developers app

    Usually:
    Vendor repos - Those are blobs (usually pulled from a stock device) that are closed-source components - these are all various drivers
    Device tree - Configuration of the various options for a device. Sometimes, a new device requires new tweaks, these get implemented elsewhere
    If you look at any of the AOSP-derivative firmware packages, you'll see that there are device support components all over in frameworks/base, frameworks/native, and many other locations. Sometimes supporting a new device requires adding stuff here, and sometimes figuring out what needs to be added is a major pain in the ass

    In the case of this device: Very few projects, if any, support the Snapdragon 400 yet. That's the bad news - far more likely to have weird "unknowns" or extra work to do. The good news is, Qualcomm is very good about posting reference source for their platforms to CodeAurora. If Motorola didn't deviate too far from CAF, it makes bringup easier.

    The first step of bringup on a Qualcomm device is usually figuring out which CAF tag at https://www.codeaurora.org/xwiki/bin/QAEP/release was used by Motorola as a starting point.

    In our case, it'll be one of the msm8226 4.3 releases

    To figure out which one, usually the trick is:
    Clone the CAF kernel/msm repo - https://www.codeaurora.org/cgit/quic/la/kernel/msm/
    Check out one of the candidate release tags
    Drop the Motorola source release on top of the checked out source
    Do
    Code:
    git diff > ../<TAG>.diff
    Reset the tree completely
    Check out another tag
    drop source and diff again
    Rinse and repeat
    Look for the tag that results in the smallest <TAG>.diff file