For reference:
https://learn.microsoft.com/en-us/xamarin/essentials/open-browser?context=xamarin%2Fandroid&tabs=android
https://learn.microsoft.com/en-us/xamarin/essentials/web-authenticator?context=xamarin%2Fandroid&tabs=android
I am using both of these features and everything works as expected when I was on an emulator that targeted android 11. It was working without adding the recommended configurations from the documentation above.
when the app is run on an emulator that targets android 13, neither of these features works anymore. the browser just opens and never finished loading the page. If the browser is closed the app will recognize a cancel method was called.
from the documentation, I have tried with and without the configurations and to no avail.
<queries>
<intent>
<action android:name="android.support.customtabs.action.CustomTabsService" />
</intent>
<intent>
<action android:name="android.intent.action.VIEW" />
<data android:scheme="http"/>
</intent>
<intent>
<action android:name="android.intent.action.VIEW" />
<data android:scheme="https"/>
</intent>
</queries>
any suggestions?
Related
After testing on real device I want to navigate dynamic link to app or app/play store directly without having bridge of browser, currently dynamic link is working fine but it is navigating to browser first and then to app if it is installed else navigates to browser first and then play store or app store.
I need to do direct navigation without going to browser first.
enter image description here
Steps which I followed.
Created dynamic link using Firebase.
Added behaviour of ios and android for both the scenario and linked app respectively.
3.Added team id, app store id to project setting in firebase and apple-app-site-association file is up on domain which created by dynamic link.
4.Added Android intent filter in androidMainfest.xml
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" android:host="www.example.com"/
</intent-filter>
Associated bundle id, domain to xcode for ios.
Installed package for dynamic link in project.
yarn add #react-native-firebase/dynamic-links
cd ios/ && pod installenter image description here
Go to campaign tracking, social tags and advanced options inside dynamic link tab, and check the check box skip the app preview page (not recommended). It works for me
I'm trying to get a sample application provided by the media streaming framework Gstreamer to work as a Xamarin Android application. The application plays and displays an RTSP stream. To do so, I took the sample Android application (Java-based, with some C++ interop) from here: https://github.com/centricular/android_rtsp_example and built it as an AAR file in Android studio (as described here https://developer.android.com/studio/projects/android-library).
I then referenced the AAR file from my Xamarin application as described here: https://learn.microsoft.com/en-us/xamarin/android/platform/binding-java-library/binding-an-aar.
I then went into my AndroidManifest.xml file for the Xamarin application and specified the Activity that came along with the AAR file as my main activity. Doing all of this, as far as I know, I should basically have something that's essentially the same as the original APK built from Android Studio in pure Java, but running in the Xamarin framework. So far, so good. Everything built and deployed. The app started up and ran just like it did when built from Android Studio except for one thing: the playback was very, very slow and choppy, with a lot of compression artifacts. This was NOT the case when running the same code/pipeline from the non-Xamarin application. My question is, what could cause this? Did I do something dumb when trying to wrap this APK in Xamarin and launch it? Did I fail to turn on some hardware acceleration that is enabled in the APK that's not enabled in the Xamarin app? Some aspect of playback is worse when wrapped in Xamarin, but I'm not sure exactly what it could be.
Ultimately the way in which the GStreamer application is drawing in Android isn't understood by me, but I know the actual drawing code is implemented in C++ and there's a Java/C++ interoperability layer that's involved (JNI_OnLoad and RegisterNatives is involved). So, it could be that something is no longer accelerated on the hardware, but I'm unsure how that could be.
So in summary:
Existing APK can be built and ran on an Android phone. It plays an RTSP stream very well, with no jitter or compression artifacts.
Building the APK as an AAR and referencing it from Xamarin, I'm able to get the player to launch just as it did when built as an APK. Button taps, etc. work and the video player shows and connects to the RTSP stream.
Performance is much, much poorer in the Xamarin application, with severe jitter, data loss and compression artifacts showing up in the visual window.
Other than build settings (for example, to produce an AAR instead of an APK from Android Studio) and modifying the AndroidManifest.xml file, no code changes were made (See below for my AndroidManifest.xml file).
Any thoughts or feedback?
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0" package="com.companyname.XamarinGstreamerTestAndroid" android:installLocation="auto">
<uses-sdk android:minSdkVersion="21" android:targetSdkVersion="25" />
<application android:allowBackup="true"
android:icon="#mipmap/ic_launcher"
android:label="#string/button_play"
android:roundIcon="#mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="#style/AppTheme">
</application>
<activity android:name=".RTSPExample"
android:label="#string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</manifest>
I've updated my Android Wear watch face according to the official API, and overall it's gone pretty well. One thing I'm stuck on, however, is launching the companion (handheld) config activity from within the Android Wear app. I just can't get the "gear" icon to appear on my watch face preview image in the AW app - AW isn't recognizing my config link.
Just to be clear, every other part of this app is working OK; the app runs fine on both devices, the watch face works, Data API works, auto-install works. It's just this link to my settings activity that's borked.
Here's the relevant portion of my handheld app's manifest:
<activity
android:name=".google.WatchfaceSettingsActivity"
android:label="#string/pref_wear_wf_title" >
<intent-filter>
<action android:name="com.mypackage.google.CONFIG_WEAR_WATCHFACE" />
<category android:name="com.google.android.wearable.watchface.category.WEARABLE_CONFIGURATION" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
And here's the matching bit of my wearable app's manifest:
<service
android:name=".wear.WatchFaceService"
android:label="#string/app_name"
android:permission="android.permission.BIND_WALLPAPER" >
<meta-data
android:name="android.service.wallpaper"
android:resource="#xml/watch_face" />
<meta-data
android:name="com.google.android.wearable.watchface.companionConfigurationAction"
android:value="com.mypackage.google.CONFIG_WEAR_WATCHFACE" />
<intent-filter>
<action android:name="android.service.wallpaper.WallpaperService" />
<category
android:name="com.google.android.wearable.watchface.category.WATCH_FACE" />
</intent-filter>
</service>
As I understand it, the crucial part is the com.mypackage.google.CONFIG_WEAR_WATCHFACE string, which appears in both manifests. Everything looks OK to me - is there just something stupid I'm missing?
Almost correct, but it looks like the intent filter category for your handheld Activity is set incorrectly as WEARABLE_CONFIGURATION. It should be:
com.google.android.wearable.watchface.category.COMPANION_CONFIGURATION
More info: http://developer.android.com/training/wearables/watch-faces/configuration.html
I am new to windows phone app development. Is it possible to open windows phone app via browser url. If possible, please someone help me.
How to implement my very own URI scheme on Android
please visit the above url;
but its possible in the android
<activity
android:name="TabHost"
android:label="#string/app_name"
android:screenOrientation="portrait" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
<intent-filter>
<data android:scheme="myschema" />
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
below code is working in windows 8 desktop IE Browser
but its not working in the windows phone
<Applications>
<Application Id="SDKSample.App" Executable="$targetnametoken$.exe" EntryPoint="SDKSample.App">
<Extensions>
<Extension Category="windows.protocol">
<Protocol Name="alsdkcs" m2:DesiredView="useLess"/>
</Extension>
<Extension Category="windows.fileTypeAssociation">
<FileTypeAssociation Name=".alsdkcs" m2:DesiredView="useLess">
<SupportedFileTypes>
<FileType>.alsdkcs</FileType>
</SupportedFileTypes>
</FileTypeAssociation>
</Extension>
</Extensions>
<m3:VisualElements DisplayName="Launcher API C# sample" Description="AssociationLaunching C# sample" ForegroundText="light" BackgroundColor="#00b2f0" Square150x150Logo="Assets\squaretile-sdk.png" Square44x44Logo="Assets\smallTile-Phone-sdk.png">
<m3:DefaultTile ShortName="Launcher API C#" DefaultSize="square150x150Logo" Wide310x150Logo="Assets\tile-sdk.png" Square71x71Logo="Assets\mediumtile-sdk.png">
<m3:ShowNameOnTiles>
<m3:ShowOn Tile="square150x150Logo"/>
<m3:ShowOn Tile="wide310x150Logo"/>
</m3:ShowNameOnTiles>
</m3:DefaultTile>
<m3:SplashScreen Image="Assets\splash-Phone-sdk.png" BackgroundColor="#00b2f0"/>
<m3:ApplicationView MinWidth="width320"/>
</m3:VisualElements>
</Application>
Hell... I got the answer. It's working if I call via javascript
<input id="btnwindowsphone" type="button" class="button" name="" value="open windows phone" onclick="javascript:loadwindowsphone();" /><br /><br />
function loadwindowsphone() {
window.location = 'alsdkcs://hd';
}
You can do the same for Windows phone - registering custom URI scheme that will open your app.
Here are some resources for you:
Auto-launching apps using file and URI associations for Windows Phone 8
URI schemes for launching built-in apps for Windows Phone 8
This documentation article works for Windows Phone 8.1 / Windows Phone 10 Mobile:
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh779670.aspx
If you're running into issues not being able to open the URI scheme you registered it's most likely because you're trying to open it using Internet Explorer / Edge. This will not work.
Instead send yourself an email containing the link or put it down into OneNote - just an external place, that actually links into the browser.
Otherwise IE / Edge will treat your scheme as http://myscheme/ instead of myscheme://.
I'm working on music app for WP7. It downloads music from our servers in form of little segments (each track is devided into 128k encrypted pieces). I'm using AudioPlayerAgent and AudioStreamingAgent to download, decrypt and play music.
Everything works fine, while I start application from visual studio via F5. When I start app from menu on emulator or device, everything works fine except of music is not playing. BackgroundAudioPlayer never starts. Doesn't metter if I try debug or release build, or if I try it on emulator or real device(Nokia Lumia 710 and HTC HD7 Pro).
I think that I have everything correctly setted up in AppManifest:
<Capabilities>
<Capability Name="ID_CAP_GAMERSERVICES" />
<Capability Name="ID_CAP_IDENTITY_DEVICE" />
<Capability Name="ID_CAP_IDENTITY_USER" />
<Capability Name="ID_CAP_LOCATION" />
<Capability Name="ID_CAP_MEDIALIB" />
<Capability Name="ID_CAP_MICROPHONE" />
<Capability Name="ID_CAP_NETWORKING" />
<Capability Name="ID_CAP_PHONEDIALER" />
<Capability Name="ID_CAP_PUSH_NOTIFICATION" />
<Capability Name="ID_CAP_SENSORS" />
<Capability Name="ID_CAP_WEBBROWSERCOMPONENT" />
</Capabilities>
<Tasks>
<DefaultTask Name="_default" NavigationPage="Panorama.xaml" />
<ExtendedTask Name="BackgroundTask">
<BackgroundServiceAgent Specifier="AudioPlayerAgent" Name="AudioPlaybackAgent1" Source="AudioPlaybackAgent1" Type="AudioPlaybackAgent1.AudioPlayer" />
<BackgroundServiceAgent Specifier="AudioStreamingAgent" Name="AudioStreamAgent1" Source="AudioStreamAgent1" Type="AudioStreamAgent1.AudioTrackStreamer" />
</ExtendedTask>
</Tasks>
After some research I found that I can enable hidden console for emulator to see debug log. I tried to track what happens when I start app from emulator menu. In point where BackgroundAudioPlayer should start playing track following message appers:
PID:0E8500C6 TID:0EEE006A Sentinels are Disabled for all processes.PID:0E8500C6 TID:0EC500DE Exception 'Raised Exception' (0xc0008005): Thread-Id=0ec500de(pth=c0654930), Proc-Id=0e8500c6(pprc=c05f3160) 'HeadlessHost.exe', VM-active=0e8500c6(pprc=c05f3160) 'HeadlessHost.exe'
PID:0E8500C6 TID:0EC500DE PC=42a629f7(mscoree3_7.dll+0x000529f7) RA=42ac3ae5(mscoree3_7.dll+0x000b3ae5) SP=0634f6b8, BVA=00000000
I also tried to test app in MarketplaceTestKit if any unsupported Api is causing it, but app passed all test fine.
So my question is: does anybody know, while app is playing only when attached to debugger?
Thank You,
Jan.
You should only have one type of background audio agent in your app.
Based on your description of how you're getting the tracks, it seems that using the streaming agent will be more appropriate.
If you're playing each segment directly (treating it as a separate track) and there isn't an issue with gaps as you switch between segments (tracks) then you could use the playback agent.
Having multiple background audio agents specified can cause your app to crash. Note. You'll have to edit the WMAppManifest file directly to remove the one you don't want.