友盟推送androiddemo

㈠ 友盟-推送-Andorid-後台顯示消息發送成功，設備並沒有收到消息，

黃金問題。
在用戶後台，可以查詢設備狀態，以及設備收發消息情況，能夠查詢到設備的狀態，以及設備的收發歷史情況。

1、如果設備不在線，需要明確幾個步驟:

appkey，message-secret-key, package-name, intent 等是否填寫正確。
使用demo是否OK，替換為自己的appkey, message-secret-key, package-name, intent之後是否work，App是否打開。機型是什麼，網路環境是什麼，機器是否Root過，是否有被手機管理軟體強殺過，是否頻繁切換過網路(或者中止網路)等。後台的長連service是否已經啟動。 (umengService_V1). 通過logcat查看。

2、 設備在線的話，查詢設備收發消息歷史

關於消息發送查詢歷史查詢，有一列叫做「狀態」，有「已送達」和「已取走」兩個。 「已送達」表示是千真萬確的送達設備了。「已取走」表示伺服器下發到設備了，很可能由於網路原因消息丟失了。 「已送達」的情況下，消息沒有收到，很可能是自身集成的錯誤。 這個時候要明確發的是 「通知(notification)」 還是 「消息(message)」。 消息的話，需要一些額外的處理，可以再閱讀一下SDK中關於「消息」的處理。

㈡ 友盟推送android java端的代碼怎麼使用

最好的方法，研讀官方提供的Demo，這里說的Java端應該是前端，即Android App端，在應用程序啟動的時候，開啟推送功能，同時在清單文件移植Demo提供的一些內容，測試幾遍就差不多了。。。

㈢ 友盟推送android設備不在線怎麼解決

Android混淆，又稱Android代碼混淆，是伴隨著Android系統的流行而產生的一種AndroidAPP保護技術，用於保護APP不被破解和逆向分析。 友盟（Umeng），2010年4月在北京成立，是中國最專業、最有數據凝聚力的移動開發者服務平台。友盟提供iOS、Android和Windows Phone等多平台服務。 友盟消息推送，指向指定終端用戶(單播)、 所有終端用戶(廣播) 或 滿足特定條件的終端用戶群(組播)，發送通知或消息。此外，還支持開發者使用 自有的賬號系統(alias) 來發送消息給指定的賬號或者賬號群。 混淆時排除友盟推送的Jar包，只需要在proguard.cfg文件中加入如下配置即可： -dontwarn com.umeng.** -keep class com.umeng*.** {*; }

㈣ 友盟-推送-Andorid-「Alias」是什麼, 該如何使用

不少開發者在使用友盟推送的時候，對Alias的用法和使用場景不是太理解，這篇文章給大家普及一下Alias相關的內容:

我們先從產品層面上對Alias的設計思想說起，這樣能幫助大家更好的理解和使用Alias。在我們官方文檔裡面，Alias的定義是: "設備別名，將別名與設備做綁定，便於部分App開發者使用自有賬號或者第三方賬號體系來做消息推送"。定義裡面涉及到幾個重要的點:
首先，Alias是和設備綁定的，友盟推送對設備的標識是device-token，也就是說，Alias與友盟device-token是綁定對應的。從這個層面來講，Alias可以是開發者的賬號系統(包括第三方賬號體系)，也可以是開發者自己對設備的標識體系(如安卓設備上的imei+mac)，或者是其它的開發者能保證唯一性的ID體系，這些都是由開發者自己決定的。提問中問到是否可以把Alias理解為賬號系統，狹義上講可以這么理解，實際上，友盟推送賦予了Alias更多的靈活性。
其次，結合到越來越多的App提供第三方社交平台賬號登陸的特點，我們在Alias的設計上也充分考慮到了賬號的需求，所以在官方文檔中，我們提到在使用Alias的時候，必須要關聯一個alias_type, 如果是開發者自定義的alias(包括自有賬號系統)，這個alias_type是可以隨便定義的；如果是用了第三方賬號系統，我們預提供了20多種主流的開放平台的賬號類型，如新浪微博(SINA_WEIBO), 微信(WEIXIN)等。填寫alias_type的作用是，友盟推送會和友盟社會化分享服務做數據上的打通，更好的從數據層面發揮價值，為開發者服務。說到這里，我們再次精確一下Alias的概念，即別名(Alias)+別名類型(alias_type)與設備的綁定。
最後，我們來聊聊Alias的用法，這個也是開發者們非常關心的。我們Alias的綁定操作是在SDK端提供的，開發者只需要在SDK端調用mPushAgent.addAlias(alias, alias_type)這個介面，友盟推送SDK就負責把alias+alias_type與友盟的device-token做綁定，將綁定關系回傳到友盟後端伺服器。之後開發者就可以根據自有業務邏輯，調用友盟伺服器端介面，根據Alias來做個性化推送了。由此來看，Alias的作用是能讓開發者結合自有的賬號(此處需要理解成廣義的賬號)體系，來做更個性化、精細化的推送。下圖是一個簡化的Alias架構，幫助大家理解Alias的用法:

關於Alias的相關介面，我們的友盟消息推送Android文檔提供了非常豐富的介面供開發者調用:
[Java] 純文本查看 復制代碼
?
1
2
3
4
5
添加Alias
mPushAgent.addAlias("[email protected]", ALIAS_TYPE.SINA_WEIBO);

移除Alias
mPushAgent.removeAlias("[email protected]", ALIAS_TYPE.SINA_WEIBO);

注意，在App伺服器端調用友盟伺服器端介面做推送的時候，一定不要忘了傳入alias_type的參數。

關於Alias基本的話題差不多解釋清楚了，最後再和大家深入聊聊Alias用作賬號系統涉及到多賬號多設備登陸的問題，這個時候，alias_type就派上用場了，相信看過這個章節後，大家會對我們Alias的設計機制有更深入的理解:
1. 多個賬號登陸同一台設備，具體還要細分為兩種case:
如果是同一個alias_type，那麼以最後綁定的alias為准。舉個例子: (alias_A, alias_type_A)先做了綁定，之後(alias_B, alias_type_A)後做了綁定，那麼，如果這個時候給alias_A發消息，設備是不會收到消息的，因為在友盟推送後台device-token是和最後登陸的alias_B做綁定的。這個在實際業務場景中也成立，最後一個登錄的賬號才是這台設備當前真實的用戶。
如果不是同一個alias_type, 那麼前後兩個綁定的alias均生效。舉個例子: (alias_A, alias_type_A)先做了綁定，之後是(alias_B, alias_type_B)做了綁定，那麼不管是給alias_A發消息，還是給alias_B發消息，設備均能收到消息。因為alias_type變化之後，友盟推送後台確定不了這是同一個用戶(eg: 同一個用戶使用不同平台的賬號登錄)，還是不同的用戶(不同的用戶，使用不同的賬號登錄)，友盟只能簡單的判定這兩個不同alias_type的賬號是兩個不同的賬號。這種場景是需要特別注意的，建議開發者在實際的集成過程中盡量避免這種使用場景。
2. 同一個賬號登錄多台設備:
這種情況處理起來就比較簡單了，即一個alias和多個device-token做綁定。如果給這個alias發消息，我們會給所有和這個alias綁定的設備都去推送消息。

開發者在具體使用過程中，可能會想到Alias做了綁定(addAlias)或者解除(removeAlias)之後,多長時間能在後端生效。 Alias介面，是一個實時的介面，不管是在「測試模式」下，還是在「正式模式」下，都是實時生效的。不過在集成測試階段，還是建議開發者把手頭的設備添加到"測試模式"下的測試設備集合裡面，關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。

㈤ 關於Android 消息推送，有什麼開源的技術方案

Android push message，其伺服器是用了JSP編寫，伺服器與客戶端通訊是通過XML（XMLPP）文件。
首先，下載地址 http://sourceforge.net/projects/androidpn/
我們下載其中的 androidpn-server-0.5.0-bin.zip (18.3 MB) 服務端和androidpn-client-0.5.0.zip(356.1 kB)
客戶端。而服務端是在PC上運行，而且用JSP編寫。需要安裝JAVA，並配置好JAVA_HOME變數。不然運行時
是一閃而過，不能開啟服務端。

其次，配置服務端。服務端是在PC上運行，把androidpn-server-0.5.0-bin.zip解壓在本地，如：E:\android
\androidpn-server-0.5.0 運行以上目錄的\bin\run.bat 來啟動伺服器。此時cmd窗口一直在運行。別關了。
驗證伺服器是否成功。瀏覽器打開 http://127.0.0.1:7070/index.do，出現如下頁，表示伺服器開啟成功。

最後，我們手機端，解壓androidpn-client-0.5.0.zip，導入工程到eclipse。打開res/raw/androidpn.properties
文件配置。
[java] view plain
apiKey=1234567890
xmppHost=192.168.0.5
xmppPort=5222

把192.168.0.5修改為10.0.2.2 【在虛擬機中，虛擬機地址為127.0.0.1，主機地址為 10.0.2.2】
運行客戶端，還需build path設置包含asmack.jar。
右擊此項目（org.androidpn.demoapp.DemoAppActivity）——properties。如圖，打開jaca build path，
添加asmack.jar。 然後在模擬器編譯運行。自此我們都設置完了。下面演示推送。

㈥ android 友盟消息推送 如何保活

㈦ 友盟-推送-Andorid-通過不同的自定義參數打開不同的activity,（通知，消息）

package com.yongtai.o2bra;

import android.app.Notification;
import android.app.NotificationManager;
import android.app.PendingIntent;
import android.content.Context;
import android.content.Intent;
import android.support.v4.app.NotificationCompat;
import android.widget.RemoteViews;

import com.umeng.common.message.Log;
import com.umeng.message.UTrack;
import com.umeng.message.UmengBaseIntentService;
import com.umeng.message.entity.UMessage;
import com.yongtai.common.base.Config;
import com.yongtai.o2bra.buy.OrderInfoActivity;
import com.yongtai.o2bra.feedsbra.BarInfoActivity;

import org.android.agoo.client.BaseConstants;
import org.json.JSONObject;

/**
* Developer defined push intent service.
* Remember to call {@link com.umeng.message.PushAgent#setPushIntentServiceClass(Class)}.
*
* @author lucas
*/
public class MyPushIntentService extends UmengBaseIntentService {
private static final String TAG = MyPushIntentService.class.getName();

@Override
protected void onMessage(Context context, Intent intent) {
super.onMessage(context, intent);
try {
String message = intent.getStringExtra(BaseConstants.MESSAGE_BODY);
UMessage msg = new UMessage(new JSONObject(message));
UTrack.getInstance(context).trackMsgClick(msg);
//後台傳過來的參數，開發人員可根據type來啟動對應的activity，type只自己定義。
//type_id是需要將此參數傳給對應的activity，需要傳什麼都行。
String type =msg.extra.get("type");
String type_id =msg.extra.get("type_id");
Intent intent1=null;
if("proct".equals(type)){
intent1= new Intent(context, BarInfoActivity.class);
intent1.putExtra(Config.INTENT_PARAMS1_SERVICE, type_id);
//啟動activity必須加上Flags
intent1.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
}else if("purchase".equals(type)){
intent1= new Intent(context, OrderInfoActivity.class);
intent1.putExtra(Config.ACTIVITY_ORDER_INFO_TYPE_ID, type_id);
intent1.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
}
showNotification(context, msg, intent1);
} catch (Exception e) {
Log.e(TAG, e.getMessage());
}
}
// 通知欄顯示當前播放信息，利用通知和 PendingIntent來啟動對應的activity
public void showNotification(Context context,UMessage msg,Intent intent) {
NotificationManager mNotificationManager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
NotificationCompat.Builder builder = new NotificationCompat.Builder(context);
builder.setAutoCancel(true);
Notification mNotification = builder.build();
mNotification.icon = R.drawable.umeng_push_notification_default_large_icon;//notification通知欄圖標
mNotification.defaults |= Notification.DEFAULT_SOUND;
mNotification.defaults |= Notification.DEFAULT_VIBRATE ;
//自定義布局
RemoteViews contentView = new RemoteViews(getPackageName(), R.layout.notification_view);
contentView.setImageViewResource(R.id.notification_large_icon, R.drawable.umeng_push_notification_default_small_icon);
contentView.setTextViewText(R.id.notification_title, msg.title);
contentView.setTextViewText(R.id.notification_text, msg.text);
mNotification.contentView = contentView;
PendingIntent contentIntent = PendingIntent.getActivity(context, 0,
intent, PendingIntent.FLAG_UPDATE_CURRENT);
//notifcation.flags = Notification.FLAG_NO_CLEAR;// 永久在通知欄里
mNotification.flags = Notification.FLAG_AUTO_CANCEL;
//使用自定義下拉視圖時，不需要再調用setLatestEventInfo()方法，但是必須定義contentIntent
mNotification.contentIntent = contentIntent;
mNotificationManager.notify(103, mNotification);
}
}

㈧ 友盟-推送-Andorid-「標簽(tag)」是什麼，如何使用自定義標簽

友盟推送支持的篩選維度有「版本」、「渠道」、「地域」、「用戶活躍度」等，還有一個叫做「標簽」，「標簽」是什麼含義呢？該如何使用呢？ 今天我們和大家聊聊這個話題。

先解釋下什麼是「標簽」:

提問者問到的「標簽」其實指的是App開發者結合自有的業務邏輯對該App的終端用戶打的「標簽」，我們也稱tag，這些「標簽」是App自己的標簽（舉個簡單的例子，App根據終端用戶是否注冊，可以給用戶打上「注冊賬號」和「未注冊賬號」的標簽），第三方開發平台是無法直接提供這樣的標簽的(但是可以開放打標簽介面，讓App開發者把標簽數據回傳到第三方伺服器上)，因為具體的業務邏輯是在App這邊的。 第三方開放平台能提供的維度也僅是在用戶協議范圍內可以收集的欄位，比如「版本」、「渠道」、「機型」、「操作系統」等信息，這些維度可以認為是靜態的維度，其實App開發者自己也可以收集這些欄位，只不過交給第三方平台來做數據收集、存儲和計算更為方便，有興趣的讀者可以了解一下友盟推送收集的用戶協議欄位: 友盟 | 隱私政策。

下面我們給大家提供一些有代表性的垂直領域App結合自有業務邏輯給終端用戶打標簽的思路，希望對大家有幫助:
體育類App可以根據終端用戶看過的節目類型，給終端用戶打上「足球」、「籃球」等類目標簽。
兒童類App可以根據兒童的年齡分布，給終端用戶打上「0~1歲」、「1~3」歲、「3~5」歲之類的年齡結構標簽。
電商類App可以根據用戶的購買習慣推算出用戶性別，給終端用戶打上「男」、「女」標簽。
餐飲類App可以根據用戶的下單記錄以及點評，給終端用戶打上「川菜」、「粵菜」、「韓國料理」等標簽。
……

App自有的標簽體系對精細化運營來說是必需的，App運營人員可以根據這些用戶標簽來做精準推送、廣告定向投放、活動邀請等運營活動。既然標簽這么有用，接下來我們和大家聊聊如何在友盟推送中使用「標簽」維度，順帶也回答了提問者的第二個問題。

再來談談如何在友盟推送中使用「標簽」:

上文提到過雖然第三方開放平台無法直接給App開發者提供「標簽」維度，但是可以開放打標簽的介面，讓開發者把標簽數據回傳到第三方伺服器上。下面給大家講講友盟推送開放介面的形式，以及開發者如何使用開放的介面來把標簽數據回傳到友盟伺服器端:

圖中，黃色部分表示友盟推送提供的模塊兒，綠色部分部分表示App開發者自己的模塊兒。

方式1(推薦方式): App端直接調用友盟推送SDK提供的tag介面，由SDK負責把標簽數據回傳到友盟後端伺服器。 後期tag(標簽)的存儲、計算等邏輯都由友盟後端伺服器來負責。這種方式是推薦的方式，絕大部分開發者都採用這種打tag的方式。SDK端提供的調用介面有如下幾個:

mPushAgent.getTagManager().
添加標簽
public Result add(String... tags)
刪除標簽
public Result delete(String... tags)
清除所有標簽
public void reset()
獲取伺服器端的所有標簽
public List<String> list()

具體用法請參照我們的集成文檔: 友盟消息推送Android文檔

方式2: 開發者在自己的伺服器上通過調用友盟伺服器端提供的開放介面將該標簽數據回傳到友盟後端伺服器，效果和方式1一樣。 有這種需求的開發者不是太多，所以我們的文檔上沒有把這個介面列出來，有需求的開發者可以聯系msg-support at umeng dot com來獲取這個介面的文檔。

通過方式1或者方式2，開發者就把和自己App業務相關的標簽屬性維度放在友盟平台上了，這樣友盟推送間接的提供了「標簽」維度，和其它靜態維度一樣，「標簽」可以和這些維度一塊兒來使用(App自身業務邏輯結合友盟數據屬性)，也可以單獨來使用(純App自身業務邏輯)，開發者可以利用這些綜合維度來做更精準的推送，從而獲得更好的推送效果了。關於「精準推送」，感興趣的讀者可以參考我之前寫過的一篇文章: 友盟陳漠沙：「精準推送」是怎樣煉成的？ - 友盟專欄 - 知乎專欄

開發者在使用標簽的過程中，可能會碰到這樣的問題，就是明明在SDK端已經調用了標簽介面，但是在友盟推送後台網站上並沒有顯示出剛剛打的標簽。這里需要和大家解釋一下為什麼「標簽」不能及時展現在我們的網站上，其實還是要區分一下「正式模式」和「測試模式」兩種case的，在「測試模式」下，測試設備的標簽是及時出現在網站後台的；在「正式模式下」，大概會有5~10分鍾的延遲。這是因為數據量規模決定的，測試設備數量少，所以我們能做到實時處理，線上真實設備數據量龐大，計算節點在計算的時候，會有一定的延遲。 所以開發者在集成測試階段，如果要測試tag功能的話，建議先把測試的設備在「測試模式」下添加為測試設備。關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。

最後，歡迎大家關注友盟消息推送的官方微博賬號"友盟推送"，我們的官微會定期和大家share一些技術干貨。

㈨ 友盟-推送-Andorid-消息推送-打開通知消息進入特定Activity操作

要獲取參數的話 只能通過自定義打開行為，重寫dealWithCustomAction

在消息推送SDK里，有一個類UmengNotificationClickHandler，負責處理消息的點擊事件。 該類主要有四個成員方法：

public void launchApp(Context context, UMessage msg);
public void openUrl(Context context, UMessage msg);
public void openActivity(Context context, UMessage msg);
public void dealWithCustomAction(Context context, UMessage msg);
這四個方法，分別對應於四種打開方式。其中，launchApp、openUrl、openActivity這三個方法已經由消息推送SDK完成，而dealWithCustomAction則只是一個空的方法。 若開發者需要處理自定義行為，則可以重寫方法dealWithCustomAction();其中自定義行為的內容，存放在UMessage.custom中。下面是處理自定義行為的代碼：

/**
* 該Handler是在BroadcastReceiver中被調用，故
* 如果需啟動Activity，需添加Intent.FLAG_ACTIVITY_NEW_TASK
* */
UmengNotificationClickHandler notificationClickHandler = new UmengNotificationClickHandler(){
@Override
public void dealWithCustomAction(Context context, UMessage msg) {
Toast.makeText(context, msg.custom, Toast.LENGTH_LONG).show();
}
};
mPushAgent.setNotificationClickHandler(notificationClickHandler);
注意
以上代碼需在 Application 的onCreate() 中調用使用以下介面，而不是在Activity 中調用。如果在Activity中調用此介面，若應用進程關閉， 則設置的介面會無效。 請參考demo 應用代碼。
該Handler是在BroadcastReceiver中被調用。因此若需啟動Activity，需為Intent添加Flag：Intent.FLAG_ACTIVITY_NEW_TASK，否則無法啟動Activity。
若開發者想自己處理打開網頁、打開APP、打開Activity，可重寫相應的函數來實現。