apicheck

by Jey.Michael » Wed, 04 Mar 2009 05:50:37 GMT


Sponsored Links
 I am trying to understand the api-check mechanism, currently built-in
to the framework.

When I make source changes, by adding new public apis, the build warns
me about that change and stops.

Then I do make update-api which updates the current.xml

But the build still fails, because it tries to validate against the
(old version?) 3.xml (2.xml, 1.xml etc)

make showcommands show this:

Checking API: checkapi-last
( out/host/darwin-x86/bin/apicheck  -hide 2 -hide 3 -hide 4 -hide 5 -
hide 6 -hide 24 -hide 25 -error 7 -error 8 -error 9 -error 10 -error
11 -error 12 -error 13 -error 14 -error 15 -error 16 -error 17 -error
18   frameworks/base/api/3.xml  out/target/common/obj/PACKAGING/
public_api.xml || (  cat build/core/apicheck_msg_last.txt  ; exit
38 ) )
(unknown): error 17: Field android.view.KeyEvent.MAX_KEYCODE has
changed value

Is this, by design?  I thought, the build's intermediate
'public_api.xml' would be checked against the current.xml forcing the
developer to modfy the current.xml.  If this is by design, I am not
sure what needs to be done for this additional check against the
3.xml ?  3.xml needs to changed as well?  That does not sound right.

Any links, documents, write-ups about the api-check mechanism would
help.

thanks
Jey

--~--~---------~--~----~------------~-------~--~----~



apicheck

by Jean-Baptiste Queru » Wed, 04 Mar 2009 14:00:03 GMT


 There are two steps in apicheck:

-whether you changed a public API at all (that's the part that uses
current.xml), so that there is a mechanism to have any API change
reviewed and approved before they're submitted.

-whether you broke binary compatibility by changing an API (that's the
part that uses 3.xml), so that applications compiled against previous
levels of the API (in this case 1 is 1.0 and 2 is 1.1) can continue to
work on this version.

The first one is something that's open for review, but the second one
typically isn't.

There might be exceptional changes where some constants might be
allowed to change between versions, which can be done without
preventing apps from loading, but that still has some issues (e.g. the
compiled version of the constant isn't the same as the one the app can
get through reflection, and the semantics of the constant can
introduce adverse effects if it changes).

JBQ






-- 
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

Questions sent directly to me will likely get ignored or forwarded to
a public forum with no further warning.

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


apicheck

by Jey Michael » Wed, 04 Mar 2009 21:38:58 GMT


 


Thanks JBQ.  I am running into the second one. :-(
This makes it important for me to try getting the changes to public
api, I suppose.

https://review.source.android.com/9070  [Dianne Hackborn]
https://review.source.android.com/9069  [Jeff Hamilton]
are the changes that would help devices with Ringer switch.

-Jey

--~--~---------~--~----~------------~-------~--~----~



apicheck

by Jean-Baptiste Queru » Wed, 04 Mar 2009 21:51:49 GMT


 Well, the good news is that this is the right list to discuss the
consequences of changing a constant in the API.

JBQ







-- 
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

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

--~--~---------~--~----~------------~-------~--~----~



apicheck

by Dianne Hackborn » Wed, 04 Mar 2009 22:21:52 GMT


 




I don't see any public constants being changed in these patches, though
there are some new ones that needed to be added with "make update-api".

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them.

--~--~---------~--~----~------------~-------~--~----~



apicheck

by Jey Michael » Wed, 04 Mar 2009 23:11:34 GMT


 Sigh!  I missed that.  Its in:
https://review.source.android.com/9075

-Jey







--~--~---------~--~----~------------~-------~--~----~



apicheck

by Jey Michael » Wed, 04 Mar 2009 23:23:21 GMT


 


This 3.xml is mapping to cupcake release (1.5?) I suppose.
In my case, I created a new recent workspace just to push code into
gerrit.  With my changes, now the build does not complain about 3.xml
anymore.   Should I still add the new entries in 3.xml and include in
my submission?

-Jey

--~--~---------~--~----~------------~-------~--~----~



apicheck

by Jean-Baptiste Queru » Wed, 04 Mar 2009 23:28:17 GMT


 having 3.xml while the cupcake API is still changing is a hack to hide
a situation where according to the tools cupcake isn't
backward-compatible with 1.1 (where the 1.1 API is 2.xml). When the
cupcake API freezes, we'll copy the then-current current.xml into the
"real" 3.xml.

(manually) modifying 3.xml should only be for cases where we're
knowingly hiding a case where the tool complains about API
compatibility but for one reason or another we've determined that it's
actually OK. That's a very rare instance, though.

JBQ







-- 
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

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

--~--~---------~--~----~------------~-------~--~----~



apicheck

by Dianne Hackborn » Wed, 04 Mar 2009 23:40:29 GMT


 That's a current.xml change, which is fine, it is just showing that new APIs
are being added.  There is no need to change 3.xml due to this.








-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them.

--~--~---------~--~----~------------~-------~--~----~



apicheck

by Jey Michael » Thu, 05 Mar 2009 03:01:25 GMT


 Hm... I am learning to use Gerrit properly, and redid the submissions
a few times...

Finally my changes are all grouped under these 2 patchsets:
https://review.source.android.com/9080
https://review.source.android.com/9081

Thanks,
Jey








--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Resize WebPage Problem

Hello all,

I am developing a website for mobile.  I have a resizing problem on
Android. On Iphone, IPad, Windows Mobile my site is automatically
resize.On Android, my page is resized only if the url looks like this:
www.mysite.ch. If the url looks like this: http://mobile.mysite.ch, my
page does not resize correctly. Do you know the problem?

I tried using "<meta name="viewport" content="width=device-width">"
but it doesn't work.

Can you help me? Have you a work around for this problem???

Eric

-- 

2. .text.parseexception unparseable

hey i am getting an error   how to  solve java.text.parseexception
unparseable date 2011/26/4    while converting date from string format
to java.sql.Date format...
can anyone suggest solution to this problem...

-- 

3. [WTI] [Desire ROM] LeeDrOiD V3.0 GB Android 2.3.3 Gingersense

4. How to properly use Model classes in Android

5. Built-in camera problem deleting files

6. VideoView setBackgroundColor is foregroundcolor ?

7. all_apps_3d error when screen rotation