From a9788cd98f14de4c07134df1466673488c3df95c Mon Sep 17 00:00:00 2001 From: Dan Morrill Date: Sun, 15 Nov 2009 11:49:30 -0800 Subject: [PATCH] Cleaning up source.android.com files. This change fixes some formatting artifacts that resulted from the export from Sites, and also updates links to no longer point to Sites and use the standard {@docRoot} idiom. Also contains a few content updates, and introduces a page about branch management. --- pdk/docs/about/philosophy.jd | 2 - pdk/docs/community/groups-charter.jd | 19 -- pdk/docs/community/index.jd | 32 ++- pdk/docs/compatibility/contact-us.jd | 13 +- pdk/docs/compatibility/cts-intro.jd | 30 +-- pdk/docs/compatibility/faq.jd | 44 +--- pdk/docs/compatibility/index.jd | 17 +- pdk/docs/downloads/index.jd | 2 - pdk/docs/images/code-lines.png | Bin 0 -> 238643 bytes pdk/docs/porting/bluetooth.jd | 2 +- .../porting/bluetooth/bluetooth_process.jd | 2 +- pdk/docs/porting/bring_up.jd | 2 +- pdk/docs/porting/build_system.jd | 6 +- pdk/docs/porting/index.jd | 2 +- pdk/docs/porting/power_management.jd | 2 +- pdk/docs/source/building-dream.jd | 13 +- pdk/docs/source/cla-corporate.jd | 6 +- pdk/docs/source/cla-individual.jd | 10 +- pdk/docs/source/code-lines.jd | 77 +++++++ pdk/docs/source/code-style.jd | 44 ++-- pdk/docs/source/documentation.jd | 28 ++- pdk/docs/source/download.jd | 94 ++------- pdk/docs/source/git-repo.jd | 197 +++++------------- pdk/docs/source/index.jd | 6 +- pdk/docs/source/licenses.jd | 4 +- pdk/docs/source/life-of-a-patch.jd | 10 +- pdk/docs/source/overview-1.0.jd | 37 ++-- pdk/docs/source/overview-1.5.jd | 10 +- pdk/docs/source/overview.jd | 4 +- pdk/docs/source/roles.jd | 8 - pdk/docs/source/source_toc.cs | 1 + pdk/docs/source/submit-patches.jd | 176 +++++----------- pdk/docs/source/using-eclipse.jd | 26 ++- 33 files changed, 352 insertions(+), 574 deletions(-) create mode 100644 pdk/docs/images/code-lines.png create mode 100644 pdk/docs/source/code-lines.jd diff --git a/pdk/docs/about/philosophy.jd b/pdk/docs/about/philosophy.jd index a1a75ccba..64d04234e 100644 --- a/pdk/docs/about/philosophy.jd +++ b/pdk/docs/about/philosophy.jd @@ -1,7 +1,6 @@ page.title=Philosophy and Goals doc.type=about @jd:body -

Android is an open-source software stack for mobile phones and similar devices. The Android Open Source Project is tasked with maintaining current and developing new versions of the Android software. We believe that users @@ -77,4 +76,3 @@ we ship high-quality, flagship devices with an intense product and end-user focus. The "next release" of Android is driven by the product needs for the next generation of mobile devices; the resulting excellent product is then released to open source and becomes the new current version of the platform.

-
diff --git a/pdk/docs/community/groups-charter.jd b/pdk/docs/community/groups-charter.jd index 69381d9a9..6d5b501ed 100644 --- a/pdk/docs/community/groups-charter.jd +++ b/pdk/docs/community/groups-charter.jd @@ -1,24 +1,6 @@ page.title=Android Discussion Groups Charter doc.type=community @jd:body -

Android mailing lists charter -

-
-
-
-

Audience

@@ -47,4 +29,3 @@ Contacting the moderators

But if you see an outrageous violation, want to report spam, feel very strongly about something, or even if you just want to chat, then contact the mailing list's owners. It's what we're here for!

-
diff --git a/pdk/docs/community/index.jd b/pdk/docs/community/index.jd index d00838fbc..5d219c8bd 100644 --- a/pdk/docs/community/index.jd +++ b/pdk/docs/community/index.jd @@ -34,21 +34,23 @@ href="http://developer.android.com/community/index.html">http://developer.androi read How To Ask Questions The Smart Way. +

Open Source Project discussions

Using email with Google Groups

diff --git a/pdk/docs/compatibility/contact-us.jd b/pdk/docs/compatibility/contact-us.jd index 92062ba70..432dc2296 100644 --- a/pdk/docs/compatibility/contact-us.jd +++ b/pdk/docs/compatibility/contact-us.jd @@ -1,11 +1,10 @@ -page.title=Android Compatibility - Contact Us +page.title=Contact Us doc.type=compatibility @jd:body -

Mailing list -

+

Mailing list

Welcome to the Android compatibility mailing list!
To get the most out of the mailing list discussions, please do the following before you post: -
  1. Read themailing list charter +
    1. Read the mailing list charter that covers the community guidelines.

    2. Search the mailing list archives @@ -13,15 +12,15 @@ to see whether your questions have already been discussed.

    3. Be very clear about your question in the subject -- it helps everyone, both those trying to answer your question as well as those who may be looking for information in the future.

    4. Give plenty of details -in your post to help others understand your problem. Code or log snippets, as well as pointers to screenshots, may also be helpful. For a great guide to phrasing your questions, readHow To Ask Questions The Smart Way +in your post to help others understand your problem. Code or log snippets, as well as pointers to screenshots, may also be helpful. For a great guide to phrasing your questions, read How To Ask Questions The Smart Way .

    There are two ways to join the Android compatibility mailing list:
-
  • Once all the tests are executed, you can view the test results in your browser and use the results to adjust your design. You can continue to run the CTS throughout your development process.
    • -
  • If you see test failures, follow the instructions on theCompatibility FAQ +
  • If you see test failures, follow the instructions on the Compatibility FAQ page.
    • When you are ready, you can submit the report generated by the CTS to cts@android.com. The report is a .zip archived file that contains XML results and supplemental information such as screen captures.
    @@ -50,15 +40,15 @@ The CTS includes the following types of test cases:

    Areas Covered

    -The unit test cases cover the following areas to ensure compatibility
    +The unit test cases cover the following areas to ensure compatibility
    - + - - - + - + - - +
    AreaDescription
    AreaDescription
    Signature tests For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.
    Platform API TestsTest the platform (core libraries and Android Application Framework) APIs as documented in the SDKClass Index +Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK Class Index to ensure API correctness:
    • correct class, attribute and method signatures
      • @@ -68,7 +58,7 @@ to ensure API correctness:
    Dalvik VM TestsThe tests focus on testing the Dalvik VM
    Platform Data ModelThe CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDKandroid.provider +The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK android.provider package:
    • contacts
      • @@ -78,13 +68,13 @@ package:
    Platform IntentsThe CTS tests the core platform intents, as documented in the SDKAvailable Intents.The CTS tests the core platform intents, as documented in the SDK Available Intents.
    Platform PermissionsThe CTS tests the core platform permissions, as documented in the SDKAvailable Permissions.The CTS tests the core platform permissions, as documented in the SDK Available Permissions.
    Platform Resources
    		The CTS tests for correct handling of the core platform resource types, as documented in the SDKAvailable Resource Types +
    Platform Resources
    		The CTS tests for correct handling of the core platform resource types, as documented in the SDK Available Resource Types . This includes tests for: bGoK}OH(^pBa2w2rhj@^<6P-z+BTq4k0WY-NW5Rj?eK7Cd8)z{86_=Uao* zYNbg;wmIDIGE!SvfOa3Yf7+z6Cdk3WV*3M}GO?WsKmIPc-wf zhwvqA2QKsXWS40Suc7t75ugqdHu~DAu|s#^A{BU zhBt)_K_9U27W>(hFT{`R-$y@T7z;eKtqnLRlPnB(I^if+{fb#@bgkM=>}Z~*l9C-H+jN)^Z-k4UNk@t@!a!s__3y&eaPfZ za7yoj!cE3Iw*Aof6sghbom*WRyzvi`$-kj1fLoB_Sp-a0oAIpPt8lD%d^_b)UiO1~e7g`1qMm!VgnWev!9*}L zXEkSK3qG0D2a6YUV|q!RkO01}8=_hx6TdR*5oWfjfP6#9KgGS^C?xINk~%xwyFGxd z{x$P_7E-yMiVPc24jhl1jEDJmst(a-CEPPvy!cIFO<_b?Zp3qLma)L0>LG^+KWLps z>G;jmh$JiFJS`VBmwIINNo!jvANM5Rq|UF^;u=}HQ7 zBA{u0nR0Co=1iJSf&=^m?dHRS%F=oWXD+q?qmj)5;SwRR7`cV_7Y%KXea@-?&V)(v z51Bj0!1su_E!8K{v+Zg31*#pM;vj4H5)X6o;`We-xx zEvGl->)IgC;mIADIA`dw(Zauj?ZuMoRRb6Qlf7aM{darUyTH(zz#YCneD4s7`{k8K z{C)LFH&^^E`X6$oInG|;-tM&x#8X5?i60>YA*nhi8p|LJbtm7Rt5+RbH*`02C#hWb z%SX7$u95XKSsge0rLj3g2 zTehuUG!V&(+vCqkTi$gaIwr%l@EASO;@nPJrEcdNlLW^DZL-8@Lgj#6j-5MRNHBAy2H7Y%r!u0WdfTA7O|acCE$= z4QCZzvsXxeNS8dU)@mD1*S=64~K7bq7ft~94f9{GgOX2qAZ=!?|3 z808Sa-x(l02E-U)#ZZXyxT0or4)#s;DKnjUTzJe7*4H|l7XNHvce8*XhaE?(V#q?? zlD;L?Ans0aVl33Ed1=Y?jNKw0;K#~dK5AT)1>)+X>*pb-WhZ5;xJmybA8SX_Uz8Fk z1;oZHJ2*QyVh&Bqsyx;?y~@^fQ`_dB_Fr|N*u}xABR8e)Qpb}Cf0oW0O+lOaV`5nl zeNAdjYG|E3 zLopVhBTuel{;x+qWOBZV(7oTDBDB}^Y+vk0|M&hD_mj6Cp%O!CQ)-FEkSgEyYpZSf zx%A53Hir-MpR0UKnv|QA%h!c=h0He&cH~F07;>{)y?5J!SB{n`I)|WTo2^WTa)hx_( ztNS@0ELL&1xKX}Qjv{7I+$F>ORAY9Nx;iX%OLt30QX#+0WycAx=$gLYL%eWpx7>WW zn7PF{IO9;3R-V>tT>v{J0;c|J2_C=vYxpKT0w>9{r7e14x(EH@;ow(C+cTOgnOGQE zDmtCwJ>ut$@UD0uwLYFSj9=B!yQuu7h3=y|<2q6I8b`>}#2#+5FZmA6+xR5;BtH;c zR__~`^7nN5p8nrpA(JJy(?0p3*MZl8t>4Sm$_zfZiq3}6<@;3| zcZP9xNmnXVRta7?9`qN-M!#!8T*)*LX&}?-w6}D%Y^bTZuQ};&;a=iwve}+pE?+FK z-P2KQ$dUT?xznf<5O6(d0KWQX$oT(;yct4>F~WVR@Pc{fc;-NYRwUx22lFDhyJjug znfu1mUMn6IOHXMQRC8QLFJRObGVFRCUoAl(ALBowJ)xXNu3?IIUq(VOfBb}I`Z-MN zwbzb03zl?_u&^!PLA4H#Z<$kbS>^4F|>gSU_^Yc7sOYrIQ>EqfxuM^9Ne(J^Y zmjTa#_wTL-4rAY#Zc;cY|Ig%=zx!W7GWuO0hR&t;rFSLSA;BR*>>`xi$G#%=w7ccm z#8bJ+qp7*UFvLH^Kigm^A^`&%ht^JE3EguA*&e<$_z~tF4n}N!uWRCVPXHnSX~|@f z)Q@}Tn?8~;qOOnm_Y5|N{cBqNe0&i(MPv6zkj=tAe0<{?P%F(Z#veRZx3lEzd6&Z~ zU^sMSvioE7tJxsm4?a%Y=%%=)RK+pMi=m}0G*n@pQT`co|Ex!A%sbG2bI{fJQRX6N zX0BzvCHYjYTc{fxpD5O+@;0eUeTEjn4Gt%Kl zJ!2cY=!I6j4MseQa6$C#rDCXsqklrq5ecL|7C^RNb_(f#=Ux~tGi*qATi%<|i^gjJ zSR-WTtFusg-+6MADU79qtpny3+7jGS|B{p8XdcAG4)K}2g`_nD9n@X;__`ha$cG`h z%fgzDAXD=}xj6x(#83o*JUAUSeM}V;aiji)uv%w|d*_p#%$w%ibw7h#+yRuWCV>aG zz5Z_+7sER#BPmG(qXTkHS!14A7e)nmd3XRtwQRx{+hqE0EU;fHX30jwPQzY+OhYJV zuE)7=F&Wzp;}wt0>?F#?@~Z4w^%8K9coHZU5xWUH83wf0ui)$TzLxXrj#ZK6(%@>^ zQT}lhwfH&OG21a4h;;9O{>Eyj!CB{PjrxL&oOw$9un3_~uO_$^YVLjI{}XSI>)lD8 zz6lkQR?oL`5B*cV!jJD*5cl|6yjr{>ny&cP4}He+`4c@T%&H4w3S(@91sMF*SctLQ z$RRN8eJ}W1SLOZfXs6@ei^eYDV;s0$g6lc6nF*sbBA||eC!_HVnm&kjpaOOLd>I{s*2-nkR0%H{O#_RSJ`CV=HLl6bS`O{}+4rzU^Y^u4b?({cP*TvDn=~L)S`@6j! zLH{duhxQdb6H$j@_9Gg>67KhO^>+16Tt}Wo8kH`zEVOV;Fn`nHslD5}8ahn8^6nD~ z^Gzm+hhT$ct1{M-*S_P=&{WIkIJ!5pthSxmf0?+*8AO;FpC6} z(C3EFsnH`piYQG#n0^4r1=0i9@M$XAHd%jIRyRvHpfsn|x7PDA_HG9KfCIqzrQ@?g z9Us=9e{Ira_ugxTBHsDP!|$VPuP}{*q?4two||rXPMw(BqiC@d6ISE(vD<+Rn*#-e z(M6qx-W}Iv)WMBGjYEdBLEs>;`3?WlY1zJ|u(B`)|BvCB;jd33{f7Oy99v6{c0F(J zL=Dx`BAx;XL}O^+xd3l0&zLIYg?pa_Y7J=3Yj?o$3S(dGDx;d{p?F(K_u$?7H(bfX zBD`g5-A`@KO%M4GV_dp1Gbe-?#L(@-A;1eunqVeU5pK zaa-7o`GH?U;e{@!2CX=QdOZKeqR=Ky6Lh@*BxGiN6n&JbuCMf1`^gBLM-_*HTJ*5Tl7 z%O`{b!{yEZk-J<;*M^h(dI+3AmBQ#{v4&lk1px>oIM`Le zld7MqyZ$-piQ!Ql+QD?Ya={D=1&4y8+}*6)tY(p+h%cZ0Yu?ts#neU9<8~xIjNIWF zaROEyb&D`jRAJ2LAz4Xe2D0XhTbA=-K$TeiUv!ZF{Eb`fBixs-A7Pl~i|D7f_dL5V z{06UVx7G&?zw|rQukU*Gvfr|M_V>+48?Yv|ThN%%aLR0={vftK^K3gmkmwyEaq#MZ z((1X@xoxtz9_=hdV^rG|+rUi>J#PD{r`^oRzTyX13m8i_r~{bM^LW42M~WmM9WO5m zBwJ=WoPPN#u=J4M*wOmbAC1OJKua@(xhu7{@;m$DWJ+BGa#L~(2B%yE~ zCm+*XSoUU{uH7NWYTXd=Qrv9FV5j?+<4GQ#I1)+LlRB_t1$i`EtEIE@r_1z3QyPDb zJ?U)PTI)(09r@2vFNLx{jTF!n(9*@BP(v^Qyy+Efv$+eHcrcy4Us(!;DGytaS%TN( zfAu-$2Y+HnbneC03zV@1S%Ivq=oaYK%{EWHdEB@U{WirdxJf%qRQ;o?q&0XWJD{`8YYcfM3+7%1HcKp7ee^)UR1| zR!A7cb`wlsHyzGaVeS>wx7WAl`Qn=4Qq%r$irXSuf_-v%a?ujycoz%pMSJvqom(ZL zY5E(*o$$z<0i_4ZDF7q$*B0kb^#9)+=5a{+#GoB}+1C7UBH7{YB*WfIej4}M%!$lR;PhVXPWHGm=lR+-8kjodBsIXi+TsNVSA_=)`sBMV5d8=M{Re3R$v{Ltk_zx(iq6y@a?sDp(~`KgH9YDmY* z%F=3xz?Ovzx7pyL<=839yL@bmE1r;p0t+Lmr0u5TrlYMjKTC{z#Cp?v@W%YK9-#)| zm$ROC`!!C$x@Gs&$`n?{g3&^-xWvO=;#(`JRp-9@YaEP@z=AL1c!;k~PQOzcSh3+A+8 z&@KM356zGL(fsZ5wce5oJxU0fn%j#DhJJVQZ>C#XQZtdH?b{KGz!J)ZcRDq&O$6%_>N=EY##Hp60?h4k{~0Lq$a0*z<;X zL!#LqHSeo;*PPBh&P!L7_^aJ>_WL&L|F9*bOUS9Z`MyZ1g7UAo8R94B@l)$V>T4)) zcH^XN-r~or*d!zAngnobt4lq{HRudf)5d3{*;6Hv_PyYHK^q#m5V_EF7RCr=YP8U0 z!?6{k?f%Acf7XLOYB zWMPWk^*wJZKN3sy(j~N)s2-?+Y=-(1!W&c32uL|JiVd=y?PN0U6AdK2-kYNMb3Uk> z&VSd&v^eJ>zTn?w$A(viR~}8dv%0fN5Wgw$h7Ewz`ro_4qx!$W6Z&12DM~%W6fAj& zd-3+-?Rf@92S&#oiekIqF-`Wv?nBl^U14P1C++g{oHjwXhCFtpaVDcvM_V^rb={>2 zP%a_u;NtpXE_l49rzHTV>ZIfZz6na~Qr1TESFZp3FNDWc5EThJnh`beevcLi`orAC ztHq;5_hn6eMV+Z4LKxS-s>*JtHz7FILWQr$)$%AsD_v`0|8KdxK)AcjGHB=8WBIr# zYk8?l_MS!0kQVwa>0C)&N$n%JDg7_LzwG`W&@|KrSk$G^QOiVvh<*WJd3s)9><6(R zn7aax)E0S|ggAs6o~~uP)BLVA<%k*#c=Pd=w z-*X*n&kejYMKn$BO6~z z>Vs|$sUVc+CF6DG>m-jqJ(~YK)7+W-w@dQh$A>v4@-s&R^-# zuIF^JcxNApxI%x#enp?N4sdIAH~HG>`tN#AcuC_2#d{TIU zLtoNujJC!VK^y47gO=+-w`9Kmf44XJ<*93cP8oFos%u_WlnC-A(~ZWBMpN#U)M4TS zgM*^O#6Wmt0)pE}-%@Df*Qf$o3B^j3PKz%SO74PH^i`1;)4XfE2A6Xlk*Dv*6~Z%6 z+3`)U_6{d#9cpYAI31H4C_p{$c6&QmhbiIcrScJ?@(`GM-!ZALzO?V{p9cRA%ksql ziD-RP+?U2gsCrxF9Fx7rJAwJNKQo;3P)?gck6{+1C+zd+=+qlwPuWJ#HKzgnsNlzu zziI0<6go;8*IwcLz!5j=hQ8f5+i0-1=sRXv&(k?1_rsedd_W+`2fP(>acA9;+>wOX zM=M050-$j}(Ebh70A1b$YW~w70KH57Bh!a<`gHnoted~vBYNk#mAjQo6-t`Ke{%Z? zE#D+3#9m~tvk+gSew4jy#DOB1rq82%aXp{<0m0XFtAd<82%veAs4UOvb~f{Q_}%j! z@1YajeZJfF7eoRt@s+wMY;8k3D?zn1%7V)JpuwI{SlsFBs5cRB0$^W@)d2Yeq1t&| z`0oUZ8j7LIXO+mqo|~MTutdmzr}_3X?t*x)LOp(8puojt`GN43+qzmPK_Fo^+Z+9w ztkPZg*Imz*Ixj80GOTWV`+r1^FBqz8hV^1?f@7Xsdon0z9%>fA6dYC8Y5d<^vf zp}#^io)>TYP2Lm+D1Wplzc0Uck|&BLj&5WyC;sL(Nw-yVV64jA4`+e<%`CTx*ogll zANd-?8Ze|bxIS3*i_>|)4_Kh&+6y4**6hv1x^No7fY*SROshi#cSu1CunJi9bktuE zF1}NL!+q>veW}2g>>2@~NECorRykziB||%B3_IGsT2jLrJN%2qHv~ zk4A#LLjwI%Bc>6t@^WR;L?(UGQN_8`pVZ`NoM;kS-gick zMUjP;gR`lDv0v!O*7<$f1^>|pf-i1_>XAM4GoCxHT((M8VE<+=bqeZM_h-Dq`aq5; z)F=7pj{|BnyzgY%vHWM653(e78O>$}7!LizD2!Q4MQ|l>eN<-9OW~i_zyHtkn7kT}|U)S;fa~>vd@&!kOJwI__ zruTU7@UFQCY>NaXW3*rTWP2N|u zNR|f51b`;F2zcYgj+1J<*%WXh;q$o@ex7N}#a7CPnD|-Hd<)8tk{phh^ZV{aky1n1 z8DY~PQS+K|zYOAtK(1cEGdwe^3VHu6Om8w|NeHeKk39g1{ z#qWOc1g+f4WNT?Iz+^1`vQ2wz?)M|e^dmernW`HLH2vPFgw)7}&eih~!quYGOpfDB zrU9;f61!4DyBfZkwcHtoDI6Z{7)SX=WB#aX%?@bP{%6wN+3#!c1_JO$U$Lu8-k$!f zZrTCaBAMR|lO?K4}8-XF$y>F2F}!AQ8#OcLJdw)CcdX6jbSFXHc^ab8@*`b%i(g0Vmcx{P5uhASR4X9f~qZ zhm;bk<}2g060up#TYLb<4$q9|x~JC+gvSdG142m#xANyyiL52$Q)Y{;ztlQ_zXml& z5f7V!1fYM7R*^2YqZ;OEP)zv2s(P;kOE5@XPtPV4kb5F+JiGy382;bX%xPh{q@H3AbffK#_D7)Qx8{Ww77en-*8K40% z+!hK|E;?O4O(8}@y5oZVbuYz?B8b*=zN{ninwmRPed1h4_vN*1qD!owo8HW;1&K4G zEMR|rF4BwKmr{2|(@o~)W)9j;f4)iz)}7#J>O3a+aLLBCO zU!aEvXr1Ix0v|kKkv^0M zg(a83U0u#|l|SazvAB6|_^lYQN_P$nDcHR~jkzOKdLy)7#z!YAoVV)u_6}Vz0zUnB z7rmDa1}oPF=jqnTz-#U9R3iv7CvjUD-)62AvjZ{6Cr4Pw#ai80sx&~H{&d(^7Kh6c zAsBq)7}fJiA}AQhUhsDfz4(pZ04z{g6Reb+^QF4iXg)C6I+K+0Y?$ikr+(1)jA$!? zL_8a8-4B>DHyyCAd8c$DY^_|#vQqDUB_85mN?yZyviCwYr9Q3!vQu34LtZIN248$j z97CLC!({=d!n;Kg_}m%{PX(oazoYTGK+tAb2~gsxg5-6pB7`cHZ8I7&oP5ruyOyzO zzobf%l|X7?*CK6cRwsVR<=uI2da+AhT-wk|QFDen&{OamcBMNt z@^Eu1U{rS$@8>~WpAAfN%>$w3EDmdpc!h_)2A(-5^PANzYn2uP8qszegR4I?ClpoP zBtrbOBz_@KcoFq~JIZqx3I2iqZtX!US&*xq%hS3wzM*cdju)Fo%&?^ZI?tKc@{^z3 zN?gl2>d3`?2_z&deYsdQ6QFWSOxZ?Cxp17;_K5uIz0`11x@7MoKj7|jU|bsf{Z1Kz z@vTE^X5K=W&G3n!AooCTODCVUqL`uVEglFG^PI<|6jyA%_e~a4Qy@wJcQ>oOv1}$> zsF6sFwtjKbM}u|TF^oK)jLE1S_?6<)bc?FC?h6s4prFP5*B|)m@T9nFzdAQ_A;}r~ zM_HRQ9d&NqK7l~?C)mc!sFDX+#d!&w3B;eVSw1!{Do5e%ry3QV+oY;{hmvL8Y&ufo zWN0(?Kq!03i!(^IKSDx5h3r)}k7wsk`t3&cvLX)=;}WSfx=C$p1Wn^kg+u(i!;RoG zDqXXRD>XZ1(IlhiVfO0Oan-o2#(fP{)c_=T&9U9LpjA(vQ?ZV{HfW^?QUvwtEISXv ziu9_(Bdf})W9G;#$5DvAvvRqFeWgvZre%LW&=hcrf${wZU-SG@p3lD%of%#5tv>!e zL1hrr#PC{!&4y23@xJN_D=--e(@ zPNLgE_#xh6?mxyUTS{w6^C)-#|1Kfm6WCXLe{g`Kz{4VgFfOf3FUiXAcqmPIOHZ5)c(O{ZnFf3m+LNQNjB;Do)cOB z{Aubj(L2MV$zdh&`)KZ!z10OP=w^FQ9Y-1dLjt`4<0)NgafmNn{D=@6#P3(CT{TT9 zBt(NN&dPJXY;kS*PJi#J<7cHHjIbksc^?Srg6<(o=AoyM#?SE*$P;62KhJ}Af3H|* zn=;<4BJ(v<`?-J8vy5K}mR~0HZb))OPwi(;fjfqUvcetrS$7YZ<;U^EXm4sjGUX zIhR~ZH@$reCB6=6`{^!HDK|iP?V^734tihwhCPs)BsyHSh8(grvn@}tfV(Ow50$!jE<)pLcCe5@waEjVC@( zYoh^Ov1s15{iYJkJ`YN@tee{edXXKHEC(jSzd%L+?dhOyLcSZDH`UJk9kdt@L>v4c+IJPrV zHiG$QR#tKyDc*u!z1frdMHM5a@#gVS97#7;=g?z!n}Bw^PO}`|zJuw~Cu-1n=y4&c zXKU}cZE{zP|YQ5*VPGZ{IGHd0X&x@lD8K4b?;7A{NANSAQLFE|w z{SteilqIfjmi9$q{f-gID{~B+v9qKOo0T{sU(n|fWx$=Egjrv71#bipZ9{v+^IR`m zFeywo&od*aPDQBxh3%8z&6#bb9zyCfI#%m5-0nfo4(efOt{RZTuly$SxO4MZX_TTR zd%)TxWMrn^g%%^tdTr}$-LX^$i}ee!_y~4I@{*EkQ31RZydOBKwZz>Sg_589DjyCb zBy~H3Ou?n5A7|^pK3hw}l{NJvug0y46Nmb5CpFPM!c~LTZ%=0{0`#}W8vScD)qIPF z*+BZ5V$H2WM+N7Bul?~?o8E79eO)V&3BJaZ^783(T{)MIdL3?S*})1z zJ2auY|K*OqFVy{7eefP$m6Ig1qZX2%wsVG4Ku%DQC8MLjMU1eX^n3Sb3Zn)qE6I8? z({l|KOV?sc%6!LuwSqcDMHN%WgA@j|n}NesO7uvunlE0$^H}-|ytLAHA~9}r>bAv< z*t2gv+Ji(twt#KX2#?2?VQWS|kH2RP5}CKoI91IdRbk|gjTX$QJ|*`{ipMp0^f11)SWETwswB(2QAY#Bmqn-vw^QgB6#h^gn&Fs-+xHrl=?T(`F zGDRmDH|Y5+Ma(wvW4d9YYIlvTD&Sc@t3LjeH5&UhR*E6WTYvh_3h|geL%#5k1SfZL zqUNYv({}l5hUksarmqyno$O>iK9c1sF>AwOWho^|*x4VQ1u z8}+9&@vBgk_0n`p{m%61Jlp5dHw_*GXiPK_4iN&gMYiM(p-p+!kSD0;_DNXgaNLq> zWOlq!;B%ACVW>L2FRdL<=jDt=IdyV~j>>ceO#$1D#NFX{cDw#6Dx5W!inS%jhMA*zR$ zCk6e+)YL%4E~w71OCxOQW4S)KZSZ(AXFXLo1MB%RuEE(wP`zp6#s=@UL3N5DP1ymX5mdsuY^41=Mtkzs|QSywY?+Iak>3bA_l4>A-_~g2d z;XcBXPT?$%mp9RjJWC6yG1nwmySUp>^gtCEDBF87JkmO#NxpKa*6vMT>-9=!M-c*_ zY~5$HfSmJu?l}X62iU>Y)!T`uY&ZKO$lY=B02#M39-c<4avDg6LIP-YgDT(PAV9$l zTt9r@EVhsCY~1Bbtaj&C=SF?8#P}GlQk36N#;C(++K=EQP^wBk6TOch0zlCa6>YF^ zhQElfdt_*%QQGS(`m6i5+5H(#j*TbG%4tM)AVToo5E^}oSL}d~Q^Kt9;{L3DeILG1d|Z%A zmUoDc502_uionT#hJ$Kf0*|_DD00$`4ft-6omh+LP9q`U_0vIA&F*{WK#C8nG%f}y z_p%3K!IhJu+9%6P%gipiLJX-QG@nHWaI=~4g2+p1r8VZ?op({0+f1FcltoZNvztpP z!YQ{OUw?XN4{m7j+IaXuz{hubdx*agW7^ORJi!nd8TA9QmJX*a-aa9SC%TV<*^s07Yz*uXp(oAlU8!jE* zGs9lFi5%;)N_ERC@+K%W3lW`eJIhUV2sC#5$ef4^TATl_F*3E1wjApjS6U9qd3nnb zW^GjNXnz;knl&z>OYT8_-}Q?t24>yA3tRC}duK<(^LlNX89y-)i2~lBBVqQ8{P$`{ zSRKv$ofZVXs3(k7Xd^^|+cQ}XOFJd!+UGOEO}5pqvc6jNTGG89oiFecPgj6d(JOX% zT;w;FTA6sxO&_dV)~_>`5FV4$HMP(z3*Ek=@JAa|AaU|J+ePX+B85HA6fmoyebHWQ zl%v9?BKTy;G8%jB?@67j&fm@u3@=U z@!NZ>Gb^5dGw&+^K&~VGNkokyglQH?2petuUf`*)kSTm&rqLQK zbp>;xPe=agtnoBD3jGfEa)!ettaAfqjJ>2jdmt;uruiUVgJFga(JZ^YbC$pGPUc`_ z36qk9HKM*lu(+$#_EYRk+BaF=$hWE*Y2zSidSpRb9~`HBk)x%QPPqEC$fV&BP~4-<4$~Z;%q3={oc{JI^s-H%=8t=)We+bqts^jJKq^M^7!l zdjBKG0)JbnWJjcJh9sfz*^Syv!K^2EDG0J5e>A6?Bk__G3AS_y{wc@JQ529Mcjkn~|(qMxy(6zo?# zQ6x+`qqfQ(0&tW9ihc%^Qw@)zE~-fIunPcQ&dwzt?e4C%3qLN)!b5ndfXyQ$*eW_&X4VE=_-Y$F(BE{;P6NifX zo4YYvmVk66#@E%w=mhj(eH0tSkHxMFdK#N<%6ns%L30UXe%b`a;Uy-uxtLvogjclb zB0TExEPK+#aM`;X+`_YJGhGWVk>DW*`+F32`)j>2E#GqMo+YwO643Lhr#7=Jx|rG3 zGds=%;>UJAKQPrbgjF$jZlO>Hzr{W!9oWWVwrQnKqdy{lN3pT~pcKMEPCSItW`isj z`c@V8F!7zf4v{ZQq`y$!DU66RmbmW$Kl{`?7M!wD9#J`45l)yZQiNiyzcU-15UAWr z#8fSMB$rf17y6ad>hg*Xpp+W~$2|};g_fgVc862&e&+6zD=qD%B)1rUbn_IVxMGtJ zYDP;UL%c3)GedY}O8z-(V&<%n`%e1q2Pa&buSJG0N43%RhZM*x_D-9yu*O;Hqllx5 zUrA%yO2e&`jkC*5b&AaF&@qF#Jl-nkX2q_*cunLhE4m9J>n70)e%-ULKh*dlJPr=$ zArB{K)9b@=fAPN@vN;_04k6}u?U-#gciFIba;JfbtSYK9`oOO;*`42F^`$d2Ni194 zFLZ=50`)t-NuY?Nbb4fe8)m=jH6H(W!fLx2l()a|ex(#4_%fOs!Mgxi)vP(zc$Yk7 zk4G-xf`8x5HqcQI+d|mm^>-p#eA5e)WmB^0>~1ql%$U8qHR#5Xt56Cp(yn~@v~I7f z@S&_gSzYlP(lo)0EkWbYUBaTzNF7OPZcAd`Y-BE$UY`P_BZ`~v1PzLeNL_}~h=46s z3*`-o3UQOB?@N%F z6}#-|gk)V4sX4$+CyewZ2UGBvr_d>Mk@8SIvSK(p0?!S2f&#sK-v?LIJDvNPdIKwv znll9ByRq;39kp&V`e{V5h=O$!-j*9OB2LBeNH@$xDpyP^x<;|Lf@ze&og&b*;^ebg z{diCBLB4#`hS;8f2D>k%%`Pr+6G_qr{Om_0scso$7RR4ipUKBYe9OcWn&l3o*wk*) zf!@KB6Vb(EYa$b_Ei*JS+=<@lr9W$^R1kUJAG3!OheByj4ijEW8!`_QEuaa4{giY2 z>Fe>2r`?=gYKHmslrLT_!rk z7jr-)Q*Qa_R{4LW{DEBTZ*;eCJ#+fYwKrxGu}-5mMf($zQxF-)ZC@InmCgZ0q`lBF zg&mLG@8>Rd(fw|*1&q~S!4kB@H2%@I#=71prgzu_I=?GA39m++`v1Ji&~(iu;EFC` zyJn-}c!T#=%(x85A2KQYE8+5<4PMkJMm;fDF1kFspjnY8eTbYRlGQ6~bY4{VQ#GwO zfkYNgG+Km0WFxN-8Q>M0`YJ()pNRw+4CQeKMOe=Fpy@@suY(=3r+t;TCHQS(9t-xB zRc0owW1f`Fwnzs$gDeXORtqFE%Nt*!Q?S%CkZK`i_Dh;1Zc zw_}ZW{*TOZ9Ps3&x+LT&=9Q%Y*L&wBGlA7?^2?1b3{rqD8+@*Vi+dn>d+g+peMs+T zi~P9KFXc}rcyF?e%Yp4dlM`|C%0@jtR!wsQQtVO=85<_b3(!$k!+Q(x4>Ji+vEg;U z)e(cVOCWw^m!}&Em;9oK67l3&V==bL1o+nQNel|54xa88lJ30(v{$e(xD{^2i<2}M zr)sNcP;EkMuj=e9TAFp}Iy`(vF065)%^^iv-1x}OQ2xn{7+mX$Hq4jo{2lveB4bG$ z9nyI;moqlLqC|%!(h@OAtuwoE`)R}b{Nm0rsbEiqCuB;Uw=?gc#PqZ3tJopvfPe*+ zE!Z27SeJK#eYk_C!3I$y0+-d(B#XEUrhk4-;A1O)0Ywo7)J()pj!&vY7~iD~Tv6zc zk!73tn3|9}g?@R4j*$47u;S+=!sPqStTO0)@}Ea06-`6SL;KCP3b;7G!B)1fI9$Tx zk9qffTs=2OS%PRpTNOsIH-rOEUjJQsw(Ni|KnAQFIYQw@Mkx^7Umx2 z%eG_JNvoe#-BqDkA5;}l)*v-Ou1SDO@mmZGdIs?*1d7xz`(!}~5m<0c0TBVOiVIya zQ1wTjgZJ(Xb0~4cu)@BrbXW6VbWC)TwzQlaow!DIns?(HMy`+BVH>n@m%fP<L_WRVB;lslaBi4(T?=3OUY1~A=AxTM_Y!5BdlsX3 z9Rcvi0YceFbsptW$VqUox9@#_^gSMl3wj^4>gdqE#r*>U;`sx|@G~7Sk;RBptVq2w zx~ebvUqPc-kJ&^H+W08)jR-Ztx{-tWOx5N$>qlJ753~W#KkRa!byu51WpAxkd zdv{2amLbi^Q2%Eut8c}^l;S&$Qx#8z*aoH}TJY_~u3k_9TKEHTnnsm4rXW^dr{^2A zm&bnl9Asn1xv|FEo!$aRXK&`81Dusu6$C#5L)&Q)>-aK8a^dNxP~-|1V!v z*LR1=YV1Ti#ukr1w%0k+2d_?EQy)AIO8SJHSv^>%X5EU!-WjCq%%lq~O%=VhlG&7n zpff13`-1Cu%{$#a`YOuxkBN&rml7Ei4$c6Mv@5Th(sff4c7?E@{KtEdvSX$&He*+; zi>k=pMFtWMkd&V9qnDG><0;a?2QJ$ld}0TeP*EH`{;2D5=gW+(3_&FB`{G*+(^0)29 zpTMA;TiI*$-twhh{TsVDq^#pLoL*a1>}yp1j~B_PXpXdW(x*067*9;5u($LhKII>{ z1KDd{QFCUz<&eSAD&_sWTJP+85j?Hl7ED4eQj7`PLoE0yGeKzg^pen4R`66?0nR#d zu}{NE>L&?>$MlnR7kag`FYaQm*G%A1%ycdEl;rI{z%}9L53u~~n7_yIkIovtp)3FC z%48>N7~{FfGw;^ZHTkD#&y?${Z=any-+RD=;F$X=jGM`*lcrmLmPwqeas>V2E$|k2 zq9^E2<~sg>#9n`(ro#8WXI)I%%dj3f_9uAvzT%BPM{Gi-O&UUc^6clPII~H(IB-r? z*v4Jr=?N|Vj zqN0fOt8^}iC=fbGCm<~}sUir3P((@~G*LiliU}P<4Lt;D(j@cTJN9m&Tq5UIeVU&dG_pm%A6D3%d5?S@J^OJa<_iD$T?}wo+ZM4gPM$(o-s3t zcFgM@e+^_MV<|cruPz`nrX@Hq<2hM5l11itQnDD5g#Al>5q=sT5*TH^HXGGAxoe1k zHUjrx-QQU_ZIO&OHJS`BZtA^&BBLzXL{O~RAEA}BiN}|4J;@a71Q#vr)1@EK? ziM|rYPBR9S%LBcx4X{vn$bbflRGGOYIO-Hfh(42jc?f|*zk+#vgUTmOcX3cM^>)Fm z+_r};)AG?541+jnEz+F>JLu-w_0}bS00bBW$RY7zFUvm%EJ$QVMX`D=G2CdZ927&^ z2_HL=f^u{P%X%o~g7y~j0)T6gj)`Q%g2o7$pb;wbk-#OBC3^fdH4uOQ%^J9m?pB%} zO=gg7WO)yjK8b<)+6NWzK2mRwB69jJil*!Sl*MsG$@x&ZAIbx=pKJIJ8;O_2leBRF zRS2?K=JsVjTvW?IfyCT|pstPiVcI_LT+`BfG#CQeNt?DNSRBrP3eO9RQEO@~#EG4p zzi)%;FWX&+vbz_*u)i+)u~wF^SpUgB;)$U?nBs*O+dP*J0=+u_Jol%?hx*{ZchB~W zs9G!tZ0dWhJ&rHcbbBYWu`tFoFQn9jF{H^2R!{D3!uo=!%n|oya$DD3nr&NC z3<3*?Xq#y(RLb&^b*xmi(4?8CH{Co5+Qkk9$n zmCXs}tJ8I72Mde}j^-kSY(gFw2HYEgy0aCYo=Hsv)(8TC-)m5ia>y(#<58NzE%` znZCmmY1y3nU^A5UJ=ASZXPx=p*WAFbI#5y6B|uEyQ>_7$RW{}Zb3u!0C8q!h!3;*B zvd&+Ps66Qy`{nCqvX_Zv-426X4kaTmtNF}y6!JHzcV=vRpxNbkO2PgDEqCPKT1~3;r`se>XHDn-dJ($w7@t#2=UR%88ap-q!o(ed6 za(kh-K46v4U--}l#GtL@os2K9L~`AYo)t!2I?YuwyVx6R4XCz@i_|kaw&Cc;$Q+p5 zUs={2bKmAC!z+CB#W9GZxYeuq_s*z#ON#e8pk_E5W%w<&Z&&#UTxfZ6X=qfHeOfZR5Xfvt9f`radTZ#xKfq}AB25m$4mC1{NwY$%tmKSRUf7i@d zzEEjdS>@&~_vN5+Qqorx;!r--H=weDx*9YzlJXIK)ae3~%wZ#IzHTV=O(L;1-u*Q6 z$u7Z^SihFUO#2je3V-EdY~Fmf_&VG2y#j%co9UV3=2(#o+oFudgf29;7*|#+GpWRP z2fQj4QciyXnb>z8(5~5GtVCQno>UYt62N7Y>dk^B?PQBa&41G`4V7G(#f7*(J|v3F#^N18V6!IvIJHV-RW*S0QQpl1%7)<9x{ zx(Ie;DS(mtTjV6Vl3e0fH*Y}#=lIX_wnGU_Q)*LmPs^X4k?G3fg!R7nN_TZYbP`78 z$3Wyq02rMBWK{A^9N!G%-~;kw?sDZHpR0`rHMn}3>{G4DP7Mh=)iyB@?9u2map$Iw z=eRW&remuCC+Fl78qg`S8buPGx;AUfn$h*Kp}93)Q*^Hf&DPv#`Nx!cz{ID8mLbQi z`Fy9`A|rfiw&Mp`_+kFD>ErfQ?E%HVcCF|*1&K&o!!#iLpmL&GB}n^^8?@6mX;-rj zy@&dhBtPizh|=|@pc{XS8?ORGZyhKb2?e(+M!seB_vTD`bKdBhux`(dcs*^?1B8Ep z%518L-w>#TC$hnV#a3r&R9;?wS#->)Lu2CM-AsMHQBdKT=ZF^JWxP_tx~c$!{^pFlU~RR>+{<8}D3>hN zvL$fW!ppS?-Op{Iui9)E4%>pJ^rX%a*MI2YU)6G^gMWwJ*3r!C(7HGc-z|7Z^+1 zB^{%ZMMZ!3))7oT(>LDR5D6OotWQ;rYGU;pO8}WIA4+(yox<0W36;zi5}9d@IzF zo4R`nzK{T*FY36!)_$M<>!w4ujHIo!YH;(TIf{gYrOt($QM}U311(0$o2_k1?q@fB zZst1zR7HM=AF9F|-40mdl~%Y>1KYh2p02zQPoI1Z{#(VnvC5Ovwl_Fj2+=CKE)n4% zI)JczBKiqJ#%{r+UfmY)$_g6uAb;vGK&{gwOJCQeGImQ~Gc-u&;6+~5E`-{vCc6DD z4J1UZIS8W;Gx5FmdQ$zn26G)xLn4Ka;Y_w_JU27qw56NGxLFPY1@rC9RC-R-Z7s+X z)M@c^()i&XV~yxte2{>+HMT_VQL%O*5;xmvU+&bE_|15zVSjmtZ|WlU(DfoPym$VM zC<*`o#TNSgq?w_ySpF&eHokOx|0 zHu9y;5&l(1(sQ#r9S>_E<6W$G)8*#xi0kDv9>eqH+8eY7B&6iMG28Fq$pI)8trA2D zKgRbgKv*1KSYt+g92PWA92|U8QGi;VZMMrJFwiggu@*++ExyZnvJ>l@(R2_QJyST0 zO1V1N2!pR=1{9kYB<8F;hjplT4!QY?RE+CAp_8Hv231oCc@?#yN9q}cli0@l8(sQ{ z@;{cwtoF4{u|Icy@#}rAXs-fiJxC!)&xWhmw<@(#oD8GXbh+IfJx+WN(P3F;j%$RD z#7XY#MJn+ezW7hw_cX447S&T@TB9|QpvM=YOF9YWLPGK>e7)>mkw5$Ku%t;gz$(r0 zt=;-Nx1W3pv(10KCcd2TQ&2v}Gv{Po;(0fI*dmCK+`cc`KNQCQKw8WU4m~Zuv>g@K zu;8KD-y|r{kL_!lej$sl-HVGV_IXDJC=4$vYOcR5fbDI-+2@t9ljz%bhqlpgyM>f! zj=kb&1*^s|U0LN0e07deLOXjAoY##HszP6Omu(FJ+9MIwjE)TT`uhzE!?h3ReM#My ziq$dV8LGoa>!Q0NE-t)j{?>Rm?1*CD-ahaj_{mz@Rmxb!O}G9IoFcJkL?~kFeRlWJ z2?H%6oa6p@wgQLSYJf~mcp|2I(7^Qn9SF(P8pSaQjV98&O`h#@?pfv`-Zky|d48+6L%SuSb+veBovNb(}*;^mB6W?~zZ9i{b z(nMevr;NK%KawS~1th^_WJBdvr70l|-3|OYfL^AT&|1QePpe$3tS=7xrg zK9K6mt6oQ5pO0<#GY5*TF=`k@#S3|Z&B9G0R3C&5 z_iYB%t{PCkNKj^i3oOPJcyLV^+7|-34R3^C*-Dt1Pi$UY=%~Yf3HWFDQ2p`*8SHwf zC{VJtn)-9y?$J6scUEFQ$AFPW(Fa1k#nn=4v{m+20YKoK03@v=q*bLgJ&=P2cgHz0 zH`>3nvz*P;Mj9H_5lWFGhAt@DN>^s`2=$+$8CR&jDW`joVYS3;xk-@U>o9G|l`CB> zDCABr<&4LPuZMzTwxqIbGw zH3JN`ZvpklnrA??AVQ_YJARg0>8=VZm@rFmK-XS^V*d~Ol||C^rAMA+Jp9UHV*GMs0eh0q(=pZ*_Zbz3rM1SURmNKGZoaTMD6^E@`*WdCbq9vnQP%^+|jtu57GtR*QK4i zPPB66TmFFTxEBmGS?|K$ulYFtobz3!!AZs@X{Xy=fqny$%YUG$hfpJQO7wpu5&FA9 z>0bqq2o=_)u6qASwvD>(#eWsR90$ncKZ@|M5rTTD{*S2EMDevelopment Notes

      -
    • HID Support
      +
    • HID Support
      Cupcake features some early work—Bluez has an HID plugin, external/bluez/utils/input/Android.mk, which gets compiled.

      You can interact directly with this plugin using dbus-send and dbus-monitor. While not officially supported, you should be able to connect and use a HID keyboard and mouse using the Bluez HID plugin API. Next steps include plumbing the plugin API in the Android Java framework and offering better support for HID input methods (new keymaps and mouse support).
      diff --git a/pdk/docs/porting/bluetooth/bluetooth_process.jd b/pdk/docs/porting/bluetooth/bluetooth_process.jd index ea46f231e..00ec0daa1 100755 --- a/pdk/docs/porting/bluetooth/bluetooth_process.jd +++ b/pdk/docs/porting/bluetooth/bluetooth_process.jd @@ -1,6 +1,6 @@ page.title=Bluetooth Process Diagram pdk.version=1.0 -doc.type=guide +doc.type=porting @jd:body

      The diagram below offers a process-oriented architectural overview of Android's Bluetooth stack. Click Bluetooth to return to the Bluetooth overview page.

      diff --git a/pdk/docs/porting/bring_up.jd b/pdk/docs/porting/bring_up.jd index 022c18534..1d04b8602 100755 --- a/pdk/docs/porting/bring_up.jd +++ b/pdk/docs/porting/bring_up.jd @@ -264,7 +264,7 @@ runs a service. Options are described in the table below:

    Properties

    - Init updates some system properties to provide some insight into
    + Init updates some system properties to provide some insight into
    what it's doing:

    diff --git a/pdk/docs/porting/build_system.jd b/pdk/docs/porting/build_system.jd index e5811bd4f..686fba0d5 100755 --- a/pdk/docs/porting/build_system.jd +++ b/pdk/docs/porting/build_system.jd @@ -211,7 +211,7 @@ currently-defined build variants:
    - + diff --git a/pdk/docs/source/building-dream.jd b/pdk/docs/source/building-dream.jd index 71b4f5890..f5472ce4e 100644 --- a/pdk/docs/source/building-dream.jd +++ b/pdk/docs/source/building-dream.jd @@ -1,9 +1,12 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Building for ADP1 doc.type=source @jd:body -

    Building For Dream -

    -
    The basic manifest for cupcake (and above) defines which projects are needed to do a generic build for the emulator or for unlocked Dream devices (e.g. the Android Dev Phone 1). You need to have an appropriate device running a matching official image.

    To build donut or master for dream (your device needs to be an ADP1 running an official 1.6 system):
    1. Follow thenormal steps +
      The basic manifest for cupcake (and above) defines which projects are +needed to do a generic build for the emulator or for unlocked Dream devices +(e.g. the Android Dev Phone 1). You need to have an appropriate device running +a matching official image.

      To build donut or master for dream (your +device needs to be an ADP1 running an official 1.6 system):
      1. Follow +the normal steps to setup repo and check out the sources.
      2. At the root of your source tree, run ". build/envsetup.sh" like you normally would for an emulator build. @@ -17,7 +20,7 @@ to setup repo and check out the sources.
      3. from this point, the fastboot tool (which is put automatically in your path) can be used to flash a device: boot the device into the bootloader by holding the back key while pressing the power key, and run "fastboot -w flashall".
      -To build cupcake for dream (your device needs to be an ADP1 running an official 1.5 system):
      1. Follow thenormal steps +To build cupcake for dream (your device needs to be an ADP1 running an official 1.5 system):
        1. Follow the normal steps to setup repo and check out the sources.
        2. At the root of your source tree, run ". build/envsetup.sh" like you normally would for an emulator build. diff --git a/pdk/docs/source/cla-corporate.jd b/pdk/docs/source/cla-corporate.jd index 5ddfe6f0b..0f9452b80 100644 --- a/pdk/docs/source/cla-corporate.jd +++ b/pdk/docs/source/cla-corporate.jd @@ -1,13 +1,11 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Corporate Contributor License Agreement doc.type=source @jd:body -

          Corporate Contributor License Grant - Android Open Source Project -

          In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose.

          This version of the Grant allows an entity (the "Corporation") to submit Contributions to the Project Leads, to authorize Contributions submitted by its designated employees to the Project Leads, and to grant copyright and patent licenses thereto. If you have not already done so, please complete and send an original signed Grant to

          -
          Google Inc.
          Attn: Open Source Program Office
          1600 Amphitheatre Pkwy
          Building 43
          Mountain View, CA 94043
          U.S.A.
          +
          Google Inc.
          Attn: Open Source Program Office
          1600 Amphitheatre Pkwy
          Building 43
          Mountain View, CA 94043
          U.S.A.

          Scanned agreements may also be emailed in PDF form to cla-submissions@google.com

          If necessary, you may send it by facsimile to (650) 887-1625. Please read this document carefully before signing and keep a copy for your records. diff --git a/pdk/docs/source/cla-individual.jd b/pdk/docs/source/cla-individual.jd index 1433318b6..8890be87e 100644 --- a/pdk/docs/source/cla-individual.jd +++ b/pdk/docs/source/cla-individual.jd @@ -1,16 +1,14 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Contributor License Agreement for Individuals doc.type=source @jd:body -

          Individual Contributor License Grant - Android Open Source Project -

          -

          Please visit thecode review tool +

          Please visit the code review tool to execute the grant online.This page provides the text of the Individual Contributor License Grant for your quick review.


          In order to clarify the intellectual property license granted with Contributions from any person or entity, the Android Open Source Project (the "Project") must have a Contributor License Grant ("Grant") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Project and the Android Open Source Project Leads (the "Project Leads"); it does not change your rights to use your own Contributions for any other purpose. If you have not already done so, please complete and send an original signed Grant to

          -
          Google Inc.
          Attn: Open Source Program Office
          1600 Amphitheatre Pkwy
          Building 43
          Mountain View, CA 94043
          U.S.A.
          -

          Scanned agreements may also be emailed in PDF form to cla-submissions@google.com, sent by facsimile to (650) 887-1625, orsigned electronically +

          Google Inc.
          Attn: Open Source Program Office
          1600 Amphitheatre Pkwy
          Building 43
          Mountain View, CA 94043
          U.S.A.
          +

          Scanned agreements may also be emailed in PDF form to cla-submissions@google.com, sent by facsimile to (650) 887-1625, or signed electronically .

          Please read this document carefully before signing and keep a copy for your records. diff --git a/pdk/docs/source/code-lines.jd b/pdk/docs/source/code-lines.jd new file mode 100644 index 000000000..61b400d5e --- /dev/null +++ b/pdk/docs/source/code-lines.jd @@ -0,0 +1,77 @@ +page.title=Android Code-Lines +doc.type=source +@jd:body +

          The Android Open Source Project maintains a complete software stack intended +to be ported by OEMs and other device implementors to run on actual hardware. +Accordingly, we maintain a number of "code lines" to clearly separate the +current stable version of Android from unstable experimental work.

          +

          The chart below depicts at a conceptual level how AOSP manages code and +releases. We're referring to these as "code lines" instead of "branches" +simply because at any given moment there may be more than one branch extant +for a given "code line". For instance, when a release is cut, sometimes that +will become a new branch in git, and sometimes not, based on the needs of the +moment.

          + +

          Notes and Explanations

          +
            +
          • A release corresponds to a formal version of the Android platform, such +as 1.5, 2.0, and so on. Generally speaking, a release of the platform +corresponds to a version of the SdkVersion field used in +AndroidManifest.xml files, and defined in frameworks/base/api in +the source tree.
            • +
          • An upstream project is an open-source project from which the Android +stack is pulling code. These include obvious projects such as the Linux kernel +and WebKit, but over time we are migrating some of the semi-autonomous +Android projects (such as Dalvik, the Android SDK tools, Bionic, and so on) to +work as "upstream" projects. These will be developed entirely in the public +tree, and snapshots will be periodically pulled into releases.
            • +
          • The diagram refers to "Eclair" and "Flan"; however, they are simply +placeholders, and the diagram actually reflects the overall release and +branching strategy.
            • +
          • At all times, the Release code-line (which may actually consist of +more than one actual branch in git) is considered the sole canonical source +code for a given Android platform. OEMs and other groups building devices +should pull only from a Release branch.
            • +
          • We will be setting up an "Experimental" code-line to capture changes from +the community, so that they can be iterated on, with an eye toward stability.
            • +
          • Changes that prove stable will eventually be pulled into a Release +branch. Note that this will only apply to bug fixes, app improvements, and +other things that do not affect the APIs of the platform.
            • +
          • Changes will be pulled into Release branches from upstream projects +(include the Android "upstream" projects) as necessary.
            • +
          • The "n+1"th version (that is, next major version of the framework and +platform APIs) will be developed by Google internally. (See below for +details.)
            • +
          • Changes will be pulled from upstream, Release, and Experimental branches +into Google's private branch as necessary.
            • +
          • When the platform APIs for the next version have stabilized and been fully +tested, Google will cut a release of the next platform version. (This +specifically refers to a new SdkVersion.) This will also +correspond to the internal code-line being made a public Release branch, and the +new current platform code-line.
            • +
          • When a new platform version is cut, a corresponding Experimental +code-line.
            • +
          +

          About Private Code-Lines

          +

          The source management strategy above includes a code-line that Google will +keep private. The reason for this is to focus attention on the current public +version of Android.

          +

          OEMs and other device builders naturally want to ship devices with the +latest version of Android. Similarly, application developers don't want to +deal with more extant platform versions than strictly necessary. Meanwhile, +Google retains responsibility for the strategic direction of Android as a +platform and a product. Our approach is based on focusing on a small number of +flagship devices to drive features, and secure protections of Android-related +intellectual property through patents and the like.

          +

          As a result, Google frequently has possession of confidential +information of third parties, and we must refrain from revealing patentable +features until we've secured the appropriate protections. Meanwhile, there are +real risks to the platform arising from having too many platform versions +extant at once. For these reasons, we have structured the open-source project +-- including third-party contributions -- to focus on the currently-public +stable version of Android. "Deep development" on the next version of the +platform will happen in private, until it's ready to become an official +release.

          +

          We recognize that many contributors will disagree with this approach. We +respect that others may have a different point of view; however, this is the +approach that we feel is best, and the one we've chosen to implement.

          diff --git a/pdk/docs/source/code-style.jd b/pdk/docs/source/code-style.jd index 540ac997e..3122ea88c 100644 --- a/pdk/docs/source/code-style.jd +++ b/pdk/docs/source/code-style.jd @@ -1,8 +1,6 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Code Style Guidelines for Contributors doc.type=source @jd:body -

          Code Style Guide -

          Android Code Style Rules

          The rules below are not guidelines or recommendations, but strict rules.You may not disregard the rules we list below @@ -29,12 +27,12 @@ except as approved on a need-to-use basis.

        Java Library Rules

        -

        There are conventions for using Android's Java libraries and tools. In some cases, the convention has changed in important ways and older code might use a deprecated pattern or library. When working with such code, it's okay to continue the existing style (seeConsistency +

        There are conventions for using Android's Java libraries and tools. In some cases, the convention has changed in important ways and older code might use a deprecated pattern or library. When working with such code, it's okay to continue the existing style (see Consistency ). When creating new components never use deprecated libraries.

        Java Style Rules

        -

        Programs are much easier to maintain when all files have a consistent style. We follow the standard Java coding style, as defined by Sun in theirCode Conventions for the Java Programming Language +

        Programs are much easier to maintain when all files have a consistent style. We follow the standard Java coding style, as defined by Sun in their Code Conventions for the Java Programming Language , with a few exceptions and additions. This style guide is comprehensive and detailed and is in common usage in the Java community.

        In addition, we enforce the following style rules: @@ -108,7 +106,7 @@ Sometimes it is tempting to write code that completely ignores an exception like 

        void setServerPort(String value) throws ConfigurationException {
        try {
        serverPort = Integer.parseInt(value);
        } catch (NumberFormatException e) {
        throw new ConfigurationException("Port " + value + " is not valid.");
        }

      2. Handle the error gracefully and substitute an appropriate value in the catch {} block. -
        /** Set port. If value is not a valid number, 80 is substituted. */
        void setServerPort(String value) {
        try {
        serverPort = Integer.parseInt(value);
        } catch (NumberFormatException e) {
        serverPort = 80;  // default port for server
        }
        +
        /** Set port. If value is not a valid number, 80 is substituted. */
        void setServerPort(String value) {
        try {
        serverPort = Integer.parseInt(value);
        } catch (NumberFormatException e) {
        serverPort = 80;  // default port for server 
        }
      3. Catch the Exception and throw a new RuntimeException. This is dangerous: only do it if you are positive that if this error occurs, the appropriate thing to do is crash. 
        /** Set port. If value is not a valid number, die. */
        void setServerPort(String value) {
        try {
        serverPort = Integer.parseInt(value);
        } catch (NumberFormatException e) {
        throw new RuntimeException("port " + value " is invalid, ", e);
        }
        @@ -120,7 +118,7 @@ Note that the original exception is passed to the constructor for RuntimeExcepti

        Exceptions: do not catch generic Exception

        Sometimes it is tempting to be lazy when catching exceptions and do something like this: -
        try {
        someComplicatedIOFunction();        // may throw IOException
        someComplicatedParsingFunction();   // may throw ParsingException
        someComplicatedSecurityFunction();  // may throw SecurityException
        // phew, made it all the way
        } catch (Exception e) {               // I'll just catch all exceptions
        handleError();                      // with one generic handler!
        }

        +
        try {
        someComplicatedIOFunction();        // may throw IOException 
        someComplicatedParsingFunction();   // may throw ParsingException 
        someComplicatedSecurityFunction();  // may throw SecurityException 
        // phew, made it all the way 
        } catch (Exception e) {               // I'll just catch all exceptions 
        handleError();                      // with one generic handler!
        }

        You should not do this. In almost all cases it is inappropriate to catch generic Exception or Throwable, preferably not Throwable, because it includes Error exceptions as well. It is very dangerous. It means that Exceptions you never expected (including RuntimeExceptions like ClassCastException) end up getting caught in application-level error handling. It obscures the failure handling properties of your code. It means if someone adds a new type of Exception in the code you're calling, the compiler won't help you realize you need to handle that error differently. And in most cases you shouldn't be handling different types of exception the same way, anyway.

        There are rare exceptions to this rule: certain test code and top-level code where you want to catch all kinds of errors (to prevent them from showing up in a UI, or to keep a batch job running). In that case you may catch generic Exception (or Throwable) and handle the error appropriately. You should think very carefully before doing this, though, and put in comments explaining why it is safe in this place.

        @@ -176,17 +174,17 @@ Wildcards in imports

        Every file should have a copyright statement at the top. Then a package statement and import statements should follow, each block separated by a blank line. And then there is the class or interface declaration. In the Javadoc comments, describe what the class or interface does.

        -
        /*
        * Copyright (C) 2007 The Android Open Source Project
        *
        * Licensed under the Apache License, Version 2.0 (the "License");
        * you may not use this file except in compliance with the License.
        * You may obtain a copy of the License at
        *
        *      http://www.apache.org/licenses/LICENSE-2.0
        *
        * Unless required by applicable law or agreed to in writing, software
        * distributed under the License is distributed on an "AS IS" BASIS,
        * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
        * See the License for the specific language governing permissions and
        * limitations under the License.
        */

        package com.android.internal.foo;

        import android.os.Blah;
        import android.view.Yada;

        import java.sql.ResultSet;
        import java.sql.SQLException;

        /**
        * Does X and Y and provides an abstraction for Z.
        */
        public class Foo {
        ...
        }
        -

        Every class and nontrivial public method you writemust +

        /*
        * Copyright (C) 2007 The Android Open Source Project 
        *
        * Licensed under the Apache License, Version 2.0 (the "License");
        * you may not use this file except in compliance with the License.
        * You may obtain a copy of the License at 
        *
        *      http://www.apache.org/licenses/LICENSE-2.0
        *
        * Unless required by applicable law or agreed to in writing, software 
        * distributed under the License is distributed on an "AS IS" BASIS,
        * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
        * See the License for the specific language governing permissions and 
        * limitations under the License.
        */

        package com.android.internal.foo;

        import android.os.Blah;
        import android.view.Yada;

        import java.sql.ResultSet;
        import java.sql.SQLException;

        /**
        * Does X and Y and provides an abstraction for Z.
        */
        public class Foo {
        ...
        }
        +

        Every class and nontrivial public method you write must contain a Javadoc comment with at least one sentence describing what the class or method does. This sentence should start with a 3rd person descriptive verb. Examples:

        -
        /** Returns the correctly rounded positive square root of a double value. */
        static double sqrt(double a) {
        }

        /**
        * Constructs a new String by converting the specified array of
        * bytes using the platform's default character encoding.
        */
        public String(byte[] bytes) {
        }
        +
        /** Returns the correctly rounded positive square root of a double value. */
        static double sqrt(double a) {
        }

        /**
        * Constructs a new String by converting the specified array of 
        * bytes using the platform's default character encoding.
        */
        public String(byte[] bytes) {
        }

        You do not need to write Javadoc for trivial get and set methods such as setFoo() if all your Javadoc would say is "sets Foo". If the method does something more complex (such as enforcing a constraint or having an important side effect), then you must document it. And if it's not obvious what the property "Foo" means, you should document it.

        Every method you write, whether public or otherwise, would benefit from Javadoc. Public methods are part of an API and therefore require Javadoc.

        -Android does not currently enforce a specific style for writing Javadoc comments, but youshould -follow theSun Javadoc conventions +Android does not currently enforce a specific style for writing Javadoc comments, but you should +follow the Sun Javadoc conventions .

        Short methods

        @@ -199,10 +197,10 @@ Item 29). By doing so, you increase the readability and maintainability of your

        One exception to this rule concerns try-catch statements. If a variable is initialized with the return value of a method that throws a checked exception, it must be initialized inside a try block. If the value must be used outside of the try block, then it must be declared before the try block, where it cannot yet be sensibly initialized:

        -
        // Instantiate class cl, which represents some sort of Set
        Set s = null;
        try {
        s = (Set) cl.newInstance();
        } catch(IllegalAccessException e) {
        throw new IllegalArgumentException(cl + " not accessible");
        } catch(InstantiationException e) {
        throw new IllegalArgumentException(cl + " not instantiable");
        }

        // Exercise the set
        s.addAll(Arrays.asList(args));
        +
        // Instantiate class cl, which represents some sort of Set 
        Set s = null;
        try {
        s = (Set) cl.newInstance();
        } catch(IllegalAccessException e) {
        throw new IllegalArgumentException(cl + " not accessible");
        } catch(InstantiationException e) {
        throw new IllegalArgumentException(cl + " not instantiable");
        }

        // Exercise the set 
        s.addAll(Arrays.asList(args));

        But even this case can be avoided by encapsulating the try-catch block in a method:

        -
        Set createSet(Class cl) {
        // Instantiate class cl, which represents some sort of Set
        try {
        return (Set) cl.newInstance();
        } catch(IllegalAccessException e) {
        throw new IllegalArgumentException(cl + " not accessible");
        } catch(InstantiationException e) {
        throw new IllegalArgumentException(cl + " not instantiable");
        }
        }
        ...
        // Exercise the set
        Set s = createSet(cl);
        s.addAll(Arrays.asList(args));
        +
        Set createSet(Class cl) {
        // Instantiate class cl, which represents some sort of Set 
        try {
        return (Set) cl.newInstance();
        } catch(IllegalAccessException e) {
        throw new IllegalArgumentException(cl + " not accessible");
        } catch(InstantiationException e) {
        throw new IllegalArgumentException(cl + " not instantiable");
        }
        }
        ...
        // Exercise the set 
        Set s = createSet(cl);
        s.addAll(Arrays.asList(args));
        Loop variables should be declared in the for statement itself unless there is a compelling reason to do otherwise: 
        for (int i = 0; i n; i++) {
        doSomething(i);
        }

        for (Iterator i = c.iterator(); i.hasNext(); ) {
        doSomethingElse(i.next());
        }


        Imports @@ -232,9 +230,9 @@ The use and location of static imports have been mildly controversial issues. So

        We use 8 space indents for line wraps, including function calls and assignments. For example, this is correct:

        -
        Instrument i
        = someLongExpression(that, wouldNotFit, on, one, line);
        +
        Instrument i 
        = someLongExpression(that, wouldNotFit, on, one, line);
        and this is not correct: -
        Instrument i
        = someLongExpression(that, wouldNotFit, on, one, line);
        +
        Instrument i 
        = someLongExpression(that, wouldNotFit, on, one, line);

        Field Names

        • Non-public, non-static field names start with m. @@ -256,10 +254,10 @@ and this is not correct: 
          class MyClass {
          int func() {
          if (something) {
          // ...
          } else if (somethingElse) {
          // ...
          } else {
          // ...
          }
          }
          }

          We require braces around the statements for a conditional. Except, if the entire conditional (the condition and the body) fit on one line, you may (but are not obligated to) put it all on one line. That is, this is legal:

          -
          if (condition) {
          body; // ok
          }
          if (condition) body; // ok
          +
          if (condition) {
          body; // ok 
          }
          if (condition) body; // ok

          but this is still illegal:

          -
          if (condition)
          body; // bad
          +
          if (condition)
          body; // bad

          Line length

          Each line of text in your code should be at most 100 characters long. @@ -277,18 +275,18 @@ Java 1.5 Annotations

          Android -standard practices for the three predefined annotations in Java 1.5's are:

          -@DeprecatedThe @Deprecated annotation must be used whenever the use of the annotated element is discouraged. If you use the @Deprecated annotation, you must also have a @deprecated Javadoc tag and it should name an alternate implementation. In addition, remember that a @Deprecated method isstill +@DeprecatedThe @Deprecated annotation must be used whenever the use of the annotated element is discouraged. If you use the @Deprecated annotation, you must also have a @deprecated Javadoc tag and it should name an alternate implementation. In addition, remember that a @Deprecated method is still supposed to work.

          If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.

          @OverrideThe @Override annotation must be used whenever a method overrides the declaration or implementation from a super-class.

          For example, if you use the {@inheritdocs} Javadoc tag, and derive from a class (not an interface), you must also annotate that the method @Overrides the parent class's method.

          -@SuppressWarningsThe @SuppressWarnings annotation should only be used under circumstances where it is impossible to eliminate a warning. If a warning passes this "impossible to eliminate" test, the@SuppressWarnings annotationmust +@SuppressWarningsThe @SuppressWarnings annotation should only be used under circumstances where it is impossible to eliminate a warning. If a warning passes this "impossible to eliminate" test, the@SuppressWarnings annotation must be used, so as to ensure that all warnings reflect actual problems in the code.

          When a @SuppressWarnings annotation is necessary, it must be prefixed with a TODO comment that explains the "impossible to eliminate" condition. This will normally identify an offending class that has an awkward interface. For example:

          -
          // TODO: The third-party class com.third.useful.Utility.rotate() needs generics
          @SuppressWarnings({"generic-cast"})
          ListStringblix = Utility.rotate(blax);
          +
          // TODO: The third-party class com.third.useful.Utility.rotate() needs generics 
          @SuppressWarnings({"generic-cast"})
          ListStringblix = Utility.rotate(blax);
          When a @SuppressWarnings annotation is required, the code should be refactored to isolate the software elements where the annotation applies.

          Acronyms in names

          @@ -336,8 +334,8 @@ When a @SuppressWarnings annotation is required, the code should be refactored t

          Both the JDK and the Android code bases are very inconsistent with regards to acronyms, therefore, it is virtually impossible to be consistent with the code around you. Bite the bullet, and treat acronyms as words.

          -

          For further justifications of this style rule, seeEffective Java -Item 38 andJava Puzzlers +

          For further justifications of this style rule, see Effective Java +Item 38 and Java Puzzlers Number 68.

          TODO style diff --git a/pdk/docs/source/documentation.jd b/pdk/docs/source/documentation.jd index 8be570173..4eae07184 100644 --- a/pdk/docs/source/documentation.jd +++ b/pdk/docs/source/documentation.jd @@ -1,14 +1,12 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Documentation Resources doc.type=source @jd:body -

          Documentation -

          -

          +

          As this page grows, it will include resources for wireless operators and handset manufacturers as well as for platform developers.

          -Resources for platform developers +Resources for platform developers

          - + Google I/O videos:
          - + Getting started with the Android source code:
          - + Repo and Git resources:
          - + Documentation on specific tasks:
          diff --git a/pdk/docs/source/download.jd b/pdk/docs/source/download.jd index 9f675121d..065a70897 100644 --- a/pdk/docs/source/download.jd +++ b/pdk/docs/source/download.jd @@ -1,83 +1,16 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Get Android Source Code doc.type=source @jd:body -

          Get source - -

          -
    - eng + eng This is the default flavor. A plain make is the @@ -230,7 +230,7 @@ currently-defined build variants:
    - user + user make user @@ -248,7 +248,7 @@ currently-defined build variants:
    - userdebug + userdebug make userdebug diff --git a/pdk/docs/porting/index.jd b/pdk/docs/porting/index.jd index 9d23fbe4c..76609d222 100644 --- a/pdk/docs/porting/index.jd +++ b/pdk/docs/porting/index.jd @@ -21,7 +21,7 @@ doc.type=porting

    If you are new to Android, start with the platform documentation on the following sites:

    When you are ready to start customizing the platform or porting to your target hardware, start in this guide with the Build System overview.

    diff --git a/pdk/docs/porting/power_management.jd b/pdk/docs/porting/power_management.jd index 542459da8..28f951983 100755 --- a/pdk/docs/porting/power_management.jd +++ b/pdk/docs/porting/power_management.jd @@ -103,7 +103,7 @@ Solid elements represent Android blocks and dashed elements represent partner-sp     		Description
    ACQUIRE_CAUSES_WAKEUP
    		ACQUIRE_CAUSES_WAKEUP
    		Normally wake locks don't actually wake the device, they just cause it to remain on once it's already on. Think of the video player app as the normal behavior. Notifications that pop up and want the device to be on are the exception; use this flag to be like them.
    - - -
    For information about current problems and fixes, see Known issues -.
    -

    This document describes how to set up your local work environment, how to use Repo to get the Android files, and how to build the files on your machine.

    Related reading:
    -
    • For an overview of the entire code-review and code-update process, see Workflow +

      What's in the source?

      -
      For a description of all the projects that make up the Android source code, see Project layout -. To see snapshots and histories of the files available in the public Android repositories, visit the GitWeb +
      To see snapshots and histories of the files available in the public Android repositories, visit the GitWeb web interface.
      The source is approximentely 2.1GB in size.You will need 6GB free to complete the build.

      @@ -241,7 +174,9 @@ file:
      # set the number of open files to be 1024
      ulimit -S -n 1024

      • Installing Repo

      -

      Repo is a tool that makes it easier to work with Git in the context of Android. For more information about Repo, see Using Repo and Git +

      Repo is a tool that makes it easier to work with Git in the context of +Android. For more information about Repo, see Using Repo and Git .

      To install, initialize, and configure Repo, follow these steps:

      1. Make sure you have a~/bindirectory in your home directory, and check to be sure that this bin directory is in your path: @@ -304,10 +239,10 @@ Getting the files
        To pull down files to your working directory from the repositories as specified in the default manifest, run

        $ repo sync

        For more aboutrepo syncand other Repo commands, see -Using Repo and Git +Using Repo and Git . -

        The Android source files will be located in your working directory under their project -names. +

        The Android source files will be located in your working +directory under their project names.

        @@ -335,7 +270,7 @@ Building the code

        $ export ANDROID_JAVA_HOME=$JAVA_HOME

        Using an IDE

        -
        • Using Eclipse +

          @@ -357,9 +292,10 @@ What's next?

          To learn about reporting an issue and searching previously reported issues, see -Report bugs +Report bugs . -For information about editing the files and uploading changes to the code-review server, see Contribute +For information about editing the files and uploading changes to the +code-review server, see Contribute .
      diff --git a/pdk/docs/source/git-repo.jd b/pdk/docs/source/git-repo.jd index cc996260d..97bd2eaf8 100644 --- a/pdk/docs/source/git-repo.jd +++ b/pdk/docs/source/git-repo.jd @@ -1,104 +1,11 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Using Repo and Git doc.type=source @jd:body -

      Using Repo and Git -

      -

      To work with the Android code, you will need to use both Git and Repo.

      • Git is an open-source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits.

      • Repo -is a tool that we built on top of Git. Repo helps us manage the many Git repositories, does the uploads to ourrevision control system +is a tool that we built on top of Git. Repo helps us manage the many Git repositories, does the uploads to our revision control system , and automates parts of the Android development workflow. Repo is not meant to replace Git, only to make it easier to work with Git in the context of Android. The repocommand is an executable Python script that you can put anywhere in your path.

         In working with the Android source files, you will use Repo for across-network operations. For example, with a single Repo command you can download files from multiple repositories into your local working directory.
        • @@ -112,59 +19,59 @@ Why Git? One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbiest community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.

        Already a Git user?

        -In most situations, you can use Git instead of Repo, or mix Repo and Git commands to form complex commands. Using Repo for basic across-network operations will make your work much simpler, however. For more information about Git, see the list of resources on ourDocumentation +In most situations, you can use Git instead of Repo, or mix Repo and Git commands to form complex commands. Using Repo for basic across-network operations will make your work much simpler, however. For more information about Git, see the list of resources on our Documentation page.

      -Task reference

      -The task list below shows a summary of how to do common Repo and Git tasks. For complete quick-start information and examples, seeGet source +Task reference
      +The task list below shows a summary of how to do common Repo and Git tasks. For complete quick-start information and examples, see Get source .

      -Installing Repo

      -$ curl http://android.git.kernel.org/repo ~/bin/repo
      $ chmod a+x ~/bin/repo
      -$ mkdirworking-directory-name -
      $ cdworking-directory-name
       -$ repo init-u git://android.git.kernel.org/platform/manifest.git

      +Installing Repo

      +$ curl http://android.git.kernel.org/repo ~/bin/repo
      $ chmod a+x ~/bin/repo
      +$ mkdir working-directory-name +
      $ cd working-directory-name
      +$ repo init-u git://android.git.kernel.org/platform/manifest.git

      Synchronizing your client

      -To synchronize the files for all availableprojects -:
      $ repo sync

      To synchronize the files for selected projects:
      $ repo syncproject1 project2 ... +To synchronize the files for all available projects +:
      $ repo sync

      To synchronize the files for selected projects:
      $ repo sync project1 project2 ...

      Why use topic branches?

      -Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature.

      A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you canisolateone aspect of your work from the others. For an interesting article about using topic branches, seeSeparating topic branches +Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature.

      A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you canisolateone aspect of your work from the others. For an interesting article about using topic branches, see Separating topic branches .


      Creating topic branches

      -To start a topic branch using Repo:
      $ repo startbranchname -

      To verify that your new branch was created:
      $ repo status

      +To start a topic branch using Repo:
      $ repo start branchname +

      To verify that your new branch was created:
      $ repo status

      Using topic branches

      -To assign the branch to a particular project:
      $ repo startbranch +To assign the branch to a particular project:
      $ repo start branch name project -

      To switch back and forth among branches that you have created in your local work environment:
      $ git checkoutbranchname -

      To see a list of existing branches:
      $ git branch
      or...
      $ repo branches

      The name of the current branch will be preceded by an asterisk.

      +

      To switch back and forth among branches that you have created in your local work environment:
      $ git checkout branchname +

      To see a list of existing branches:
      $ git branch
      or...
      $ repo branches

      The name of the current branch will be preceded by an asterisk.

      Note:
      A bug might be causing repo sync to reset the local topic branch. If git branch shows * (no branch) after you run repo sync, then run git checkoutagain.

      Viewing client status

      -To list the state of your files:
      $ repo status

      To see uncommitted edits:
      $ repo diff

      Therepo diffcommand shows every local edit that you have made that wouldnot +To list the state of your files:
      $ repo status

      To see uncommitted edits:
      $ repo diff

      Therepo diffcommand shows every local edit that you have made that would not go into the commit, if you were to commit right now.

      To see every edit that would go into the commit if you were to commit right now, you need a Git command, git diff. Before running it, be sure you are down in the project directory:
      $ cd ~/workingdirectory /project -
      $ git diff --cached

      +
      $ git diff --cached

      Recovering sync conflicts

      If a repo sync shows sync conflicts:
      1. View the files that are unmerged (status code = U).
      2. Edit the conflict regions as necessary.
        3. -
      3. Change into the relevant project directory, run git add and git commit for the files in question, and then "rebase" the changes. For example:
        $ cd bionic
        $ git add bionic/*
        $ git commit
        $ git rebase --continue

        4. -
      4. When the rebase is complete start the entire sync again:
        $ repo syncbionicproj2 +
      5. Change into the relevant project directory, run git add and git commit for the files in question, and then "rebase" the changes. For example:
        $ cd bionic
        $ git add bionic/*
        $ git commit
        $ git rebase --continue

        6. +
      6. When the rebase is complete start the entire sync again:
        $ repo syncbionic proj2 proj3 ... @@ -172,13 +79,13 @@ If a repo sync shows sync conflicts:
        1. View the files that are unmerged

        -Cleaning up your client files

        -To update your local working directory after changes are merged in Gerrit:
        $repo sync

        To safely remove stale topic branches:
        $ repo prune

        +Cleaning up your client files

        +To update your local working directory after changes are merged in Gerrit:
        $repo sync

        To safely remove stale topic branches:
        $ repo prune

        Deleting a client

        -Deleting a client willpermanently delete -any changes you have not yet uploaded for review.Becauseall state information is stored in your client, you only need to delete the directory from your filesystem:

        $ cd~ -
        $ rm -rfworking-directory-name +Deleting a client will permanently delete +any changes you have not yet uploaded for review.Becauseall state information is stored in your client, you only need to delete the directory from your filesystem:

        $ cd ~ +
        $ rm -rf working-directory-name

        Scripting common tasks

        @@ -196,14 +103,14 @@ You can use Repo to run the same program across all projects:

        $ repo fora ]

        The -c argument is evaluated through /bin/sh and any arguments after it are passed through as shell positional parameters.

        Repo command reference

        -Repo usage takes the following form:
        repocommand options -

        Optional elements are shown in brackets[ ]. Once Repo is installed, you can get information about any command by running
        repo helpcommand +Repo usage takes the following form:
        repo command options +

        Optional elements are shown in brackets[ ]. Once Repo is installed, you can get information about any command by running
        repo help command

        init

        -repo init -uurl +repo init -u url [options -]

        Installs Repo in the current directory. This creates a .repo/ directory that contains Git repositories for the Repo source code and the standard Android manifest files. The .repo/ directory also containsmanifest.xml, which is a symlink to the selected manifest in the .repo/manifests/ directory.

        The -u argument specifies a URL from which to retrieve a manifest repository. For example:
        $ repo init -u git://android.git.kernel.org/platform/manifest.git

        To select a manifest file within the repository, use the -m option. (If no manifest name is selected, the default is default.xml.)For example:
        $ repo init -ugit://android.git.kernel.org/platform/manifest.git-m dalkvik-plus.xml

        To specify a revision, that is, a particular manifest-branch, use the -b option. For example:
        $ repo init -ugit://android.git.kernel.org/platform/manifest.git-b release-1.0

        To see other repo init options, run
        $ repo help init

        Note: +]

        Installs Repo in the current directory. This creates a .repo/ directory that contains Git repositories for the Repo source code and the standard Android manifest files. The .repo/ directory also containsmanifest.xml, which is a symlink to the selected manifest in the .repo/manifests/ directory.

        The -u argument specifies a URL from which to retrieve a manifest repository. For example:
        $ repo init -u git://android.git.kernel.org/platform/manifest.git

        To select a manifest file within the repository, use the -m option. (If no manifest name is selected, the default is default.xml.)For example:
        $ repo init -ugit://android.git.kernel.org/platform/manifest.git-m dalkvik-plus.xml

        To specify a revision, that is, a particular manifest-branch, use the -b option. For example:
        $ repo init -ugit://android.git.kernel.org/platform/manifest.git-b release-1.0

        To see other repo init options, run
        $ repo help init

        Note: For all remaining Repo commands, the current working directory must either be the parent directory of .repo/ or a subdirectory of the parent directory.

        sync @@ -220,8 +127,8 @@ repo sync [project-list
        When you run repo sync, this is what happens:
        1. If the project has never been synchronized, then repo sync is equivalent to git clone. All branches in the remote repository are copied to the local project directory.
          2. -
        2. If the project has already been synchronized once, then repo sync is equivalent to:
          git remote update
          git rebase origin/branch -
          wherebranch +
        3. If the project has already been synchronized once, then repo sync is equivalent to:
          git remote update
          git rebase origin/branch +
          where branch is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.

          If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, git rebase --continue) to resolve the conflicts.
        The repo sync command also updates the private repositories in the .repo/ directory.
        @@ -229,7 +136,7 @@ is the currently checked-out branch in the local project directory. If the local upload

        repo upload [project-list -]

        For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.

        After you select one or more branches, all commits on the selected branches are transmitted to Gerrit over an SSH connection.You will need to configure an SSH key to enable upload authorization.VisitSSH Keys +]

        For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.

        After you select one or more branches, all commits on the selected branches are transmitted to Gerrit over an SSH connection.You will need to configure an SSH key to enable upload authorization.Visit SSH Keys within the user settings panel to register your public keys with Gerrit.To enable password-less uploads, consider using ssh-agent on your client system.

        When Gerrit receives the object data over its SSH server, it will turn each commit into a change so that reviewers can comment on each commit individually.

        To combine several "checkpoint" commits together into a single commit, use git rebase -i before you run repo upload.

        You can specify project-list as a list of names or a list of paths to local source directories for the projects:
        repo upload [proj1 proj2 ... @@ -238,13 +145,13 @@ within the user settings panel to register your public keys with Gerrit.To enabl ]

        If you run repo upload without any arguments, it will search all the projects for changes to upload.

        To make edits to changes after they have been uploaded, you should use a tool likegit rebase -ior git commit --amend to update your local commits.

        After your edits are complete:
        1. Make sure the updated branch is the currently checked out branch.
          2. -
        2. Use repo upload --replaceproj1 +
        3. Use repo upload --replace proj1 to open the change matching editor.
        4. For each commit in the series, enter the Gerrit change Id inside the brackets:
        -
        # Replacing from branch foo
        [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
        [ 2829 ] ec18b4ba Update proto client to support patch set replacments
        [ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...
        # Insert change numbers in the brackets to add a new patch set.
        # To create a new change record, leave the brackets empty.

        After the upload is complete the changes will have an additional Patch Set (e.g. Patch Set 2, Patch Set 3, ...).
        +
        # Replacing from branch foo
        [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
        [ 2829 ] ec18b4ba Update proto client to support patch set replacments
        [ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...
        # Insert change numbers in the brackets to add a new patch set.
        # To create a new change record, leave the brackets empty.

        After the upload is complete the changes will have an additional Patch Set (e.g. Patch Set 2, Patch Set 3, ...).

        diff

        @@ -256,28 +163,28 @@ repo diff [project-list projN ]

        Options:
        -h, --helpmeans show this help message and exit.

        -download

        -repo downloadtarget +download
        +repo download target change -

        Downloads the specified change into the specified local directory. (Added to Repo as of version 1.0.4.)

        For example, to downloadchange 1241 +

        Downloads the specified change into the specified local directory. (Added to Repo as of version 1.0.4.)

        For example, to download change 1241 into your platform/frameworks/base directory:
        $ repo download platform/frameworks/base 1241

        A"repo sync"should effectively remove any commits retrieved via "repo download".Or, you can check out the remote branch; e.g., "git checkout m/master".

        Note: -As of Jan. 26, 2009, there is a mirroring lag of approximately 5 minutes between when a change is visible on the web inGerrit +As of Jan. 26, 2009, there is a mirroring lag of approximately 5 minutes between when a change is visible on the web in Gerrit and when repo download will be able to find it, because changes are actually downloaded off the git://android.git.kernel.org/ mirror farm. There will always be a slight mirroring lag as Gerrit pushes newly uploaded changes out to the mirror farm.

        forall

        repo forall [project-list -] -ccommand +] -c command [arg. -..]

        Runs a shell command in each project.

        You can specify project-list as a list of names or a list of paths to local source directories for the projects
        +..]

        Runs a shell command in each project.

        You can specify project-list as a list of names or a list of paths to local source directories for the projects

        help

        repo help [command ]

        Displays detailed help about a command.

        -prune

        +prune
        repo prune [project-list ]

        Prunes (deletes) topics that are already merged.

        You can specify project-list as a list of names or a list of paths to local source directories for the projects:
        repo prune [proj1 proj2 @@ -288,10 +195,10 @@ repo prune [project-list

        start

        -repo startnewbranchname +repo start newbranchname [project-list -]

        Starts a new branch for development.

        Thenewbranchname -argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.

        Theproject-list +]

        Starts a new branch for development.

        The newbranchname +argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.

        The project-list specifies which projects will participate in this topic branch. You can specify project-list as a list of names or a list of paths to local working directories for the projects:
        repo start default [proj1 proj2 ... @@ -307,7 +214,7 @@ repo status [project-list ... projN -]

        To see the status for only the current branch, run
        repo status .

        The status information will be listed by project. For each file in the project, a two-letter code is used:
        +]

        To see the status for only the current branch, run
        repo status .

        The status information will be listed by project. For each file in the project, a two-letter code is used:
        • In the left-most column, an uppercase letter indicates what is happening in the index (the staged files) when compared to the last committed state.

        • In the next column, a lowercase letter indicates what is happening in the working directory when compared to the index (what is staged).
          • @@ -321,11 +228,11 @@ repo status [project-list The file is added (brand new). Can only appear in the first column.
          -M or m
          +M or m
          The file already exists but has been modified in some way. -D or d
          +D or d
          The file has been deleted.
          R @@ -349,12 +256,12 @@ repo status [project-list - -The file state is unmodified. A hyphen inboth +The file state is unmodified. A hyphen in both columns means this is a new file, unknown to Git. After you run git add on this file, repo status will show A-, indicating the file has been added.
          -
          For example, if you edit the file main.py within the appeng project without staging the changes, then repo status might show

          project appeng/
          -mmain.py

          If you go on to stage the changes to main.py by running git add, then repo status might show

          project appeng/
          M- main.py

          If you then make further edits to the already-staged main.py and make edits to another file within the project, app.yaml, then repo status might show

          project appeng/
          -mapp.yaml
          Mm main.py

        +
        For example, if you edit the file main.py within the appeng project without staging the changes, then repo status might show

        project appeng/
        -mmain.py

        If you go on to stage the changes to main.py by running git add, then repo status might show

        project appeng/
        M- main.py

        If you then make further edits to the already-staged main.py and make edits to another file within the project, app.yaml, then repo status might show

        project appeng/
        -mapp.yaml
        Mm main.py

        Git and Repo cheatsheet

        @@ -367,7 +274,7 @@ Click on the cheatsheet to open it in a new window for easier printing. Staged changes -
        Changes marked by git add for inclusion in the next commit's snapshot.

        Commit
         +
        Changes marked by git add for inclusion in the next commit's snapshot.

        Commit
        At intervals, you use git commit to save a snapshot of the staged files and a log message that describes the change.

        Manifest
        A manifest file that contains a list of repositories and a mapping of where the files from these repositories will be located within your working directory. When you synchronize your files, the files contained in the repositories that are listed in the manifest will be pulled into your working directory.
        diff --git a/pdk/docs/source/index.jd b/pdk/docs/source/index.jd index 6c27bdbf9..4960e30e2 100644 --- a/pdk/docs/source/index.jd +++ b/pdk/docs/source/index.jd @@ -19,8 +19,10 @@ read Life of a Bug.

        We created Android so that all developers can distribute their applications to users on an open platform. One of the best ways you can help Android is to write cool apps that users love!

        -

        To get started, visit our sister site, developer.android.com.

        +

        To get started, visit developer.android.com. This site +provides the information and tools you need to write applications for +compatible Android devices, using the SDK.

        Contribute to the Code

        Code is King. We'd love to review any changes you submit, so please check diff --git a/pdk/docs/source/licenses.jd b/pdk/docs/source/licenses.jd index f1f646b95..0d2cf2e6c 100644 --- a/pdk/docs/source/licenses.jd +++ b/pdk/docs/source/licenses.jd @@ -10,7 +10,7 @@ contributions from individuals and corporations.

        The preferred license for the Android Open Source Project is Apache 2.0. Apache 2.0 is a commercial and open source friendly open source license. The majority of -the Android platform is licensed under theApache 2.0 license. While the project will strive to adhere to the preferred license, there may be exceptions which will be handled on a case-by-case basis. For example, the @@ -24,7 +24,7 @@ only on their own behalf) of ideas, code, or documentation to the Android Open Source Project will be required to complete, sign, and submit an Individual Contributor License Grant. The grant can be executed online through the code review +href="https://review.source.android.com/#settings,agreements">code review tool. The agreement clearly defines the terms under which intellectual property has been contributed to the Android Open Source Project.This license is for your protection as a contributor as well as the protection of the diff --git a/pdk/docs/source/life-of-a-patch.jd b/pdk/docs/source/life-of-a-patch.jd index e7ae936ab..458afa561 100644 --- a/pdk/docs/source/life-of-a-patch.jd +++ b/pdk/docs/source/life-of-a-patch.jd @@ -1,5 +1,11 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Life of a Patch doc.type=source @jd:body -

        Workflow

        +

        The Android Open Source Project (AOSP) uses a web-based code review tool +known as "gerrit". The image below is a flowchart that details what happens to +a patch, once it's been written. Though it may appear complex, the majority of +the steps below are performed in the web application.

        +

        For full instructions on how to get set up to use gerrit and git, please +see the Submitting Patches +page.

        diff --git a/pdk/docs/source/overview-1.0.jd b/pdk/docs/source/overview-1.0.jd index cc923c649..e1b5cd673 100644 --- a/pdk/docs/source/overview-1.0.jd +++ b/pdk/docs/source/overview-1.0.jd @@ -1,17 +1,16 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Android 1.0 Features doc.type=source @jd:body -

        Release features - Android 1.0 -

        -
        This page provides a high-level overview of Android 1.0 features. For a list of all the projects that make up the Android 1.0 source code, seeProject layout -. To see the code itself, you can either use theGitWeb -interface to view snapshots of the files, or you candownload +
        This page provides a high-level overview of Android 1.0 +features. To see the code itself, you can either use the GitWeb +interface to view snapshots of the files, or you can download the source code onto your local machine.

        Applications

        The Android platform comes with a variety of applications written using the Java programming language:
        • Home displays applications, widgets, and shortcuts. It also supports customizable wall paper.
        • Phone -supports regular telephony functions as well as call controls, conference calls, supplementary services, and easy integration withContacts +supports regular telephony functions as well as call controls, conference calls, supplementary services, and easy integration with Contacts .
        • Web Browser is a fully featured WebKit-based browser that supports HTML and XHTML. @@ -27,7 +26,7 @@ enables managing, importing, and playing back content that has been encoded in v
        Application framework

        -
        The Android Application Framework has been designed to provide a rich set of APIs for third-party application developers. For more information, visit theAndroid SDK developer guide +
        The Android Application Framework has been designed to provide a rich set of APIs for third-party application developers. For more information, visit the Android SDK developer guide .
        @@ -47,7 +46,7 @@ Dalvik has the following runtime characteristics:
      7. Efficient linkage to low-level native code.
        8. -
      8. A familiar and rich set of core library functionality. For a complete list of supported libraries, seehttp://developer.android.com/reference/packages.html +
      9. A familiar and rich set of core library functionality. For a complete list of supported libraries, see http://developer.android.com/reference/packages.html .
      10. Enhanced JDWP support, enabling easier debugging of multiple processes simultaneously. @@ -55,7 +54,7 @@ Dalvik has the following runtime characteristics:
      11. JNI support.
    -Native libraries
     +Native libraries

    The Android platform makes use of many native libraries, including:
    • Bionic , a custom libc implementation optimized for embedded systems.
      • @@ -72,9 +71,9 @@ Dalvik has the following runtime characteristics:
      • Based on Linux 2.6.25 for ARM.
      • Platform currently expects ARM V5T or better architecture. Support for earlier architectures could be added, but CPUs without an MMU would be difficult to support.
        • -
      • A set of kernel enhancements are provided to support Android. The patches include alarm, ashmem, binder, power management, low memory killer, kernel degugger, and logger.
         +
      • A set of kernel enhancements are provided to support Android. The patches include alarm, ashmem, binder, power management, low memory killer, kernel degugger, and logger .
        • -
      • While the platform is designed to be chipset agnostic, and will run on virtually any ARM-based Linux kernel environment, version 1.0 of the platform has been tested and verified on the MSM 7K chipsets. +
      • While the platform is designed to be chipset agnostic, and will run on virtually any ARM-based Linux kernel environment, version 1.0 of the platform has been tested and verified on the MSM 7K chipsets . Over time we expect to see support for other major chipsets. Kernel patches for MSM based chipsets are also available.
        • @@ -92,7 +91,7 @@ Kernel patches for MSM based chipsets are also available.
      • Logging and crash logs supported for debugging.
      -Supported hardware
       +Supported hardware
      • The platform will run on almost on any ARM based Linux kernel environment.
      • The platform requires a minimum of 128 MB of RAM and 256 MB ofFlash memory. AnOEM may want to support more Flash memory to make it possible to download more third-party applications to user devices.
        • @@ -110,8 +109,8 @@ Kernel patches for MSM based chipsets are also available.
      Supported display -
      • HVGA resolution
        • -
      • 16 bit color depth
        • +
        • HVGA resolution
          • +
        • 16 bit color depth
        • Landscape and portrait orientation, including dynamic runtime switching
        • Finger-based touchscreen navigation @@ -141,12 +140,12 @@ Kernel patches for MSM based chipsets are also available.
        • Vibration
        -Supported radio and telephony features
         +Supported radio and telephony features
        • GPRS, EDGE, UMTS, HSDPA
          • -
        • International roaming, SMS, MMS
          • -
        • Emergency call support
          • -
        • Supplementary Services for Telephony, for example call waiting and conference calling
          • +
        • International roaming, SMS, MMS
          • +
        • Emergency call support
          • +
        • Supplementary Services for Telephony, for example call waiting and conference calling
        • Unstructured Supplementary Service Data (USSD)
        • Reference Radio Interface Layer (RIL) diff --git a/pdk/docs/source/overview-1.5.jd b/pdk/docs/source/overview-1.5.jd index 3212f3b48..dd74874f6 100644 --- a/pdk/docs/source/overview-1.5.jd +++ b/pdk/docs/source/overview-1.5.jd @@ -1,12 +1,14 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Android 1.5 Features doc.type=source @jd:body

          Release features - Android 1.5

          Previous release highlights -:Android 1.0 -

          This page provides a high-level overview of the new features added to Android 1.5. To see the code itself, you can either use theGitWeb -interface to view snapshots of the files, or you candownload +:Android 1.0 +

          This page provides a high-level overview of the new features added to +Android 1.5. To see the code itself, you can either use theGitWeb +interface to view snapshots of the files, or you candownload the source code onto your local machine. You can userepo init -u git://android.git.kernel.org/platform/manifest.git-b android-1.5 to download the source code for Android 1.5.

          User interface refinements: diff --git a/pdk/docs/source/overview.jd b/pdk/docs/source/overview.jd index 0948ef204..9874b4bad 100644 --- a/pdk/docs/source/overview.jd +++ b/pdk/docs/source/overview.jd @@ -3,9 +3,9 @@ doc.type=source @jd:body

          This page provides a high-level overview of the new features added to Android 1.6. To see the code itself, you can either use the GitWeb +href="http://android.git.kernel.org/">GitWeb interface to view snapshots of the files, or you can download +href="{@docRoot}source/download.html">download the source code onto your local machine. You can use repo init -u git://android.git.kernel.org/platform/manifest.git -b android-1.6 to download the source code for Android 1.6.

          diff --git a/pdk/docs/source/roles.jd b/pdk/docs/source/roles.jd index 9c64c717b..2b4a7214e 100644 --- a/pdk/docs/source/roles.jd +++ b/pdk/docs/source/roles.jd @@ -13,14 +13,6 @@ questions, contribute patches, report bugs, look at submitted patches, and use the tools. To get started with the Android code, see Get Involved.

          -

          AOSP Member

          -

          "AOSP Member" is a somewhat loose term, but generally refers to -those organizations who are key contributors to Android, and who are managing -the product requirements process and core engineering. You can think of this -group as the Android "core team" responsible for Android's overall success in -the marketplace. One of the most prominent AOSP members is Google.

          -

          -

          Contributor

          A "Contributor" is anyone making contributions to the AOSP source code, including both employees or other affiliates of an AOSP Member, as well as diff --git a/pdk/docs/source/source_toc.cs b/pdk/docs/source/source_toc.cs index 007ea64e4..1531affbe 100644 --- a/pdk/docs/source/source_toc.cs +++ b/pdk/docs/source/source_toc.cs @@ -25,6 +25,7 @@ function nothing() {}

        • Life of a Patch
        • Submitting Patches
        • Reporting Bugs
          • +
        • Branches & Releases
      diff --git a/pdk/docs/source/submit-patches.jd b/pdk/docs/source/submit-patches.jd index afa6bf258..880a68247 100644 --- a/pdk/docs/source/submit-patches.jd +++ b/pdk/docs/source/submit-patches.jd @@ -1,109 +1,32 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Android Contributors' Workflow doc.type=source @jd:body -

      Contribute - -

      -
      Using Repo and Git -
      - - - -
      For information about current problems and fixes, seeKnown issues -.

      This page describes how to record changes to the Android files on your local client, upload those changes to the code-review server, and use Gerrit to track changes.

      Prerequisites

      -Before you follow the instructions on this page, you will need to set up your local working environment and get the Android source files. For instructions, seeGet source -.

      Other recommended reading:
      • For an overview of the code contribution and review process, seeWorkflow +Before you follow the instructions on this page, you will need to set up your +local working environment and get the Android source files. For instructions, +see Get source +.

        Other recommended reading:
        • For an overview of the code +contribution and review process, see Workflow .
          • -
        • For details about Repo, seeUsing Repo and Git +
        • For details about Repo, see Using Repo and Git .
          • -
        • For information about the different roles you can play within the Android Open Source community, seeProject roles -.
          • -
        • If you plan to contribute code to the Android platform, be sure to read aboutcontributor licenses +
        • For information about the different roles you can play within the Android +Open Source community, see Project roles .
          • +
        • If you plan to contribute code to the Android platform, be sure to read +the AOSP's licensing information.

        Working with the code

        -First, download the source into your working directory, as described inGet source -.

        To work on a particular change to the code, follow these steps:
        +First, download the source into your working directory, as described in Get source +. For information about how to choose which branch to use, see Android Code-Lines.

        To work on a particular change to the code, follow these steps:
        -
        1. Use repo startbranchname +
          1. Use repo start branchname to start a new topic branch.
          2. Edit the files.
          3. Use git add to stage changes. @@ -117,34 +40,32 @@ to start a new topic branch.
          You can track your uploaded changes using the Gerrit code-review tool. When it's time to work on the code again, run repo sync, then go back to step 1 above and start another topic branch.

          The steps will not always come in the order shown--for example, you might run git diff at several points in the process.

          Starting a topic branch

          -Start a topic branch called default in your local work environment:

          $ repo start default

          For more about topic branches, seeUsing Repo and Git +Start a topic branch called default in your local work environment:

          $ repo start default

          For more about topic branches, see Using Repo and Git .

          Editing the files

          You do not need to check files out before working on them. Edit the files using vim, emacs, or any other editor.

          Staging changes

          To indicate that every new and modified file in your working directory should be "staged" for inclusion in the next commit, run git add without any arguments. You can also specify files or filetypes. For example, the following command would stage all the new and modified files under the bionic directory and its subdirectories:

          $ git add bionic/*

          Run git help add to see more ways to use git add.

          When is git add optional?
          If you add new files, you must stage them using git add before you run git commit. However, if you are only modifying or deleting files, you can skip git add if you use the -a option with git commit. For more details, see the "Committing changes" section further down.

          -Using repo status

          -To see the status of the current branch, run

          $ repo status .

          For information about how to interpret the results of repo status, seeUsing Repo and Git +Using repo status
          +To see the status of the current branch, run

          $ repo status .

          For information about how to interpret the results of repo status, see Using Repo and Git .

          Using git diff

          -To see uncommitted changes, cd into the project directory and run

          $ git -diff

          Without any arguments, git diff will show you the differences +To see uncommitted changes, cd into the project directory and run

          $ git +diff

          Without any arguments, git diff will show you the differences between the files in your working directory and the committed files.


          If you add the --cached option, git diff will show you the differences between the files in your working directory and the staged files.

          -

           -
          -To see every edit that would go into the commit if you were to commit right now, make sure you are in the project directory and then run

          $ git diff --cached

          +To see every edit that would go into the commit if you were to commit right now, make sure you are in the project directory and then run

          $ git diff --cached

          Committing changes

          At intervals while you are working, commit your edits by using git commit from within the project directory:
          $ cd ~/mydroid/project-name
          $ git commit           -

          Every file that you staged using git add will be included in this commit.

          If you have not added any new files that you want to commit, you can skip git add and simply run

          $ git commit -a

          The -a option will stage all the files you have modified or deleted and include them in this commit. (If you have added new files and want them included in the commit, you will need to use git add before you run git commit.)

          If commit +

          Every file that you staged using git add will be included in this commit.

          If you have not added any new files that you want to commit, you can skip git add and simply run

          $ git commit -a

          The -a option will stage all the files you have modified or deleted and include them in this commit. (If you have added new files and want them included in the commit, you will need to use git add before you run git commit.)

          If commit does not find changes to be committed, it will report "nothing to commit (working directory clean)". If commit finds changes to be committed, a file will open in which you can create a log message:

          Your comments about this commit go here.... -
          # Please enter the commit message for your changes. Lines starting
          # with '#' will be ignored, and an empty message aborts the commit.
          # On branch master
          # Changes to be committed:
          #(use "git reset HEADfile..." to unstage)
          #
          #new file:.repo/projects/gerrit-manifests.git/FETCH_HEAD
          #new file:.repo/projects/gerrit-manifests.git/HEAD
          #new file:.repo/projects/gerrit-manifests.git/config
          .
          .
          .
          +
          # Please enter the commit message for your changes. Lines starting
          # with '#' will be ignored, and an empty message aborts the commit.
          # On branch master
          # Changes to be committed:
          #(use "git reset HEADfile..." to unstage)
          #
          #new file:.repo/projects/gerrit-manifests.git/FETCH_HEAD
          #new file:.repo/projects/gerrit-manifests.git/HEAD
          #new file:.repo/projects/gerrit-manifests.git/config
          .
          .
          .

      If you do not add a log message, the commit will be aborted. Add a message and save the file.

      Committing changes during code review

      If you previously uploaded a change to Gerrit and the Approver has asked for changes, follow these steps:
      1. Edit the files to make the changes the Approver has requested.
        2. @@ -155,22 +76,22 @@ If you previously uploaded a change to Gerrit and the Approver has asked for cha

        Editing uploaded changes

        To update an existing change with a new patch set:
        1. Make sure the updated branch is the currently checked out branch.
          2. -
        2. Use repo upload --replaceproj1 +
        3. Use repo upload --replace proj1 to open the change matching editor.
        4. For each commit in the series, enter the Gerrit change Id inside the brackets.
        -For more details, seeUsing Repo and Git +For more details, see Using Repo and Git .

        Uploading changes to Gerrit

        -To upload your committed changes to the review server:
        1. Complete the appropriateContributor Agreement +To upload your committed changes to the review server:
          1. Complete the appropriate Contributor Agreement in Gerrit, granting the Android Open Source Project permission to distribute your changes to others.
            2. -
          2. Select anSSH Username -and upload yourpublic SSH key +
          3. Select an SSH Username +and upload your public SSH key , so that Gerrit can identify you when you upload changes.Please note that due to a bug in repo, repo upload requires your SSH Username be the local part of your email address (the text on the left of the @ sign).

            These first two steps are only necessary prior to your first change.Gerrit will remember your agreement and SSH key for subsequent changes.

          4. Update to the latest revisions:
             $ repo sync -

            For information about how to handle sync conflicts and how Repo synchronization works, seeUsing Repo and Git +

            For information about how to handle sync conflicts and how Repo synchronization works, see Using Repo and Git .

          5. Run repo upload to examine the list of all available changes and select which topic branches will be uploaded to the review server:
            $ repo upload @@ -179,28 +100,27 @@ and upload yourpu After a change is uploaded successfully:
            • Repo will give you a URL where you can view your submission.
            • The code-review system will automatically notify the project owner about your submission.
            -For information about specifying particular projects with repo sync and repo upload, see            Using Repo and Git +For information about specifying particular projects with repo sync and repo upload, see Using Repo and Git .

            -Summary example

            -Here is a simple example that shows how you might work with the bionic/Android.mk file:

            $ cd ~/mydroid/bionic
            $ repo start default
            $ vi Android.mk
            ...edit and save the file... -
            $ git commit -a
            $ repo sync
            $ repo upload
            ...close the editable window that opens... +Summary example
            +Here is a simple example that shows how you might work with the bionic/Android.mk file:

            $ cd ~/mydroid/bionic
            $ repo start default
            $ vi Android.mk
            ...edit and save the file... +
            $ git commit -a
            $ repo sync
            $ repo upload
            ...close the editable window that opens...
            ...visit the provided URL to open Gerrit and track your change...

            Downloading changes from Gerrit

            -To download a specific change from Gerrit, run

            $ repo downloadtarget change -

            where target is the local directory into which the change should be downloaded andchange is the change number as listed inGerrit -. For more information, seeUsing Repo and Git +To download a specific change from Gerrit, run

            $ repo download target change +

            where target is the local directory into which the change should be downloaded andchange is the change number as listed in Gerrit +. For more information, see Using Repo and Git .

            -Using the Gerrit code-review tool

            -You can open Gerrit by visiting whatever URL is returned to you from the repo upload command, or by visitinghttps://review.source.android.com +Using the Gerrit code-review tool
            +You can open Gerrit by visiting whatever URL is returned to you from the repo upload command, or by visiting https://review.source.android.com /.

            -Viewing the status of uploaded changes

            -To check the status of a change that you uploaded, openGerrit +Viewing the status of uploaded changes
            +To check the status of a change that you uploaded, open Gerrit , sign in, and click MyChanges.

            -Reviewing a change

            -If you are assigned to be the Approver for a change, you need to determine the following:
            • Does this change fit within this project's stated purpose? (SeeProject layout -.)
              • +Reviewing a change
              +If you are assigned to be the Approver for a change, you need to determine the following:
              • Does this change fit within this project's stated purpose?
              • Is this change valid within the project's existing architecture?
              • Does this change introduce design flaws that will cause problems in the future?
              • Does this change following the best practices that have been established for this project?
                • @@ -208,7 +128,7 @@ If you are assigned to be the Approver for a change, you need to determine the f
              • Does this change introduce any security or instability risks?
              If you approve of the change, you will then mark it with LGTM ("Looks Good to Me") within Gerrit.

              -Verifying a change

              +Verifying a change
              If you are assigned to be the Verifier for a change, you need to do the following:
              • Patch the change into your local client using one of the Download commands.
              • Build and test the change.
              • Within Gerrit use Publish Comments to mark the commit as "Verified", or "Fails" (and add a message explaining what problems were identified).
                • @@ -222,10 +142,12 @@ Anyone in the community can use Gerrit to add inline comments to code submission After a submission is approved After a submission makes it through the review and verification process, Gerrit automatically merges the change into the public repository. The change will now be visible in gitweb, and others users will be able to run repo sync to pull the update into their local client.

                How do I become a Verifier or Approver?

                -In short, contribute high-quality code to one or more of the Android projects. For details about the different roles in the Android Open Source community and who plays them, seeProject roles +In short, contribute high-quality code to one or more of the Android projects. +For details about the different roles in the Android Open Source community and +who plays them, see Project roles .

                Using GitWeb to track patch histories

                -To view snapshots of the files that are in the public Android repositories and view file histories, use theAndroid instance of GitWeb +To view snapshots of the files that are in the public Android repositories and view file histories, use the Android instance of GitWeb .
      diff --git a/pdk/docs/source/using-eclipse.jd b/pdk/docs/source/using-eclipse.jd index 961da74f2..1750a2091 100644 --- a/pdk/docs/source/using-eclipse.jd +++ b/pdk/docs/source/using-eclipse.jd @@ -1,8 +1,6 @@ -page.title=Android Compatibility - Compatibility Test Suite +page.title=Using Eclipse doc.type=source @jd:body -

      Using Eclipse -

      About this Document

      This document will help you set up the Eclipse IDE for Android platform development. @@ -16,13 +14,13 @@ Basic setup

      First, it's important to make sure the regular Android development system is set up.

      -
      cd /path/to/android/root
      make     # and wait a while, if you haven't done this
      +
      cd /path/to/android/root 
      make     # and wait a while, if you haven't done this

      Important : You will still be using "make" to build the files you will actually run (in the emulator or on a device). You will be using Eclipse to edit files and verify that they compile, but when you want to run something you will need to make sure files are saved in Eclipse and run "make" in a shell. The Eclipse build is just for error checking.

      Eclipse needs a list of directories to search for Java files. This is called the "Java Build Path" and can be set with the .classpath file. We have a sample version to start you off.

      -
      cd /path/to/android/root
      cp development/ide/eclipse/.classpath .
      chmod u+w .classpath  # Make the copy writable
      +
      cd /path/to/android/root 
      cp development/ide/eclipse/.classpath .
      chmod u+w .classpath  # Make the copy writable

      Now edit that copy of .classpath, if necessary.

      @@ -33,15 +31,15 @@ Increase Eclipse's Memory Settings

      Memory-related defaults (as of Eclipse 3.4)

      -
      -Xms40m
      -Xmx256m
      -XX:MaxPermSize=256m
      +
      -Xms40m 
      -Xmx256m 
      -XX:MaxPermSize=256m

      Recommended settings for Android development

      -
      -Xms128m
      -Xmx512m
      -XX:MaxPermSize=256m
      +
      -Xms128m 
      -Xmx512m 
      -XX:MaxPermSize=256m

      These settings set Eclipse's minimum Java heap size to 128MB, set the maximum Java heap size to 512MB, and keep the maximum permanent generation size at the default of 256MB.

      Now start Eclipse:

      -
      eclipse  # or you can click some clicky thing instead, if you prefer
      +
      eclipse  # or you can click some clicky thing instead, if you prefer

      Now create a project for Android development:

      1. If Eclipse asks you for a workspace location, choose the default. @@ -111,7 +109,7 @@ Eclipse setup to work on developer tools
      2. Choose the "Source" tab.
        3. -
      3. Expand the singletoolname +
      4. Expand the single toolname /src entry.
      5. Double click the "Excluded: (none)" item. @@ -120,14 +118,14 @@ Eclipse setup to work on developer tools
      6. Close the dialog.
        7. -
      7. Back in the "Source" tab, click "Add Folder...", and addtoolname +
      8. Back in the "Source" tab, click "Add Folder...", and add toolname /src/resources.
      9. Click OK.

      -Eclipse setup to work on DDMS

      +Eclipse setup to work on DDMS

      For DDMS, you will need to make a project for

      1. development/tools/ddms/libs/ddmlib @@ -156,10 +154,10 @@ Eclipse setup to work on DDMS

        You can also use eclipse to debug the emulator and step through code. First, start the emulator running:

        -
        cd /path/to/android/root
        . build/envsetup.sh
        lunch 1   # to build the emulator
        make      # if you didn't already do this
        emulator  # you should see a GUI picture of a phone
        +
        cd /path/to/android/root 
        . build/envsetup.sh 
        lunch 1   # to build the emulator 
        make      # if you didn't already do this 
        emulator  # you should see a GUI picture of a phone

        In another shell, start DDMS (the Dalvik debug manager):

        -
        cd /path/to/android/root
        ddms      # you should get a splufty debugging console
        +
        cd /path/to/android/root 
        ddms      # you should get a splufty debugging console

        Now, in eclipse, you can attach to the emulator:

        1. Run Open Debug Dialog... @@ -184,7 +182,7 @@ Eclipse setup to work on DDMS

          Replace Ctrl with the Apple key on Mac.

          -
          Ctrl-Shift-o = Organize imports
          Ctrl-Shift-t = load class by name
          Ctrl-Shift-r = load non-class resource by name
          Ctrl-1 = quick fix
          Ctrl-e = Recently viewed files
          Ctrl-space = auto complete
          Shift-Alt-r = refactor:rename
          Shift-Alt-v = refactor:move
          +
          Ctrl-Shift-o = Organize imports 
          Ctrl-Shift-t = load class by name 
          Ctrl-Shift-r = load non-class resource by name 
          Ctrl-1 = quick fix 
          Ctrl-e = Recently viewed files 
          Ctrl-space = auto complete 
          Shift-Alt-r = refactor:rename 
          Shift-Alt-v = refactor:move

          Useful Plugins