1058160 - Specify main activity org.mozilla.fennec.App with a default intent over org.mozilla.search.MainActivity

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

Pretty sure this is the reason why our AppThwack tests are being ran against the activity (see link below):

   org.mozilla.search.MainActivity

instead of org.mozilla.fennec.App

from category android.intent.category.LAUNCHER

in https://github.com/mozilla/fennec-search/blob/master/manifests/SearchAndroidManifest_activities.xml.in

a default intent is defined for that activity

See https://appthwack.com/project/fennec2/run/78233/job/240882 logs for each device where org.mozilla.search.MainActivity is ran against in their launch tests.

Comment 1

[Aaron Train [:aaronmt]]

$> aapt dump badging fennec-34.0a1.multi.android-arm.apk

launchable-activity: name='org.mozilla.search.MainActivity'  label='Nightly Search' icon='res/drawable-mdpi/search_launcher.png'

Comment 2

[Nick Alexander :nalexander [he/him]]

I'll take a look at this right now.

Comment 3

[Nick Alexander :nalexander [he/him]]

This appears to be a subtle interaction between the activity-alias defining .App and the launchable-activity detection.  I'm going to test putting the main launcher on o.m.g.BrowserApp.

Comment 4

[Nick Alexander :nalexander [he/him]]

You can test what activities are launchable by building and packaging and running:

chocho:gecko-dev nalexander$ aapt dump badging objdir-droid/dist/fennec-34.0a1.en-US.android-arm.apk | grep activity
launchable-activity: name='org.mozilla.gecko.BrowserApp'  label='Fennec nalexander' icon=''
launchable-activity: name='org.mozilla.search.MainActivity'  label='Fennec Search' icon='res/drawable-mdpi/search_launcher.png'
c

You can launch the default, which I surmise is the first launchable-activity, using:

chocho:gecko-dev nalexander$ adb shell am start -a android.intent.action.MAIN org.mozilla.fennec_nalexander
Starting: Intent { act=android.intent.action.MAIN pkg=org.mozilla.fennec_nalexander }

I can see no way to order the launchable-activities, other than by the manifest order.

Comment 5

[Nick Alexander :nalexander [he/him]]

It might be better to configure AppThwack/Monkey with an explicit activity to test rather than apply the patch I am going to post, although it appears that upgrading does the right thing, and I have no reason to expect any other problems.

Comment 6

[Nick Alexander :nalexander [he/him]]

> I can see no way to order the launchable-activities, other than by the
> manifest order.

For the record, the DEFAULT category stuff is not relevant.  In the Search manifests, it's not on the relevant <intent-filter>; and in the Fennec manifest, it appears to have no effect.

Comment 7

[Nick Alexander :nalexander [he/him]]

Attachment: Make o.m.g.BrowserApp the LAUNCHER activity. r=bnicholson

There is a subtle interaction with <activity-alias> and <activity>:
<activity-alias> entries appear to rank lower than <activity> entries
when determining the activity to launch in response to a MAIN intent.  I
can find no way to order launchable activities other than by order in
manifest (earliest appears to win).  This pushes the MAIN
<intent-filter> onto the actual <activity>, to work around the problem.

Sure wish this wasn't so late in the cycle, but local testing shows no
migration/upgrade problems.

Comment 8

[Nick Alexander :nalexander [he/him]]

Attachment: Make o.m.g.BrowserApp LAUNCHER activity default and high priority. r=bnicholson

In order to launch in response to the MAIN activity (via |adb shell am
start -a android.intent.action.MAIN org.mozilla.fennec|, for example),
the activity must have category default.  That is added automatically to
<activity> elements that have category LAUNCHER, but apparently not to
<activity-alias> elements.  This patch adds it manually.

In general, <intent-filters> are prioritized by their order in the
manifest file.  To avoid future confusion, this patch bumps the
android:priority of the existing filter.

Comment 9

[Nick Alexander :nalexander [he/him]]

https://hg.mozilla.org/integration/fx-team/rev/62498bd570c8

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/62498bd570c8

Comment 11

[Nick Alexander :nalexander [he/him]]

AaronMT: can we get a status update on AppThwack?  Did this help?  Hurt?  No difference?

Comment 12

[Aaron Train [:aaronmt]]

I havn't executed a run with Nightly but I do see that the activity targeted (after APK upload, they provide a nice summary) is still org.mozilla.search.MainActivity

Checking on the APK I see

$ ./aapt d badging fennec-35.0a1.multi.android-arm.apk 

launchable-activity: name='org.mozilla.search.MainActivity'  label='Nightly Search' icon='res/drawable-mdpi/search_launcher.png'

?

Comment 13

[Aaron Train [:aaronmt]]

I guess, re-open to see what why Android is making the launchable-activity that one

Comment 14

[Nick Alexander :nalexander [he/him]]

(In reply to Aaron Train [:aaronmt] from comment #13)
> I guess, re-open to see what why Android is making the launchable-activity
> that one

I think this is an |aapt dump badging| issue.  It doesn't recognize <activity-alias> intent filters.  Better to install and try with |adb shell am start ... MAIN|.

Comment 15

[Aaron Train [:aaronmt]]

Still something's not right as AppThwack is still detecting from search.MainActivity as the launchable activity: https://appthwack.com/public/06817934a8a2247331c390944

Locally though, 

$ adb shell am start -a android.intent.action.MAIN -n org.mozilla.fennec/.App
Starting: Intent { act=android.intent.action.MAIN cmp=org.mozilla.fennec/.App }

Comment 16

[Aaron Train [:aaronmt]]

This is a blocker for us (QE) on 35 as we'd like to continue to use AppThwack for testing against the browser.

E.g, we just 35 on Aurora and it was executed against the search activity

https://appthwack.com/public/d63b5d787befc927be2d8ee29?view_mode=screenshots

Comment 17

[Nick Alexander :nalexander [he/him]]

OK.  I'll try to figure out how to improvethis.

Comment 18

[Aaron Train [:aaronmt]]

Any update?

Comment 19

[Nick Alexander :nalexander [he/him]]

(In reply to Aaron Train [:aaronmt] from comment #18)
> Any update?

Sorry, no.  I think I know how to fix it but I don't feel like we can do this right now: it's possible we bust the App icon on the homescreen and/or share intents and/or saved bookmarks on the homescreen.  I hoped to get time to evaluate all the ways this could bust but I haven't had that time.

Comment 20

[Mark Finkle (:mfinkle) (use needinfo?)]

I think we need to look into what AppThwack can do to make this work too.

Comment 21

[Aaron Train [:aaronmt]]

I checked out 36-38 APK's and while an aapt (21.1.1) dump doesn't seem to directly dump a specified 'launchable-activity' this made me suspicious. I conducted a short run against 38 and they seem to be picking up the right main activity we want to focus on. This seem to just work now. Maybe we did some related refactoring or they have changed something on their end.

https://appthwack.com/public/e046b934afbc996885c31e922?view_mode=screenshots (see main browser activity is ran finally). 

In any case, it looks like we can resume full AppThwack service testing with 36 or 37.

Comment 22

[Nick Alexander :nalexander [he/him]]

(In reply to Aaron Train [:aaronmt] from comment #21)
> I checked out 36-38 APK's and while an aapt (21.1.1) dump doesn't seem to
> directly dump a specified 'launchable-activity' this made me suspicious. I
> conducted a short run against 38 and they seem to be picking up the right
> main activity we want to focus on. This seem to just work now. Maybe we did
> some related refactoring or they have changed something on their end.

Thanks for checking, this is great!  They probably launch intent.MAIN now, which works with our <activity-alias>; I suspect they were fishing launchable-activity instead before.