Closed Bug 880118 Opened 7 years ago Closed 6 years ago

Package Gecko and GeckoView into an Android library project

Categories

(Core Graveyard :: Embedding: GRE Core, defect)

All
Android
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla26

People

(Reporter: mfinkle, Assigned: stully)

References

Details

Attachments

(8 files, 20 obsolete files)

1.10 KB, patch
cpeterson
: review+
Details | Diff | Splinter Review
30.31 KB, patch
cpeterson
: review+
Details | Diff | Splinter Review
6.58 KB, patch
blassey
: review+
Details | Diff | Splinter Review
9.25 KB, patch
cpeterson
: review+
Details | Diff | Splinter Review
8.21 KB, patch
cpeterson
: review+
mfinkle
: review+
Details | Diff | Splinter Review
1.57 KB, patch
kats
: review+
Details | Diff | Splinter Review
1.85 KB, patch
glandium
: review+
Details | Diff | Splinter Review
4.21 KB, patch
glandium
: review+
Details | Diff | Splinter Review
Being able to create a standalone JAR package for Gecko and GeckoView will allow other Android developers to use GeckoView in their applications.
Bug 873569 is for moving Gecko assets (like libs, and omnijar) into the assets/ folder of the APK.
Depends on: 873569
Assignee: nobody → stully
Summary: Package Gecko and GeckoView into a reusable JAR → Package Gecko and GeckoView into an Android library project
Attached patch tmp-create-library-script.diff (obsolete) — Splinter Review
Temporary script for copying built JARs, SOs, omni.ja, and resources to library project directory.
Attached patch add-new-tab-option.diff (obsolete) — Splinter Review
Temporary patch to add option to GeckoView to open a URL in a new thread
Attached patch constant-id.diff (obsolete) — Splinter Review
Changes resources to non-constant IDs which is necessary for library projects.
Attached patch library-project.diff (obsolete) — Splinter Review
WIP patch to adapt GeckoView to run without having control over an Activity
Attached patch tmp-create-library-script.diff (obsolete) — Splinter Review
Attachment #787230 - Attachment is obsolete: true
Attached patch library-project.diff (obsolete) — Splinter Review
updated patches for allowing a page to load :)
Attachment #787235 - Attachment is obsolete: true
Attached patch constant-id.diff (obsolete) — Splinter Review
Change resources to non-static variables which is necessary for a library project.
Attachment #787233 - Attachment is obsolete: true
Attachment #789771 - Flags: review?(cpeterson)
Comment on attachment 787232 [details] [diff] [review]
add-new-tab-option.diff

I know this was patch was rejected in another bug, but it is necessary to get a page to load in GeckoView. Until a proper GeckoView interface is defined, this will at least allow a page to be loaded.
Attachment #787232 - Flags: review?(cpeterson)
Comment on attachment 787232 [details] [diff] [review]
add-new-tab-option.diff

Review of attachment 787232 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/GeckoView.java
@@ +76,4 @@
>      }
>  
> +    public void loadUrl(String uri, boolean openInNewTab) {
> +        Tabs.getInstance().loadUrl(uri, (openInNewTab ? Tabs.LOADURL_NEW_TAB : Tabs.LOADURL_NONE));

Boolean parameters are often a short-sighted design and obscure the caller code. I would much prefer this new method be named loadUrlInNewTab() or take a LOADURL flags parameter. Taking a flags parameter might be a better design because it emphasizes that this method is simply a pass-through to Tab.getInstance().
Attachment #787232 - Flags: review?(cpeterson) → feedback+
Changed to "loadUrlInNewTab" because changing to expose the flags variable means having to expose the Tabs flags to the 3rd party app using the library. While this is temporary anyway, it seems better to hide this info for now until the GeckoView interface is hashed out.
Attachment #787232 - Attachment is obsolete: true
Attachment #789798 - Flags: review?(cpeterson)
Comment on attachment 789798 [details] [diff] [review]
add-new-tab-option.diff

Review of attachment 789798 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM!
Attachment #789798 - Flags: review?(cpeterson) → review+
Comment on attachment 789771 [details] [diff] [review]
constant-id.diff

Review of attachment 789771 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM, but I think you should simplify these long chains of `if/else` statements to just a sequence of `if` statements than each call `return`. You can then add an empty line between each `if` block to make these long methods easier to read.
Attachment #789771 - Flags: review?(cpeterson) → feedback+
Attached patch constant-id.diff (obsolete) — Splinter Review
Attachment #789771 - Attachment is obsolete: true
Attachment #789893 - Flags: review?(cpeterson)
Attached patch constant-id.diffSplinter Review
Attachment #789893 - Attachment is obsolete: true
Attachment #789893 - Flags: review?(cpeterson)
Attachment #789898 - Flags: review?(cpeterson)
Comment on attachment 789898 [details] [diff] [review]
constant-id.diff

Review of attachment 789898 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM!

::: mobile/android/base/BrowserApp.java
@@ +1728,2 @@
>  
> +        int itemId = item.getItemId();

Please make this itemId `final` like you did in the other methods.
Attachment #789898 - Flags: review?(cpeterson) → review+
OS: Linux → Android
Hardware: x86_64 → All
Comment on attachment 789898 [details] [diff] [review]
constant-id.diff

Holy cow. This patch will be very unpopular.

What's the issue here?
A library project cannot have its resource IDs in R.java be static which means they can't be used as case labels. Otherwise, all the resources will be null.
(In reply to Mark Finkle (:mfinkle) from comment #18)
> Comment on attachment 789898 [details] [diff] [review]
> constant-id.diff
> 
> Holy cow. This patch will be very unpopular.
> 
> What's the issue here?

Reading between the lines, stully is discovering that we strongly enforce having only one set of Android resource IDs and therefore only one R.java.  You probably recall fighting with Sync to get the resources to work (or perhaps rnewman did that all): at that time, there was less support for having multiple resource sets that got merged together.

It is a longer term project to make Fennec build better with multiple resource sets, like what stully is hacking in here.  This shouldn't land as it is but is useful experimentation.
> A library project cannot have its resource IDs in R.java be static which means they can't be used as case labels. Otherwise, all the resources will be null.

Correction, they cannot be final; static is okay.
> It is a longer term project to make Fennec build better with multiple resource sets, like what stully is hacking in here.  This shouldn't land as it is but is useful experimentation.

The problem isn't multiple resource sets. By default, resource IDs are static final ints. The value of a static final int will be inlined into the bytecode. This means that the memory location this int points to is going to be invalid when the classes are used in a library project. The solution to this is to make the resource IDs non-final at the cost of not being able to use them as case labels.

If you want to keep them as final, every single resource reference in the code will be to be gotten by "getResources().getIdentifier(...)" which is much worse than just making the resource IDs non-final. Given the relatively small number of places in our code that resources are used as case labels, it seemed this was the lesser of two evils.

The only other option is to have two versions of each file that uses resources IDs as case lebels, one with a case structure and one with an if-else structure. This idea, obviously, shouldn't even be entertained.
More info:
http://tools.android.com/tips/non-constant-fields

Based on this, I think we'll need to move away from switch statements and use ugly if/else blocks.

BTW, I was able to get Fennec building with multiple resource sets in bug 901803 (the first obsoleted Cast SDK patch).
(In reply to Nick Alexander :nalexander from comment #20)
> It is a longer term project to make Fennec build better with multiple
> resource sets, like what stully is hacking in here.  This shouldn't land as
> it is but is useful experimentation.

oops. I already landed the non-final resource ID patch yesterday. Should I back it out?
Flags: needinfo?(nalexander)
(In reply to Chris Peterson (:cpeterson) from comment #25)
> (In reply to Nick Alexander :nalexander from comment #20)
> > It is a longer term project to make Fennec build better with multiple
> > resource sets, like what stully is hacking in here.  This shouldn't land as
> > it is but is useful experimentation.
> 
> oops. I already landed the non-final resource ID patch yesterday. Should I
> back it out?

Nah, let it ride.  I'm not thrilled about having Makefile.in changes land without build peer review and I'm with blassey on not liking the if/elif chains, but no sense churning for churns sake.
Flags: needinfo?(nalexander)
Everything needed to create zip files ready to be dropped into Eclipse for using GeckoView in a third party app.
Attachment #787810 - Attachment is obsolete: true
Attachment #790961 - Flags: feedback?(nalexander)
Comment on attachment 790961 [details] [diff] [review]
add-library-project-directory.diff

Review of attachment 790961 [details] [diff] [review]:
-----------------------------------------------------------------

This is moving in a good direction, but since there's no *build* per se (except moving some files -- keep that in the new Makefile.in), I'd like to see all of the zip/libs/assets logic moved into packager.mk.  There'll be fewer gnarly ../.. chains.  Also, prefer listing explicit files to update the zip with rather than globbing.  Lists are good!  Make sure to think about armv7/armv6/x86 too.

::: mobile/android/geckoview_library/.classpath
@@ +4,5 @@
> +	<classpathentry kind="src" path="gen"/>
> +	<classpathentry kind="con" path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/>
> +	<classpathentry exported="true" kind="con" path="com.android.ide.eclipse.adt.LIBRARIES">
> +		<attributes>
> +			<attribute name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" value="geckoview_library/libs/armeabi-v7a"/>

x86?  ARMv6?  And how do the Fennec libraries (some of which are native) fit in here?  I'm not thrilled with shipping a .classpath, but I'm not clear on how you intend this to be used.

::: mobile/android/geckoview_library/Makefile.in
@@ +10,5 @@
> +include $(DEPTH)/config/autoconf.mk
> +
> +INSTALL_TARGETS += GECKOVIEW_LIBRARY
> +GECKOVIEW_LIBRARY_DEST = $(CURDIR)
> +GECKOVIEW_LIBRARY_FILES := AndroidManifest.xml \

nit: := \
\tfile1 \
\tfile2 \

@@ +25,5 @@
> +	# Make empty directories to fit an Android project structure
> +	mkdir -p bin gen libs/armeabi-v7a src
> +
> +	# JARs
> +	mv ../base/jars/* libs/

This will bust the previously built parts of the objdir.  You can $(CP), but I think you might want to do this whole business in packager.mk.

@@ +28,5 @@
> +	# JARs
> +	mv ../base/jars/* libs/
> +
> +	# Mozglue (this should be in a directory named 'libs', not 'lib')
> +	cp ../../../dist/bin/libmozglue.so libs/armeabi-v7a/

Again, x86/armv6.  We have fu to deal with this in packager.mk; you might need to extract a better framework.

@@ +40,5 @@
> +	cd ..; \
> +	zip -r ../../dist/geckoview_library/geckoview_library.zip geckoview_library
> +
> +	# The makefiles shouldn't be included in the zip
> +	zip -d ../../../dist/geckoview_library/geckoview_library.zip geckoview_library/backend.mk geckoview_library/Makefile

What is going into this?  Is it just a few static files (listed above) and then some of the jars and libs built above?  If so, we should be doing this all in packager.mk.

@@ +43,5 @@
> +	# The makefiles shouldn't be included in the zip
> +	zip -d ../../../dist/geckoview_library/geckoview_library.zip geckoview_library/backend.mk geckoview_library/Makefile
> +
> +	# Move the JARs and resources back
> +	mv libs/*.jar ../base/jars/

Well, that's good -- but prefer staging + $(CP).  And $(ZIP), $(MKDIR), etc while you're at it.

::: toolkit/mozapps/installer/packager.mk
@@ +344,5 @@
>  INNER_ROBOCOP_PACKAGE=echo 'Testing is disabled - No Robocop for you'
>  endif
>  
> +INNER_MAKE_GECKOVIEW_LIBRARY= \
> +  cd fennec && \

nit: subshell for the scope of the cd.

@@ +345,5 @@
>  endif
>  
> +INNER_MAKE_GECKOVIEW_LIBRARY= \
> +  cd fennec && \
> +  $(ZIP) -r ../geckoview_library/geckoview_assets.zip assets && \

Not clear why we have a separate assets zip.  I'd prefer one zip with all the things.

@@ +346,5 @@
>  
> +INNER_MAKE_GECKOVIEW_LIBRARY= \
> +  cd fennec && \
> +  $(ZIP) -r ../geckoview_library/geckoview_assets.zip assets && \
> +  cd -

Not clear on what cd - does.  subshell is better.
Attachment #790961 - Flags: feedback?(nalexander) → feedback+
Attachment #790961 - Attachment is obsolete: true
Attachment #791047 - Flags: feedback?(nalexander)
Attached patch library-project.diff (obsolete) — Splinter Review
Attachment #787811 - Attachment is obsolete: true
Attachment #792993 - Flags: feedback?(cpeterson)
Attached patch disable-content-providers.diff (obsolete) — Splinter Review
Attachment #792994 - Flags: feedback?(cpeterson)
Comment on attachment 792994 [details] [diff] [review]
disable-content-providers.diff

Review of attachment 792994 [details] [diff] [review]:
-----------------------------------------------------------------

Maybe the content providers should be off by default and manually enabled by GeckoApp instead of adding hacks to GeckoView.

::: mobile/android/base/db/BrowserDB.java
@@ +19,5 @@
>  import java.util.List;
>  
>  public class BrowserDB {
>      public static String ABOUT_PAGES_URL_FILTER = "about:%";
> +    private static boolean sDisableContentProviders;

I think a name like `sAreContentProvidersDisabled` (or, flipping the logic, `sAreContentProvidersEnabled`) might be clearer because it describes a state, not an action.

@@ +213,4 @@
>      }
>  
>      public static boolean isReadingListItem(ContentResolver cr, String uri) {
> +        return (sDisableContentProviders ? false : sDb.isReadingListItem(cr, uri));

You can simplify these expressions to something like:

    return (!sDisableContentProviders && sDb.isReadingListItem(cr, uri));
Attachment #792994 - Flags: feedback?(cpeterson) → feedback+
Comment on attachment 792993 [details] [diff] [review]
library-project.diff

Review of attachment 792993 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/GeckoView.java
@@ +129,5 @@
> +    }
> +
> +    public Activity getActivity() {
> +        return (Activity)mContext;
> +    };

remove extra semicolon.

@@ +172,5 @@
> +    public void disableCameraView() {}
> +
> +    public void addAppStateListener(GeckoAppShell.AppStateListener listener) {}
> +
> +    public void removeAppStateListener(GeckoAppShell.AppStateListener listener) {}

Where are all these nop methods called from?
Attachment #792993 - Flags: feedback?(cpeterson) → feedback+
Attachment #792994 - Attachment is obsolete: true
Attachment #793125 - Flags: review?(cpeterson)
Attached patch library-project.diff (obsolete) — Splinter Review
Attachment #792993 - Attachment is obsolete: true
Attachment #793127 - Flags: review?(cpeterson)
Updated manifest with permissions for GeckoView
Attachment #791047 - Attachment is obsolete: true
Attachment #791047 - Flags: feedback?(nalexander)
Attachment #793128 - Flags: review?(nalexander)
Comment on attachment 793128 [details] [diff] [review]
add-library-project-directory.diff

Review of attachment 793128 [details] [diff] [review]:
-----------------------------------------------------------------

I'm confused about how this will be consumed.  Specifying .classpath suggests an Eclipse project (but then there should be .project, no)?  The inclusion of Makefile and backend.mk is almost certainly not wanted.  This is a strong f+ -- providing consumer build context might make this an r+.

::: mobile/android/geckoview_library/.classpath
@@ +4,5 @@
> +	<classpathentry kind="src" path="gen"/>
> +	<classpathentry kind="con" path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/>
> +	<classpathentry exported="true" kind="con" path="com.android.ide.eclipse.adt.LIBRARIES">
> +		<attributes>
> +			<attribute name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" value="geckoview_library/libs/armeabi-v7a"/>

What was the word on all the different ABIs we support?

::: mobile/android/geckoview_library/Makefile.in
@@ +11,5 @@
> +
> +INSTALL_TARGETS += GECKOVIEW_LIBRARY
> +GECKOVIEW_LIBRARY_DEST = $(CURDIR)
> +GECKOVIEW_LIBRARY_FILES := \
> +	AndroidManifest.xml \

nit: sort these.  And two spaces at start rather than \t (Make is crazy).

::: toolkit/mozapps/installer/packager.mk
@@ +343,5 @@
>  else
>  INNER_ROBOCOP_PACKAGE=echo 'Testing is disabled - No Robocop for you'
>  endif
>  
> +INNER_MAKE_GECKOVIEW_LIBRARY= \

Can we get a one-line comment explaining what this does right before the command?  For example:

# Create geckoview_library/geckoview_{assets,library}.zip for third-party GeckoView consumers.

@@ +354,5 @@
> +  cp bin/libmozglue.so bin/lib/libplugin-container.so ../mobile/android/geckoview_library/libs/$(ABI_DIR)/ && \
> +  cp -R ../mobile/android/base/res ../mobile/android/geckoview_library && \
> +  ( cd ../mobile/android && \
> +    $(ZIP) -r ../../dist/geckoview_library/geckoview_library.zip geckoview_library) && \
> +  $(ZIP) -d geckoview_library/geckoview_library.zip geckoview_library/backend.mk geckoview_library/Makefile

I'm a bit confused here.  You almost certainly don't want the processed Makefile or backend.mk included here -- that's going to include a ton of things that third parties won't want.  (For example, includes like rules.mk.)
Attachment #793128 - Flags: review?(nalexander) → feedback+
> I'm confused about how this will be consumed.  Specifying .classpath suggests an Eclipse project (but then there should be .project, no)?

Yes, it will be an Eclipse project. The .project file should have been included in the patch, but I guess I missed it. The updated patch has it included.
Attachment #793128 - Attachment is obsolete: true
Attachment #793197 - Flags: review?(nalexander)
Comment on attachment 793127 [details] [diff] [review]
library-project.diff

Review of attachment 793127 [details] [diff] [review]:
-----------------------------------------------------------------

Brad should probably review these GeckoView changes.
Attachment #793127 - Flags: review?(cpeterson) → review?(blassey.bugs)
Comment on attachment 793125 [details] [diff] [review]
disable-content-providers.diff

Review of attachment 793125 [details] [diff] [review]:
-----------------------------------------------------------------

Brad should probably review these GeckoView changes.
Attachment #793125 - Flags: review?(cpeterson) → review?(blassey.bugs)
Comment on attachment 793197 [details] [diff] [review]
add-library-project-directory.diff

Review of attachment 793197 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.
Attachment #793197 - Flags: review?(nalexander) → review+
Comment on attachment 793125 [details] [diff] [review]
disable-content-providers.diff

Review of attachment 793125 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/GeckoView.java
@@ +42,5 @@
> +        // If running outside of a GeckoActivity (eg, from a library project),
> +        // load the native code and disable content providers
> +        if (!(context instanceof GeckoActivity)) {
> +            BrowserDB.setEnableContentProviders(false);
> +        }

Just wanted to point out that this code won't get hit in Fennec because it is after the doInit check. This would also be true of any user that set doinit to fale, but they'd already be a little screwed anyway.
Attachment #793125 - Flags: review?(blassey.bugs) → review+
Comment on attachment 793127 [details] [diff] [review]
library-project.diff

Review of attachment 793127 [details] [diff] [review]:
-----------------------------------------------------------------

You have the basics here (stubbed out or default implementations of GeckoInterface functions), but the simple cast of the Context to an Activity seems wrong.

::: mobile/android/base/GeckoView.java
@@ +135,5 @@
> +        return null;
> +    }
> +
> +    public Activity getActivity() {
> +        return (Activity)mContext;

not a fan of this. There is a reason that there is a separate getContext() and getActivity(). Also, if this were "the right thing to do", callers of getActivity() could instead call (Activity)getContext().

Instead, let's provide a BaseGeckoInterface class that takes an Activity in the constructor and stubs out or provides default implementations for everything else (like you've done here).

To make things "just work" we can do an instanceof test on the context we get in the GeckoView constructor and construct a BaseGeckoInterface using that.
Attachment #793127 - Flags: review?(blassey.bugs) → review-
Attached patch library-project.diff (obsolete) — Splinter Review
> callers of getActivity() could instead call (Activity)getContext().

AFAIK, views do not have a getActivity() function so the only way to get an activity is to cast the context given in the constructor or returned by getContext() to an activity.

Regardless, other methods in the new BaseGeckoInterface need a context, so its constructor takes a context that is then cast to an activity. GeckoView checks that the context given to BaseGeckoInterface is, in fact, an instance of Activity.
Attachment #793127 - Attachment is obsolete: true
Attachment #793741 - Flags: review?(blassey.bugs)
Comment on attachment 793197 [details] [diff] [review]
add-library-project-directory.diff

Mike, could you look at the changes to packager.mk?

Context: this series of patches wraps up some of the Android assets and some new project files for consumption by third party developers who want to embed GeckoView on Android.  We create two zip files in the packaging step; third parties would configure an Eclipse (or other) project using the assets and the project files.

1.  It just occurred to me that some of the build artifacts that get zipped in the packaging step might not be present during some of the |make package| invocations on build bots.  If you see anything obvious, can you say?

2.  Eventually we want to distribute these zips via the buildbots.  Is there anything else needed except an UPLOAD_EXTRA_FILES line (like robocop.apk)?

3.  Should we be building these zips only conditionally (say for local and Nightly builds only)?

Thanks!
Attachment #793197 - Flags: review+ → review?(mh+mozilla)
Comment on attachment 793197 [details] [diff] [review]
add-library-project-directory.diff

Review of attachment 793197 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/mozapps/installer/packager.mk
@@ +355,5 @@
> +  cp bin/libmozglue.so bin/lib/libplugin-container.so ../mobile/android/geckoview_library/libs/$(ABI_DIR)/ && \
> +  cp -R ../mobile/android/base/res ../mobile/android/geckoview_library && \
> +  ( cd ../mobile/android && \
> +    $(ZIP) -r ../../dist/geckoview_library/geckoview_library.zip geckoview_library) && \
> +  $(ZIP) -d geckoview_library/geckoview_library.zip geckoview_library/backend.mk geckoview_library/Makefile

I'd rather see this as a $(MAKE) -C $(DEPTH)/mobile/android/geckoview_library package

with a package rule in mobile/android/geckoview_library/Makefile.in

That'd be more readable.

Note $(ZIP) has a -x option to exclude files when creating the archive instead of removing them with -d afterwards.
Attachment #793197 - Flags: review?(mh+mozilla) → review-
Comment on attachment 793741 [details] [diff] [review]
library-project.diff

Review of attachment 793741 [details] [diff] [review]:
-----------------------------------------------------------------

r=blassey with nits addressed

::: mobile/android/base/BaseGeckoInterface.java
@@ +53,5 @@
> +    }
> +
> +    public SensorEventListener getSensorEventListener() {
> +        return null;
> +    }

file some follow up bugs to add set<>Listener() methods

@@ +55,5 @@
> +    public SensorEventListener getSensorEventListener() {
> +        return null;
> +    }
> +
> +    public void doRestart() {}

file a follow up bug to implement this (and put the bug number in a comment)

@@ +75,5 @@
> +    }
> +
> +    public void addPluginView(final View view, final RectF rect, final boolean isFullScreen) {}
> +
> +    public void removePluginView(final View view, final boolean isFullScreen) {}

guess what? file follow ups for implementations.

Actually, file a follow up for each method that is just stubbed out to get an implementation

::: mobile/android/base/GeckoView.java
@@ +45,5 @@
>  
>          // If running outside of a GeckoActivity (eg, from a library project),
>          // load the native code and disable content providers
>          if (!(context instanceof GeckoActivity)) {
> +            setGeckoInterface(context);

do your instanceof check here and create a BaseGeckoInterface to pass to setGeckoInterface(). Also, do a (getGeckoInterface() != null) check to make sure we're not overwriting the interface that the embedder has already set.

@@ +97,5 @@
>              requestRender();
>          }
>      }
>  
> +    public static void setGeckoInterface(final Context context) {

keep setGeckoInterface(GeckoInterface) because I'd like an implementer to be able to call it
(In reply to Shane Tully (:stully: from comment #45)
> Created attachment 793741 [details] [diff] [review]
> library-project.diff
> 
> > callers of getActivity() could instead call (Activity)getContext().
> 
> AFAIK, views do not have a getActivity() function so the only way to get an
> activity is to cast the context given in the constructor or returned by
> getContext() to an activity.
I was referring to GeckoInterface.getActivity()
Comment on attachment 793741 [details] [diff] [review]
library-project.diff

Review of attachment 793741 [details] [diff] [review]:
-----------------------------------------------------------------

r=blassey with nits addressed

::: mobile/android/base/BaseGeckoInterface.java
@@ +53,5 @@
> +    }
> +
> +    public SensorEventListener getSensorEventListener() {
> +        return null;
> +    }

file some follow up bugs to add set<>Listener() methods

@@ +55,5 @@
> +    public SensorEventListener getSensorEventListener() {
> +        return null;
> +    }
> +
> +    public void doRestart() {}

file a follow up bug to implement this (and put the bug number in a comment)

@@ +75,5 @@
> +    }
> +
> +    public void addPluginView(final View view, final RectF rect, final boolean isFullScreen) {}
> +
> +    public void removePluginView(final View view, final boolean isFullScreen) {}

guess what? file follow ups for implementations.

Actually, file a follow up for each method that is just stubbed out to get an implementation

::: mobile/android/base/GeckoView.java
@@ +45,5 @@
>  
>          // If running outside of a GeckoActivity (eg, from a library project),
>          // load the native code and disable content providers
>          if (!(context instanceof GeckoActivity)) {
> +            setGeckoInterface(context);

do your instanceof check here and create a BaseGeckoInterface to pass to setGeckoInterface(). Also, do a (getGeckoInterface() != null) check to make sure we're not overwriting the interface that the embedder has already set.

@@ +97,5 @@
>              requestRender();
>          }
>      }
>  
> +    public static void setGeckoInterface(final Context context) {

keep setGeckoInterface(GeckoInterface) because I'd like an implementer to be able to call it
Attachment #793741 - Flags: review?(blassey.bugs) → review+
Attachment #793197 - Attachment is obsolete: true
Attachment #794744 - Flags: review?(mh+mozilla)
Blocks: 908744
Blocks: 908752
Blocks: 908755
Blocks: 908756
Blocks: 908760
Blocks: 908770
Blocks: 908772
Blocks: 908773
Blocks: 908775
Blocks: 908779
Blocks: 908781
Blocks: 908783
Blocks: 908785
Blocks: 908786
Blocks: 908787
Blocks: 908788
Blocks: 908789
Blocks: 908790
Blocks: 908791
Blocks: 908792
Attachment #793741 - Attachment is obsolete: true
Comment on attachment 794744 [details] [diff] [review]
add-library-project-directory.diff

Review of attachment 794744 [details] [diff] [review]:
-----------------------------------------------------------------

Almost there. You'll need someone else's review for the xml files, though.

::: mobile/android/geckoview_library/Makefile.in
@@ +21,5 @@
> +include $(topsrcdir)/config/rules.mk
> +
> +package:
> +	# Make directory for the zips
> +	$(MKDIR) -p ../../../dist/geckoview_library

Please use $(DIST) instead of ../../../dist.

@@ +25,5 @@
> +	$(MKDIR) -p ../../../dist/geckoview_library
> +
> +	# Zip the assets
> +	cd ../../../dist/fennec; \
> +	$(ZIP) -r ../geckoview_library/geckoview_assets.zip assets

This is going to break some of the .so that need to *not* be deflated. See SZIP_LIBRARIES in packager.mk.

@@ +29,5 @@
> +	$(ZIP) -r ../geckoview_library/geckoview_assets.zip assets
> +
> +	# Make empty directories to fit an Android project structure
> +	$(MKDIR) -p bin gen libs/$(ABI_DIR) src
> +	

Please remove the various empty tabs in this file.

@@ +41,5 @@
> +	cp -R ../base/res .
> +	
> +	# Zip the directory
> +	cd ..; \
> +	$(ZIP) -r ../../dist/geckoview_library/geckoview_library.zip geckoview_library --exclude geckoview_library/backend.mk geckoview_library/Makefile

Does the zip need to have a root geckoview_library directory?
Attachment #794744 - Flags: review?(mh+mozilla) → feedback+
Attachment #794744 - Attachment is obsolete: true
Attachment #794925 - Flags: review?(mh+mozilla)
Comment on attachment 794925 [details] [diff] [review]
add-library-project-directory.diff

Review of attachment 794925 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/geckoview_library/Makefile.in
@@ +25,5 @@
> +	$(MKDIR) -p $(DIST)/geckoview_library
> +
> +	# Zip the assets
> +	cd $(DIST)/fennec; \
> +	$(ZIP) -0 -r ../geckoview_library/geckoview_assets.zip assets

You're effectively making all assets uncompressed.
BTW, since this is not going to be an apk, how is an apk going to be created from this? Because that's actually where that matters most, that some files are kept uncompressed...

::: toolkit/mozapps/installer/packager.mk
@@ +345,5 @@
>  endif
>  
> +# Create geckoview_library/geckoview_{assets,library}.zip for third-party GeckoView consumers.
> +INNER_MAKE_GECKOVIEW_LIBRARY= \
> +  $(MAKE) -C ../mobile/android/geckoview_library package ABI_DIR=$(ABI_DIR) dist=$(DIST)

You don't need to pass DIST.
Attachment #794925 - Flags: review?(mh+mozilla)
Comment on attachment 794925 [details] [diff] [review]
add-library-project-directory.diff

Review of attachment 794925 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/geckoview_library/Makefile.in
@@ +25,5 @@
> +	$(MKDIR) -p $(DIST)/geckoview_library
> +
> +	# Zip the assets
> +	cd $(DIST)/fennec; \
> +	$(ZIP) -0 -r ../geckoview_library/geckoview_assets.zip assets

As per the discussion on irc, you have my r+ if you remove that -0 and remove the dist=$(DIST) from packager.mk
Comment on attachment 794786 [details] [diff] [review]
library-project.diff

gah, wrong one
Attachment #794786 - Flags: review+
Attachment #794925 - Attachment is obsolete: true
Depends on: 908929
Comment on attachment 794942 [details] [diff] [review]
add-library-project-directory.diff

Carrying forward r=blassey from comment 50
Attachment #794942 - Flags: review+
Comment on attachment 794786 [details] [diff] [review]
library-project.diff

Carrying forward r=glandium from comment 58
Attachment #794786 - Flags: review+
I tried a build and package. After, <objdir>/dist/geckoview_library/*.zip files were created.

When I tired to create an Eclipse project (what a nightmare) I ended up with some missing references to a "geckoview_library/bin/geckoview.jar". Any idea what's going on? There is no "bin/geckoview.jar" file in my ZIP files.
(In reply to Mark Finkle (:mfinkle) from comment #63)
> I tried a build and package. After, <objdir>/dist/geckoview_library/*.zip
> files were created.
> 
> When I tired to create an Eclipse project (what a nightmare) I ended up with
> some missing references to a "geckoview_library/bin/geckoview.jar". Any idea
> what's going on? There is no "bin/geckoview.jar" file in my ZIP files.

Did you followed the instructions in https://wiki.mozilla.org/Mobile/GeckoView ?
According to those instructions you have to build 2 eclipse projects: a library project (named GeckoView) which must be imported from unzipped geckoview_library.zip and another eclipse android project (e.g. GeckoViewExample made by stully) which uses the first library project.
If you do all things correctly, after building GeckoViewExample project you will also build GeckoView library project. The "bin/geckoview.jar" is located under GeckoView/bin/geckoview.jar
(In reply to Mark Finkle (:mfinkle) from comment #63)
> I tried a build and package. After, <objdir>/dist/geckoview_library/*.zip
> files were created.
> 
> When I tired to create an Eclipse project (what a nightmare) I ended up with
> some missing references to a "geckoview_library/bin/geckoview.jar". Any idea
> what's going on? There is no "bin/geckoview.jar" file in my ZIP files.

Notice that although in GeckoViewExample project which stully uploaded in https://wiki.mozilla.org/Mobile/GeckoView the library project is called "geckoview_library" but after importing geckoview_library from the zipped file geckoview_library.zip the imported project in eclipse will have the name "GeckoView".
I think this is the source of your problem. The solution is:
Right_click on GeckoViewExample project in eclipse -> properties -> Android -> delete reference to geckoview_library (it must have a red cross beside itself) -> read "GeckoView" instead
I also have a problem too:
I can import, compile and build both GeckoView library project and GeckoViewExample project in eclipse. But when I run the GeckoViewExample app on my Android 4.2.2 device, it issues the error: Unfortunately, GeckoView Example has stopped. -> OK
I can't figure out what can be the problem. Anyone has any idea?
Backed out 39ee92c06d6b because GeckoView breaks Android's l10n repacks:
https://hg.mozilla.org/integration/mozilla-inbound/rev/35d97694d436
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This patch fixes the bug where any drawable used in a GeckoView-based Application would potentially reorder the R.java identifiers and cause lookups in org.mozilla.gecko compiled JARs to fail. The two resources where this happens is: shadow and scrollbar, since they are the only ones hit during typical use of GeckoView.

The problem seems to be that the JARs in geckoview_library are compiled with specific values for the R.type.resource and when the Application that uses geckoview_library mixes in it's resources the R.java values can be changed. This is expected. What's not expected is that geckoview_library does not care about the changed values. It only knows about the original values.

Long story short, we can make it work if we dynamically load the resource identifiers for any *core* GeckoView resource.

99% of the resources in the geckoview_library will never be needed by the Application, so we could remove them in a separate bug.
Attachment #797273 - Flags: review?(bugmail.mozilla)
Whiteboard: [leave open]
(In reply to Chris Peterson (:cpeterson) from comment #69)
> Backed out 39ee92c06d6b because GeckoView breaks Android's l10n repacks:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/35d97694d436

Link to the bustage:
https://tbpl.mozilla.org/?showall=1&jobname=l10n%20nightly&rev=416075f77249
Attachment #797273 - Flags: review?(bugmail.mozilla) → review+
Attached patch allow-mozconfig-disable (obsolete) — Splinter Review
This patch adds a mozconfig option (--disable-geckoview-library) so we can skip any GeckoView work during the packaging.
Attachment #797650 - Flags: review?(mh+mozilla)
Attached patch disable-geckoview-l10n (obsolete) — Splinter Review
Disable geckoview-library on any l10n builds. We are not ready to make it work there.
Attachment #797651 - Flags: review?(mh+mozilla)
Comment on attachment 797650 [details] [diff] [review]
allow-mozconfig-disable

Review of attachment 797650 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +5133,5 @@
> +    MOZ_DISABLE_GECKOVIEW=1,
> +    MOZ_DISABLE_GECKOVIEW=)
> +
> +if test -n "$MOZ_DISABLE_GECKOVIEW"; then
> +    AC_DEFINE(MOZ_DISABLE_GECKOVIEW)

You're not using the AC_DEFINE, so no need for it.

(AC_SUBST for things accessed in makefiles, AC_DEFINE for things accessed in code (and even for that, AC_DEFINE is most of the time overkill))

That being said, since this is a l10n releng build specific option, it would be better not to add one to the already long list of configure flags available. Just keep the AC_SUBST, and set MOZ_DISABLE_GECKOVIEW in the l10n mozconfigs.
Attachment #797650 - Flags: review?(mh+mozilla) → review-
Attachment #797651 - Flags: review?(mh+mozilla)
This patch removes the AC_DEFINE support and just keeps the AC_SUBST support
Attachment #797650 - Attachment is obsolete: true
Attachment #799444 - Flags: review?(mh+mozilla)
This patch disables GeckoView for l10n builds by exporting the MOZ_DISABLE_GECKOVIEW flag directly. Tested locally and it does disable the library from being packaged.
Attachment #797651 - Attachment is obsolete: true
Attachment #799445 - Flags: review?(mh+mozilla)
Attachment #799444 - Flags: review?(mh+mozilla) → review+
Comment on attachment 799445 [details] [diff] [review]
disable-geckoview-l10n v0.2

Review of attachment 799445 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/config/mozconfigs/android-armv6/l10n-nightly
@@ +33,5 @@
>  
>  export JAVA_HOME=/tools/jdk6
>  export MOZILLA_OFFICIAL=1
>  export MOZ_PKG_SPECIAL=armv6
> +export MOZ_DISABLE_GECKOVIEW=1

I think you don't need to export, but okay either way.
Attachment #799445 - Flags: review?(mh+mozilla) → review+
Whiteboard: [leave open]
Attachment #794942 - Flags: review?(mh+mozilla)
Comment on attachment 794942 [details] [diff] [review]
add-library-project-directory.diff

Actually, Mike already reviewed this, so I'm carrying it forward:
https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=880118&attachment=794925
Attachment #794942 - Flags: review?(mh+mozilla) → review+
I am using geckoview lib. I got an resource not found exception.
I solved this excepiton in a tricky way.
I unpack gecko-browser.jar, rm the R classes and then re-pack to gecko-browser.jar
replace origin gecko-broser.jar.
Then ant debug. install apk to device. This will result java.lang.NoClassDefFoundError: org.mozilla.gecko.R$styleable.
Then copy the geckoview fold in gen/org/mozilla/,rename to gecko. 
Edit the gen/org/mozilla/gecko/R.java, change package name to org.mozilla.gecko
then ant debug, install apk to device.
It works. Because the classloader can load the right R.class which have the right int id value.

And I found your are working on fix the issue.https://bugzilla.mozilla.org/attachment.cgi?id=797273&action=diff
I think there are two methons to avoid R.java reorder.
1. getResources().getIdentifier(), as in the diff
2. Change the R.java's package name to "org.mozilla.geckoview", Do not package R.class into gecko-browser.jar. Actually I only try in a HelloProject, Because I don't known how to change the build script this project. Any suggestion is appreciated

P.S. I tried another method. Change the gecko library project's package name to "org.mozilla.gecko". But I got a so runtime exception. Is gecko library project's package name must be "org.mozilla.geckoview"?

(In reply to Mark Finkle (:mfinkle) from comment #70)
> Created attachment 797273 [details] [diff] [review]
> Pull resources dynamically to avoid R.java reorder
> 
> This patch fixes the bug where any drawable used in a GeckoView-based
> Application would potentially reorder the R.java identifiers and cause
> lookups in org.mozilla.gecko compiled JARs to fail. The two resources where
> this happens is: shadow and scrollbar, since they are the only ones hit
> during typical use of GeckoView.
> 
> The problem seems to be that the JARs in geckoview_library are compiled with
> specific values for the R.type.resource and when the Application that uses
> geckoview_library mixes in it's resources the R.java values can be changed.
> This is expected. What's not expected is that geckoview_library does not
> care about the changed values. It only knows about the original values.
> 
> Long story short, we can make it work if we dynamically load the resource
> identifiers for any *core* GeckoView resource.
> 
> 99% of the resources in the geckoview_library will never be needed by the
> Application, so we could remove them in a separate bug.
We are implementing GeckoView in our project. But we have a problem with clear cookies.
Can somebody say, what class clear cookies in geckoview? Urgent! Best Regards
(In reply to Ali Kasimoglu from comment #86)
> We are implementing GeckoView in our project. But we have a problem with
> clear cookies.
> Can somebody say, what class clear cookies in geckoview? Urgent! Best Regards

You're more likely to get an answer if you ask on the mobile-firefox-dev mailing list [1], or in the #mobile IRC channel [2].

[1] https://mail.mozilla.org/listinfo/mobile-firefox-dev
[2] https://wiki.mozilla.org/IRC
(In reply to Botond Ballo [:botond] from comment #87)
> (In reply to Ali Kasimoglu from comment #86)
> > We are implementing GeckoView in our project. But we have a problem with
> > clear cookies.
> > Can somebody say, what class clear cookies in geckoview? Urgent! Best Regards
> 
> You're more likely to get an answer if you ask on the mobile-firefox-dev
> mailing list [1], or in the #mobile IRC channel [2].
> 
> [1] https://mail.mozilla.org/listinfo/mobile-firefox-dev
> [2] https://wiki.mozilla.org/IRC

thank you
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.